WebDev Дайяван

Продолжаю развивать Hinduism.ru — один из моих основных Fullstack-проектов.

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

Технический стек: Next.js / React, TypeScript, PostgreSQL и Prisma. Реализованы собственная административная система, управление статьями, терминами, категориями, источниками и авторами, поиск и система связей между материалами.

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

Hinduism.ru — долгосрочный production-проект, на котором я последовательно развиваю архитектуру приложения и решаю реальные Fullstack-задачи по мере роста продукта.

Проект уже работает и продолжает развиваться:
https://hinduism.ru

Самое интересное в production-разработке — почти все серьёзные проблемы со временем оказываются архитектурными.

Не "не тот framework".
Не "не тот язык".
Не "не тот DevOps".

Обычно всё намного прозаичнее: слишком сильная связность, отсутствие границ модулей, хаотичный state, ручные процессы и неподконтрольный рост системы.

Технологии меняются быстро. Архитектурные ошибки живут годами.

Именно поэтому опытные команды так много времени тратят не на "фичи", а на поддержание структуры проекта в адекватном состоянии.

Одна из самых вредных привычек во frontend — решать архитектурные проблемы новыми библиотеками.

Не нравится state? Ещё один state-manager.
Проблемы с формами? Новый form-framework.
Тяжело с запросами? Добавим ещё abstraction layer поверх старого abstraction layer.

В итоге проект постепенно превращается в стек решений, которые конфликтуют друг с другом.

Production frontend довольно быстро учит неприятной мысли:

иногда проблема не в отсутствии библиотеки, а в отсутствии нормальной архитектуры.

Есть очень характерный момент взросления backend-разработчика.

Когда он впервые понимает, что "работающий код" и "надёжный код" — это вообще разные вещи.

Потому что локально почти всё работает.

Production начинается позже:

timeouts, retry, race conditions, потерянные соединения, сетевые сбои и внезапные пики нагрузки.

Именно там выясняется, насколько система реально готова к жизни.

Очень многие архитектурные решения начинают выглядеть иначе после первого серьёзного инцидента.

Самые дорогие баги обычно не выглядят страшно.

Это не "сервер загорелся".
Это маленькая незаметная проблема, которая медленно уничтожает production.

Например:

утечка памяти,
неконтролируемые таймеры,
WebSocket без очистки,
или queue consumer, который иногда зависает.

Такие вещи могут жить неделями.

Именно поэтому observability становится критически важной частью backend-инфраструктуры.

Потому что production без мониторинга — это управление системой вслепую.

Одна из самых неприятных production-проблем — frontend, который отлично работает у разработчика и начинает разваливаться у пользователей.

Особенно на слабых устройствах.

Потому что локально:

M3 Pro, 64GB RAM и идеальный интернет.

А у пользователя:

старый Android, медленный CPU и сеть, которая периодически уходит в медитацию.

И внезапно выясняется, что красивые анимации, тяжёлые hydration-процессы и гигантские bundle size ощущаются немного иначе.

Production frontend очень быстро учит тестировать не "у себя", а в реальных условиях.