Почему личный сайт я сделал как маленькую платформу

Сайт-визитка легко может быть статичной страницей: несколько блоков, ссылки, форма контакта и деплой на любой хостинг. Для многих задач этого достаточно. Но в моем случае сайт должен был показать не только текст обо мне, а способ, которым я проектирую и довожу системы до рабочего состояния.

Так обычная визитка начала расти в маленькую portfolio platform: публичный сайт, блог, кейсы, технологии, комментарии, файлы, настройки и админка.

Почему не статический Markdown

Статический Markdown был бы быстрее. Я мог бы хранить посты в репозитории, собирать сайт на build-time и не думать об авторизации, файлах, инвалидации данных и админском UX.

Но у такого подхода есть ограничение: он почти ничего не показывает о backend-мышлении. А мне было важно показать именно продуктовый контур:

• как устроена модель контента;
• как работает админка;
• как обновляются данные после изменения;
• как загружаются и переиспользуются файлы;
• как живут публичные страницы и preview;
• как проект переносится в Docker и на production-сервер.

Для портфолио это даже честнее: если я говорю, что умею строить backend-системы, сайт сам может быть маленьким доказательством этого.

Что получилось внутри

Публичная часть построена на Next.js и React. Она отвечает за страницы, локали, витрину кейсов, блог, about, контакты и секцию технологий. Админка находится в том же приложении, но живет как отдельный рабочий интерфейс.

Backend построен на NestJS/Fastify. Данные хранятся в PostgreSQL, схема описана через Drizzle ORM. Отдельно вынесен auth-service, а Redis используется для инфраструктурных сценариев: например, для дедупликации просмотров и других задач, где не хочется тащить состояние в основную модель.

Файлы вынесены в объектное хранилище. Это важно даже для небольшого проекта: cover, изображения, документы и markdown-контент не должны зависеть от локальной файловой системы контейнера.

Админка как часть продукта

Админка здесь не “техническая страница для себя”. Это рабочий интерфейс, через который можно управлять:

• hero-блоком;
• about-страницей;
• кейсами;
• постами;
• технологиями;
• навигацией;
• контактами;
• настройками сайта;
• комментариями.

На практике именно админка быстро показывает слабые места архитектуры. Если после POST приходится вручную обновлять страницу, значит где-то не хватает инвалидации. Если refresh ломает авторизацию, значит auth flow недостаточно устойчив. Если upload файлов трудно переиспользовать, значит модель файлов еще не стала частью системы.

Почему это не overengineering

Да, для личного сайта это больше, чем нужно. Но цель проекта не только “разместить текст”. Цель - показать подход к разработке: я умею не просто сделать страницу, а собрать backend, frontend, админку, деплой и контентную модель в одно поддерживаемое целое.

При этом я стараюсь не добавлять сложность ради сложности. Если часть можно оставить простой, она остается простой. Архитектурный вес появляется там, где он снижает хаос: авторизация, контентные сущности, файлы, preview, массовый импорт, кеширование и deployment.