Почему markdown лучше мини-CMS
Когда я только задумался о личном журнале, первой реакцией было поставить что-то готовое. WordPress, Ghost, может, Notion как публичный блог. Потом подумал — зачем мне база данных, админка, авторизация, плагины, обновления? Мне нужно одно: быстро записать мысль и увидеть её на сайте. Оказалось, что markdown-файлы справляются с этим лучше любой CMS.
Почему я вообще думал про CMS
Привычка. Все ведь так делают — ставишь WordPress, выбираешь тему, пишешь через визуальный редактор. Есть пользователи, комментарии, медиа-библиотека. Всё как у людей.
Но чем больше я думал о своей задаче, тем яснее понимал: мне не нужна «платформа для публикации». Мне нужен быстрый путь от мысли до опубликованной записи. Без логина, без дашборда, без «сохранить черновик» и «опубликовать». Я хочу думать о содержании, а не об интерфейсе.
Что получилось с markdown
Журнал работает так. Каждая статья — один markdown-файл в папке posts/. Файлы складываются в index.json — это лента. Статический HTML генерируется билдером. Nginx отдаёт статику. Всё.
Это значит:
- Прозрачность. Любой файл открывается в любом редакторе. Не нужно заходить в админку, не нужно понимать, где лежит контент. Он лежит там же, где и код — в git-репозитории.
- Версионность. Каждое изменение — коммит. Можно посмотреть, как статья выглядела неделю назад. В CMS для этого нужны плагины или отдельные таблицы в базе.
- Портативность. Markdown — это просто текст. Перенёс папку на другой сервер — журнал работает. Не нужно экспортировать базу, переносить настройки, чинить совместимость плагинов.
- Скорость. Статика отдаётся мгновенно. Никакого рендеринга на сервере, никаких запросов к базе. Nginx отдаёт HTML-файл — и всё.
- AI-дружелюбность. Агент может создать файл, обновить индекс — и статья уже на сайте. Ему не нужно проходить авторизацию в админке, не нужно разбираться в структуре базы данных. Просто запись в файл.
Что дало API поверх markdown
Первая версия журнала была чисто файловой — агент создавал markdown и запускал билдер. Потом я добавил API: один POST-запрос — и статья опубликована. С валидацией, с автогенерацией индекса, с prerendered HTML для SEO.
И вот тут раскрывается главное преимущество markdown как основы. API — это просто тонкий слой поверх файлов. Он не заменяет формат, он упрощает рутину. Если API сломается — я могу создать файл руками, и всё заработает. Если база данных CMS упадёт — сайт ляжет.
Тот же подход работает с картинками: POST-запрос с бинарником, сервер сам создаёт WebP-варианты, кладёт в нужную папку, возвращает markdown-путь. Ни одной SQL-таблицы.
Где markdown слабее CMS
Честно — не везде markdown выигрывает.
Нет пользовательской системы. Если нужен мультиавторский блог с ролями и модерацией — придётся что-то строить поверх. Для одного автора это не проблема, но для команды — ограничение.
Нет визуального редактора из коробки. Писать markdown — не то же самое, что набирать текст в Google Docs. Для кого-то это порог входа. Я, кстати, именно поэтому написал собственный визуальный редактор — чтобы не думать о звёздочках и решётках.
Нет медиа-менеджера. В WordPress загрузил картинку — она в библиотеке, можешь вставить в любую статью. У меня — папка с файлами и API-эндпоинт. Работает, но менее удобно для нетехнического пользователя.
Нет комментариев. Если нужна дискуссия под статьями — придётся прикручивать сторонний сервис или встраивать Disqus и подобные решения.
Но для личного журнала ни одно из этих ограничений не оказалось критичным. Один автор, агент публикует, читатели читают. Всё.
Урок
Хорошая система фиксации знаний должна быть почти невидимой. Чем меньше инфраструктуры между мыслью и опубликованной записью — тем лучше.
CMS решает проблему «как управлять контентом». Markdown решает проблему «как быстрее зафиксировать мысль». Для личного проекта второе важнее первого.
А если потом понадобится мощность CMS — API и файлы легко обернуть в любой интерфейс. Формат не привязан к платформе. В этом и свобода.
