Каталог настолок. Часть 1. Начало.
Начал новый проект - домашний каталог настольных игр. Пока планируется веб версия для браузера, мобильное приложение под андроид, сервис-апи и база.
Дальнейшие сообщения по проекту будут под тегом #bgcatalog@eshu_coding
Путем наименьшего сопротивления было бы сваять браузер на React.js, а приложение - на том же реакте, или на котлине. Но я решил попробовать нестандартный путь - шарповый фреймворк Avalonia.UI. Он заявляется как тру кросс-платформенный: единая кодовая база для web, desktop, android и ios.
Пока я потратил часов 7 на утрамбовку браузерной авалонии в докер. Работающих примеров утрамбовки Avalonia в докер я так и не нашёл, пришлось собирать что-то по мотивам обсуждения в сообществе авалонии. Логика примерно такая: подсунуть результаты билда шарпового проекта в WASM в папку для раздачи статического контенда nginx. Пример докерфайла в репозитории. Для запуска надо стартовать docker-compose-avalonia.yml в корне решения.
#avalonia
#front
#проекты
Начал новый проект - домашний каталог настольных игр. Пока планируется веб версия для браузера, мобильное приложение под андроид, сервис-апи и база.
Дальнейшие сообщения по проекту будут под тегом #bgcatalog@eshu_coding
Путем наименьшего сопротивления было бы сваять браузер на React.js, а приложение - на том же реакте, или на котлине. Но я решил попробовать нестандартный путь - шарповый фреймворк Avalonia.UI. Он заявляется как тру кросс-платформенный: единая кодовая база для web, desktop, android и ios.
Пока я потратил часов 7 на утрамбовку браузерной авалонии в докер. Работающих примеров утрамбовки Avalonia в докер я так и не нашёл, пришлось собирать что-то по мотивам обсуждения в сообществе авалонии. Логика примерно такая: подсунуть результаты билда шарпового проекта в WASM в папку для раздачи статического контенда nginx. Пример докерфайла в репозитории. Для запуска надо стартовать docker-compose-avalonia.yml в корне решения.
#avalonia
#front
#проекты
avaloniaui.net
Avalonia UI – Open-Source .NET XAML Framework | WPF & MAUI Alternative
Avalonia is the open-source .NET UI toolkit that lets you port WPF code to Windows, macOS, Linux, mobile and WebAssembly, all from one XAML codebase. Free forever.
👏4
Каталог настолок. Часть 2. Эксперименты для разработки фронта.
Некоторое время поэкспериментировал с Avalonia.UI, первые впечатления.
По сравнению с React.js, на котором начинаешь писать не приходя в сознание, прям тяжко. По ощущениям, тут нужно сначала продумать что делаешь, спроектировать все основные окна и переходы, а потом садиться кодить. Без этого получается какая-то фигня прям сразу.
Отработал основные моменты будущего приложения - переходы между экранами, обработка свайпа на экране смартфона (пришлось пилить самому обработку событий движения, нажатия и отпускания экрана, 5 часов в первый раз), обновление содержимого интерфейсов. Следующим этапом будет уже реализация альфа-версии приложения.
По логике работы все достаточно сильно напоминает React.js: отдельно разметка и стили, отдельно - логика и контент.
Отдельно вызывает восторг то, что у бэкенда и фронта по-настоящему единая кодовая база, что открывает огромные возможности для разработки толстых клиентов - переноса логики с бэка на клиентское устройство.
В общем, для шарписта AvaloniaUI прям обязательный инструмент: возможность сделать mvp сразу для всех платформ - браузер, десктоп Линукс, Мак, Винда, мобильное приложение Андроид и iOS одним махом явно стоит того, чтобы немного помучаться на старте врубаясь в непривычную парадигму.
#avalonia
#bgcatalog@eshu_coding
Некоторое время поэкспериментировал с Avalonia.UI, первые впечатления.
По сравнению с React.js, на котором начинаешь писать не приходя в сознание, прям тяжко. По ощущениям, тут нужно сначала продумать что делаешь, спроектировать все основные окна и переходы, а потом садиться кодить. Без этого получается какая-то фигня прям сразу.
Отработал основные моменты будущего приложения - переходы между экранами, обработка свайпа на экране смартфона (пришлось пилить самому обработку событий движения, нажатия и отпускания экрана, 5 часов в первый раз), обновление содержимого интерфейсов. Следующим этапом будет уже реализация альфа-версии приложения.
По логике работы все достаточно сильно напоминает React.js: отдельно разметка и стили, отдельно - логика и контент.
Отдельно вызывает восторг то, что у бэкенда и фронта по-настоящему единая кодовая база, что открывает огромные возможности для разработки толстых клиентов - переноса логики с бэка на клиентское устройство.
В общем, для шарписта AvaloniaUI прям обязательный инструмент: возможность сделать mvp сразу для всех платформ - браузер, десктоп Линукс, Мак, Винда, мобильное приложение Андроид и iOS одним махом явно стоит того, чтобы немного помучаться на старте врубаясь в непривычную парадигму.
#avalonia
#bgcatalog@eshu_coding
👍6
Каталог настолок. Часть 3. Построение инфраструктуры.
Начал строить инфраструктуру для проекта домашнего каталога настолок (и частично для других будущих проектов).
Базовую площадку - gitea для хранения кода и управления процессом развертывания мне любезно предоставил друг. Был мысль завести свой собственный гитлаб или вообще все сделать на Github Actions, но я отказался от этой идеи. Администрировать гитлаб и платить аренду за сервер под него мне откровенно не хочется. Да и таск трекинг в гитлабе избыточно мудреный. В общем gitea меня полностью устраивает: тут и девопсячьи и менеджерские инструменты, например - доски задач внутри репозиториев, с прилинковкой к ним коммитов без лишних приседаний.
Пока задействовано четыре отдельных виртуальных сервера:
1. Сервер с базой данных каталога - PostgreSQL 16
2. Сервер для апи и браузерного клиента.
3. Хранилище для образов, пакетов и прочих артефактов.
4. Отдельный сервер, на котором осуществляется билд образов, которые впоследствии пушатся в хранилище из п. 3
Все 4 сервера взяты в качестве виртуалок у RUVDS. Почему не запихнуть все на один сервер, возможно - железный, арендованный у того же selectel?
Сборка образов, если дополнительно не подкручивать какие-то настройки, съедает 100% CPU. Если туда же запихать базу и сервисы - они начнут лагать. Постоянные билды могут подразумевать солидный кэш пакетов и базовых образов. Скорость сборки мне пока проект мой личный некритична, потому HDD, 1 ядро. Но на сборку может требоваться солидное количество оперативки, иначе она просто отваливается по out of memory, поставил пока 2Гб.
Для хранения образов мне в перспективе нужно много места, при этом, оперативки и ядер мне тупо не нужно. Потому тут 1 ядро, 500 Мб оперативки и HDD, который у RUVDS можно раздуть до 600 Гб
Базе данных при росте будут критичны все параметры, но на время разработки я ограничиваюсь самым дешёвым конфигом - 1 ядро, 500 Мб оперативки, 10 Гб SSD, 3 из которых сразу отданы под своп.
К серверу для сервисов требования примерно те же, что и к базе, но я решил завести его отдельно, чтобы проще было управлять зоопарком из контейнеров. Иногда приходится осуществлять массовыерепрессии мероприятия, не хотелось бы случайно грохнуть базу.
Ну и вместо хорошей железной тачки ценой аренды тысяч в 8-10 в месяц, я имею 4 виртуалки, которые все вместе обходятся в 1100р на этапе разработки, а ресурсы я смогу наращивать по мере необходимости. Но да, настраивать придется 4 сервера вместо одного.
#bgcatalog@eshu_coding
Начал строить инфраструктуру для проекта домашнего каталога настолок (и частично для других будущих проектов).
Базовую площадку - gitea для хранения кода и управления процессом развертывания мне любезно предоставил друг. Был мысль завести свой собственный гитлаб или вообще все сделать на Github Actions, но я отказался от этой идеи. Администрировать гитлаб и платить аренду за сервер под него мне откровенно не хочется. Да и таск трекинг в гитлабе избыточно мудреный. В общем gitea меня полностью устраивает: тут и девопсячьи и менеджерские инструменты, например - доски задач внутри репозиториев, с прилинковкой к ним коммитов без лишних приседаний.
Пока задействовано четыре отдельных виртуальных сервера:
1. Сервер с базой данных каталога - PostgreSQL 16
2. Сервер для апи и браузерного клиента.
3. Хранилище для образов, пакетов и прочих артефактов.
4. Отдельный сервер, на котором осуществляется билд образов, которые впоследствии пушатся в хранилище из п. 3
Все 4 сервера взяты в качестве виртуалок у RUVDS. Почему не запихнуть все на один сервер, возможно - железный, арендованный у того же selectel?
Сборка образов, если дополнительно не подкручивать какие-то настройки, съедает 100% CPU. Если туда же запихать базу и сервисы - они начнут лагать. Постоянные билды могут подразумевать солидный кэш пакетов и базовых образов. Скорость сборки мне пока проект мой личный некритична, потому HDD, 1 ядро. Но на сборку может требоваться солидное количество оперативки, иначе она просто отваливается по out of memory, поставил пока 2Гб.
Для хранения образов мне в перспективе нужно много места, при этом, оперативки и ядер мне тупо не нужно. Потому тут 1 ядро, 500 Мб оперативки и HDD, который у RUVDS можно раздуть до 600 Гб
Базе данных при росте будут критичны все параметры, но на время разработки я ограничиваюсь самым дешёвым конфигом - 1 ядро, 500 Мб оперативки, 10 Гб SSD, 3 из которых сразу отданы под своп.
К серверу для сервисов требования примерно те же, что и к базе, но я решил завести его отдельно, чтобы проще было управлять зоопарком из контейнеров. Иногда приходится осуществлять массовые
Ну и вместо хорошей железной тачки ценой аренды тысяч в 8-10 в месяц, я имею 4 виртуалки, которые все вместе обходятся в 1100р на этапе разработки, а ресурсы я смогу наращивать по мере необходимости. Но да, настраивать придется 4 сервера вместо одного.
#bgcatalog@eshu_coding
🔥6🤯1