WebDev Dayiawan
52.9K subscribers
2 photos
6 videos
8 links
WebDev-канал о разработке современных web-приложений:

— React
— Next.js
— Node.js
— Docker
— CI/CD
— Базы данных
— Архитектура и production

Разборы решений, ошибок, оптимизации и инженерной практики.

Портфолио:
https://motoyama.one
Download Telegram
Media is too big
VIEW IN TELEGRAM
Оптимизация веб-приложений — это комплексный процесс, включающий работу с фронтендом, бэкендом и серверной частью. Следование лучшим практикам, таким как минификация, кеширование, балансировка нагрузки и мониторинг, позволяет добиться высокой скорости работы и стабильности приложения.

#devops #webdev #weboptimization
🤩112🔥107💯104👍9491😱6🫡6
Друзья, всех приветствую)! Не скучайте, скоро будет продолжение ) Всех обнял🙏
💯111👍106🔥101🤩8986🫡4😱1
Локально уже всё работает 😄
Осталось задеплоить — и залью апдейт!
Следующий релиз — скоро в прод 🚀
🤩116106🔥97💯96👍87👌1
Билд зелёный, релиз уже близко)!
96💯96🔥95🤩93👍90🤗4
Всем чмоки)! Кажется, я таки добрался до Хабра — и, что удивительно, меня там даже пустили писать статьи )

Открываю сезон публикаций материалом по DevOps: как это всё работает, почему контейнеры не кусаются, и что Docker — это не только «завтра сделаю образ», а вполне себе рабочий инструмент, если им пользоваться по-человечески )

Если хотите поддержать моего внутреннего автора — лайк, репост и тёплое словцо в комментариях сделают этот день чуть лучше )
Ну, а я тем временем уже варю вторую статью.

Мой профиль на Хабре: https://habr.com/ru/users/MOTOYAMA/articles/

#motoyama #devops #docker #dockercompose #infrastructure #backend #fullstack #itlife #инфраструктура #контейнеризация #разработка #хабр
💯105🤩104🔥9591👍80
theХабр — двери открыты, друзья)!

Пишу бэкенд, играюсь с фронтом,
Фуллстеклю бодро и с огоньком.
А теперь ещё и на Хабре появился —
как будто открыл себе новый дом 😄

Статья уже там — про web, опыт, код
и всё то, что меня зажигает из года в год.
Если любите IT и человеческую подачу —
заглядывайте, буду рад вашей отдаче 🙌

Мои публикации:
👉 https://habr.com/ru/users/MOTOYAMA/articles/

#backend #frontend #fullstack #devops #habr #webdev #react #javascript #nextjs #фуллстек #айтишник #motoyama #programming #itюмор
👍100💯9895🔥93🤩843
О-нет… О-да, друзья! Это свершилось🎯
Я наконец-то задеплоил своё полноценное web-портфолио:
https://motoyama.one

Там React. Там Next.js. Там продакшн.
Там код, который можно открывать без дрожи в руках🚀
Там и Йога, музыка и видео, весь мой IT-путь, собранный в одном месте — от разработки до внутренней алхимии😄

Заходите посмотреть:
— рекрутерам — понять, как я работаю,
— знакомым — чем я дышу,
— любопытным — что я вообще делаю ночами.

Параллельно я начал вести IT-блог и публиковаться на Хабре — так что теперь у меня не только код, но и слова существуют в продакшн-режиме.

Ну и да… ваша поддержка (вы ведь знаете какая, да?) по традиции отправляет меня куда-то между большим спортом и большим сексом, иначе говоря — в большую IT-садхану))!🤝

#react #nextjs #nodejs #frontend #webdev #motoyama #itсадхана
👍369🤩364🔥356💯335334🌚2🤯1😱1
Media is too big
VIEW IN TELEGRAM
Иногда смотришь на React-проект — вроде ничего сложного. Пара форм, список, несколько модалок. А DevTools показывает постоянные ререндеры и CPU внезапно начинает жить своей жизнью.

И почти всегда причина оказывается не в React.

Чаще всего это история про бесконтрольные ссылки. Кто-то передаёт inline-объекты в пропсах, кто-то генерирует функции прямо в JSX, кто-то держит половину приложения в одном state «для удобства».

А потом начинается: «React тормозит».

Нет. React как раз делает то, что ему сказали.

Особенно хорошо это видно на больших таблицах или dashboard-интерфейсах. Один неудачный state наверху дерева — и у тебя обновляется всё приложение из-за изменения одного checkbox.

Production-фронтенд — это уже давно не про «сделать UI». Это управление количеством обновлений и контроль связности компонентов. https://motoyama.one
Media is too big
VIEW IN TELEGRAM
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
This media is not supported in your browser
VIEW IN TELEGRAM
Есть API, с которыми работаешь спокойно. А есть такие, где каждый новый endpoint ощущается как отдельное приключение.

И почти всегда проблема не в backend-логике, а в отсутствии нормального API-дизайна.

Когда у тебя рядом существуют:

/api/getUser
/api/deletePost
/api/updateProfileData

— это уже тревожный сигнал.

Особенно когда ответы ещё и приходят каждый раз в разном формате. Где-то массив. Где-то data. Где-то result. Где-то вообще просто boolean.

В итоге фронтенд превращается не в клиентское приложение, а в слой адаптеров между хаосом и UI.

Хороший REST API — это предсказуемость. Когда разработчик заранее понимает, как будет выглядеть следующий endpoint, ещё до чтения документации.

Именно это в production экономит огромное количество времени. https://motoyama.one
This media is not supported in your browser
VIEW IN TELEGRAM
Очень характерный признак "уставшего" frontend-проекта — когда useEffect начинает использоваться как универсальный костыль вообще для всего.

Получение данных. Синхронизация state. Вычисления. Фильтрации. Подписки. Иногда даже бизнес-логика.

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

Особенно опасен момент, когда разработчик уже перестаёт понимать, почему эффект вообще срабатывает.

useEffect сам по себе не сложный. Сложными становятся зависимости.

Потому что React сравнивает ссылки, а не "смысл" объектов.

Именно поэтому один неосторожный объект в deps может внезапно превратить приложение в вентилятор ноутбука.

Production React довольно быстро учит относиться к useEffect максимально осторожно. https://motoyama.one
This media is not supported in your browser
VIEW IN TELEGRAM
Иногда смотришь Lighthouse-отчёт и видишь frontend на 8 мегабайт. И это уже почти норма.

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

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

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

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

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