Comments 24
Лендинг в виде бинарника на 20мб :)? Ну такое себе. 100мс до ттфб - это очевидный фейл. Что там говорит гугловский инструмент для проверки?
В целом уже и не страшно за пользователей этого всего. Сами виноваты. Если бизнес не умеет выбирать на инженерные задачи инженеров - он должен умереть. И вы ему прекрасно в этом поможете. И это отлично.
Да нет) Это CMS в виде бинарника, а к ней прикручивается фронт на чем угодно HTML, HTMX, React, Vue
«какие ваши предложения…»
Вы на каком объеме дискового пространства лендинг сделаете?
Не совсем понял вопрос. Лендинг можно уместить и на 100Кб (простой html файл), а можно и намного больше, это уже вопрос к фронтенду. А эта CMS может обслуживать бекенд не только под лендинг, а еще под сайты визитки, и простые корпоративные сайты где несколько статичных страниц, да новости.
Да, можно использовать Supabase, Google Sheets и другие инструменты, этот проект для тех кто хочет хранить все у себя "дома". Чтоб просто и быстро.
Никогда не делал, делал простенький им, но давненько.
С графикой аж 1.9мб.
Без яндексовского и гугловского js для мониторинга код со стороны юзера - по ощущениям килобайт 30.
3-5кб стили и html.
5-10кб исполняемая на сервере часть.
Остальное графика, текст итп. Все вместе для всех страниц да - около 20мб, может и больше даже. Фотки весят.
100 баллов по performance в лайтхаузе. Но бест пректис меньше -73, Яндекс с гуглом жгут.
Чей-то какая-то ерунда теперь вместо первого байта(помнится около 60мс требовалось), пишет что 9мс на получение тела понадобилось. Но похоже в сумме все(92 файла) приезжают за 0.9с. (speed index)
Результат неидеальный конечно.
Но это кстати, наверное еще и с поисковым индексом, он один раз приходит.
embed.FS хранит данные в ОЗУ, как понимаю. Поэтому КМК лучше сделать прямую загрузку ресурсов с какой-то директории.
Да, это в принципе верно, но частично. Просто был выбран компромисс в пользу embed.FS потому что, это единый бинарник — атомарное развёртывание, нет риска рассинхронизации файлов и кода и нет зависимости от рабочего каталога и прав на файловую систему, а также для шаблонов и статики размером в несколько сотен КБ разница на практике нулевая
Как опыт, ладно. Но как продакшен вариант, ещё и на Go, еще и такое… 😁 Не надо Django! Есть превосходное решение на нем же - Wagtail. Очень мощная CMS, простая как сапог! 😁 Еще и GraphQL из коробки… Если уж совсем простое, можно и WordPress. Django не большой, потребляет он около 64мб памяти. Wagtail аналогично очень лёгкий. Был опыт, делали тур проект + api радовало на приложение. Развернули на самом дешевом хостинге и все ок. 😁
Как опыт прикольно. Но это дикий оверинженеринг. 😁
респект и уважуха. к превеликому сожалению люди уже начинают забывать что так можно было, начинаются курсиков про всякие фркеймворки… А тут прям гордость! за наше, ламповое! Автор пиши ещё! +++
я в таком порыве, не так давно, свой мессенжер написал под андроид 🤣
…а ещё подобное надо делать на микроконтроллере, на чистом cpp ! был реальный кейс на esp32 :)))
А чем PocketBase не подошел?
А можно свой опыт размещать без таких жёлтых заголовков? Прям гарантия, что нет меньше, ресёрч был?
Это есть вся CMS ? Без админки? Что за бред?
Весьма занятный велосипед) Но границы ответственности по слоям прям трещат. Например в handlers прям идет обращение в базу данных. Но как концепт мне прям зашел👍🏻 Лайк!
У вас рейт лимитер берет глобальный лок на каждый запрос что делает это место узким горлышком. Для инкремента мутекс не нужен, досточно atomic. sync.Map тоже не про ваш случай, правильней будет взять RWMutex и обычный map
Headless CMS на Go — самая минималистичная система управления сайтом