WebDev Dayiawan

О-нет… О-да, друзья! Это свершилось🎯 Я наконец-то задеплоил своё полноценное web-портфолио: https://motoyama.one Там React. Там Next.js. Там продакшн. Там код, который можно открывать без дрожи в руках🚀 Там и Йога, музыка и видео, весь мой IT-путь, собранный в одном месте — от разработки до внутренней алхимии😄 Заходите посмотреть: — рекрутерам — понять, как я работаю, — знакомым — чем я дышу, — любопытным — что я вообще делаю ночами. Параллельно я начал вести IT-блог и публиковаться на Хабре — так что теперь у меня не только код, но и слова существуют в продакшн-режиме. Ну и да… ваша поддержка (вы ведь знаете какая, да?) по традиции отправляет меня куда-то между большим спортом и большим сексом, иначе говоря — в большую IT-садхану))!✨🤝 #react #nextjs #nodejs #frontend #webdev #motoyama #itсадхана

Иногда смотришь на React-проект — вроде ничего сложного. Пара форм, список, несколько модалок. А DevTools показывает постоянные ререндеры и CPU внезапно начинает жить своей жизнью. И почти всегда причина оказывается не в React. Чаще всего это история про бесконтрольные ссылки. Кто-то передаёт inline-объекты в пропсах, кто-то генерирует функции прямо в JSX, кто-то держит половину приложения в одном state «для удобства». А потом начинается: «React тормозит». Нет. React как раз делает то, что ему сказали. Особенно хорошо это видно на больших таблицах или dashboard-интерфейсах. Один неудачный state наверху дерева — и у тебя обновляется всё приложение из-за изменения одного checkbox. Production-фронтенд — это уже давно не про «сделать UI». Это управление количеством обновлений и контроль связности компонентов. https://motoyama.one

Node.js отлично держит нагрузку ровно до того момента, пока кто-нибудь не начинает писать backend как PHP из 2012 года. Особенно весело становится, когда в request handler внезапно появляется тяжёлый JSON.parse, синхронное хеширование или генерация PDF "на лету". А потом начинаются разговоры про то, что "Node не подходит для highload". Подходит. Просто event loop не умеет колдовать. Очень многие backend-проблемы в Node — это не недостаток платформы, а отсутствие понимания, что у тебя фактически один главный поток обработки. Любая тяжёлая синхронная операция в этот момент останавливает всё приложение. Вообще всё. Новые запросы. WebSocket. API. Очереди. Всё ждёт. Production-backend на Node — это не только API и роуты. Это постоянный контроль того, что именно блокирует event loop. https://motoyama.one

Есть API, с которыми работаешь спокойно. А есть такие, где каждый новый endpoint ощущается как отдельное приключение. И почти всегда проблема не в backend-логике, а в отсутствии нормального API-дизайна. Когда у тебя рядом существуют: /api/getUser /api/deletePost /api/updateProfileData — это уже тревожный сигнал. Особенно когда ответы ещё и приходят каждый раз в разном формате. Где-то массив. Где-то data. Где-то result. Где-то вообще просто boolean. В итоге фронтенд превращается не в клиентское приложение, а в слой адаптеров между хаосом и UI. Хороший REST API — это предсказуемость. Когда разработчик заранее понимает, как будет выглядеть следующий endpoint, ещё до чтения документации. Именно это в production экономит огромное количество времени. https://motoyama.one

Очень характерный признак "уставшего" frontend-проекта — когда useEffect начинает использоваться как универсальный костыль вообще для всего. Получение данных. Синхронизация state. Вычисления. Фильтрации. Подписки. Иногда даже бизнес-логика. А потом внезапно появляются бесконечные ререндеры, гонки запросов и ощущение, что приложение живёт собственной жизнью. Особенно опасен момент, когда разработчик уже перестаёт понимать, почему эффект вообще срабатывает. useEffect сам по себе не сложный. Сложными становятся зависимости. Потому что React сравнивает ссылки, а не "смысл" объектов. Именно поэтому один неосторожный объект в deps может внезапно превратить приложение в вентилятор ноутбука. Production React довольно быстро учит относиться к useEffect максимально осторожно. https://motoyama.one

Иногда смотришь 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-инструментах. Благодарю за поддержку!

Самое интересное в production-разработке — почти все серьёзные проблемы со временем оказываются архитектурными. Не "не тот framework". Не "не тот язык". Не "не тот DevOps". Обычно всё намного прозаичнее: слишком сильная связность, отсутствие границ модулей, хаотичный state, ручные процессы и неподконтрольный рост системы. Технологии меняются быстро. Архитектурные ошибки живут годами. Именно поэтому опытные команды так много времени тратят не на "фичи", а на поддержание структуры проекта в адекватном состоянии. https://motoyama.pro

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