Иногда смотришь Lighthouse-отчёт и видишь frontend на 8 мегабайт. И это уже почти норма.

Особенно в проектах, где "на всякий случай" подключили ещё пару UI-kit, три библиотеки дат и несколько универсальных utility-пакетов.

Проблема в том, что bundle растёт незаметно.

Сначала один импорт. Потом второй. Потом внезапно Moment.js целиком. Потом lodash полностью. Потом analytics SDK размером с половину приложения.

И всё это пользователь тащит при первом открытии страницы.

Production frontend очень быстро учит неприятной вещи:
скорость интерфейса начинается не с React, а с размера JavaScript, который вообще доехал до браузера. https://motoyama.one

Docker сильно упростил деплой. И одновременно сильно упростил создание чудовищных контейнеров по 2 гигабайта.

Очень часто открываешь Dockerfile — а там в образ уезжает вообще всё подряд:

node_modules, тесты, devDependencies, исходники, временные файлы и половина CI.

Особенно нравится, когда production-контейнер собирается из того же stage, где происходил build.

В итоге:

долгий pull, медленный deploy, лишняя нагрузка на registry и проблемы при масштабировании.

Хороший production-образ обычно довольно скучный. Минимальный runtime, только нужные зависимости и никакого мусора внутри.

Но именно эта "скука" потом отлично работает под нагрузкой. https://motoyama.one

Есть особый вид production-страданий — когда база данных "вроде работает", но CPU сервера постоянно живёт на грани нервного срыва.

И почти всегда выясняется, что проблема не в количестве данных, а в запросах.

SELECT * стал национальной традицией.
N+1 запросы появляются как по расписанию.
Индексы вспоминают уже после первых проблем.

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

А потом один endpoint внезапно делает 300 SQL-запросов.

Production backend довольно быстро учит уважать SQL и смотреть execution plan раньше, чем сервер начнёт задыхаться. https://motoyama.one

Микросервисы очень красиво выглядят на архитектурных схемах. Особенно пока их не нужно поддерживать.

Потому что реальность начинается позже:

сервис-дискавери, очереди, retry, distributed tracing, деградация сети, синхронизация контрактов и внезапные проблемы между сервисами, которые "иногда воспроизводятся".

И всё это ради проекта, который обслуживает пару тысяч пользователей.

Очень многие команды приходят к неприятному выводу:
монолит был не проблемой. Проблемой было качество самого монолита.

Production-архитектура вообще редко любит преждевременную сложность. https://motoyama.one

Есть фронтенд-проекты, где новый разработчик боится открыть папку components.

И обычно это очень плохой знак.

Потому что если UI-слой превращается в свалку shared-компонентов без границ ответственности — дальше поддержка становится мучением.

Особенно когда внутри Button внезапно оказывается бизнес-логика, запросы и половина state-management.

Production frontend со временем начинает ценить не "переиспользование любой ценой", а предсказуемость структуры.

Иногда лучше иметь три похожих компонента, чем один универсальный монстр на 900 строк с 48 пропсами. https://motoyama.one

CI/CD начинает по-настоящему цениться только после первого деплоя "вручную в пятницу вечером".

Особенно когда:

кто-то забыл migration,
кто-то не обновил env,
а rollback внезапно тоже "не очень работает".

После пары таких историй автоматизация перестаёт казаться "избыточной".

Production вообще довольно быстро отучает от ручных процессов.

Потому что любой ручной шаг — это потенциальная ошибка. Особенно ночью. Особенно под нагрузкой. Особенно когда "надо срочно".

Хороший pipeline — это не про модные DevOps-термины. Это про снижение количества человеческих ошибок. https://motoyama.one

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

Поддержка IT-канала 🚀
Эта подписка помогает развивать канал и регулярно выпускать материалы о веб-разработке, архитектуре, DevOps и современных IT-инструментах. Благодарю за поддержку!

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

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

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

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

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

Поддержка IT-канала 🚀
Эта подписка помогает развивать канал и регулярно выпускать материалы о веб-разработке, архитектуре, DevOps и современных IT-инструментах. Благодарю за поддержку!