Alleycat: Я переделал CMS для своего блога

Привет, я некомпетентен.
Я попробовал переделать CMS для своего блога.
GitHub - haturatu/alleycat: cms & frontend · GitHub

В конце концов, если я собирался строить это так далеко, не лучше ли было бы использовать WordPress? Есть такой момент.

Зачем я это сделал?

Мой блог, который изначально мигрировал с WordPress на LumeCMS примерно в 2020 году, имел следующие первоначальные намерения для миграции:

• WordPress

  • Потребляет много памяти.

  • Хостинг MySQL только для личного блога — это избыточно.

  • Расширение функциональности полностью зависит от плагинов.

  • CSS и т.д. часто становятся хаотичными.

  • Трудно безопасно управлять, не имея возможности разделить порты под admin.

  • Было очень легко вставлять изображения напрямую копированием и вставкой.

  • Генерируются ненужные ресурсы, такие как уменьшенные изображения для миниатюр для всех изображений.

• LumeCMS

  • Потребляет довольно много памяти.

  • Поскольку это CMS на основе SSG, перестройка всего при каждом обновлении статьи была неэкологичной.

  • Нельзя загружать изображения напрямую копированием и вставкой.

  • Простота была очень хороша.

  • На самом деле, писать только в markdown не было проблемой, но довольно часто приходилось обновлять со смартфона, и тогда это было довольно сложно.

Вот так примерно.

Требования

Итак, необходимые требования следующие:

• Сама CMS может быть разделена по портам.

• Обработка загрузки изображений копированием и вставкой, а также генерация ссылок.

• Дизайн, который легко редактировать даже со смартфона.

• Свести CSS к минимуму, насколько это возможно для понимания.

  • В конце концов, неизбежно, что он будет увеличиваться.

  • Если внешние зависимости CSS увеличиваются, это становится непонятным, поэтому я хочу избегать этого насколько это возможно.

• Сделать фронтенд доступным без JS.

  • Статическая сборка необходима для производительности, и я хотел сделать ее удобной для пользователей w3m, который я до сих пор иногда использую.

• TOC (оглавление) обязательно.

  • Просто наличие этого значительно улучшает читаемость.

  • Однако, я задавался вопросом, почему TOC в Lume раньше начинался с h2? Но то, что эквиваленты заголовков не включаются в TOC, может быть вполне объяснимо.

  • Но почему-то Lume охватывал только до h3?

    • Может быть, потому что дизайн легче нарушается?

• Редактор с Rich Editor и md был бы удобен.

  • Для редактирования со смартфона.

• Только сейчас осознал ценность БД.

Что касается реализации

Лично мне Pocketbase показался очень удобным, поэтому я его и выбрал. Резервные копии данных можно сохранять в виде zip-файлов из стандартного веб-интерфейса, не требуя специальной реализации.

Обработка конфиденциальной информации также очень проста, потому что Pocketbase реализует ее соответствующим образом. База данных, похоже, SQLite.

Кроме того, я решил реализовать многоязычную поддержку, которую хотел сделать, но считал слишком сложной, зарегистрировав Gemini API.

Даже с Google Translate приходится перемещаться в верхнюю часть браузера и нажимать кнопку перевода, и я все же подумал, что лучше иметь это, просмотрев различные страницы документации. Однако это относится только к страницам статей.

Если я изменю его настолько, изменится ли он как блог-сайт? Или, скорее, мне интересно, с точки зрения человека из какой страны пишет автор блога, поэтому я хочу, чтобы японцы ориентировались на страницу типа About как японцы, и я не видел необходимости в этом на других страницах.

Проблема количества inode, или, скорее, дискового ввода-вывода

SSG также сталкивается с аналогичными проблемами, но дисковый ввод-вывод интенсивно сканируется, когда количество файлов после сборки увеличивается. Нет, нет, оставим в стороне замечание, что статьи не будут увеличиваться до исчерпания inode... Я не хочу увеличивать ненужные операции чтения/записи на диск.

В этом отношении публичные данные после сборки на самом деле не требуют такой большой постоянности. Поэтому

$ rg tmp
backend/ssr/config.go
13:     staticExportDir  = getEnv("STATIC_EXPORT_DIR", "/tmp/alleycat-static")

Таким образом, по умолчанию, выводя файлы в /tmp, мы размещаем статически собранные файлы в ОЗУ и доставляем их.

Место хранения данных изображений

В основном, я хотел иметь возможность копировать и вставлять изображения из веб-редактора, а также максимально упростить поддержание целостности между статьями и наборами изображений при экспорте, поэтому я решил напрямую вставлять бинарные данные в Pocketbase.

Есть моменты, когда я думаю: "Что это такое...". Но я никогда не смотрел папку, где хранятся изображения, и это сделано для уменьшения сложности. Кроме того, я сделал это так, потому что это облегчает проверку в Pocketbase.

Окончательные ресурсы: менее 500 МБ

Мне кажется, получилось довольно хорошо.

При сборке это выглядит как на изображении выше, но это примерно столько же ресурсов в режиме ожидания. Обычно это сходится к примерно 150 МБ или меньше.

Я рад, что смог реализовать это с такими ресурсами, включая CMS, и мне также хотелось попробовать, насколько я смогу доработать дизайн фронтенда с помощью Codex, так что, думаю, это был хороший эксперимент.

До скорой встречи. Всего наилучшего.