JavaScript *

Как перестать копировать формы и построить масштабируемую архитектуру

В enterprise-приложениях формы множатся быстро: create, edit, import, create-from-lead, duplicate — и вот у вас уже шесть копий одной формы, а внутри условный ад из if (mode === …).

Почему mode prop и giant form component не масштабируются, как разделить форму на четыре слоя: presentation, orchestration, context, data source. Что такое capabilities и почему они лучше условной логики. Как адаптеры отвязывают форму от source entities. Куда прятать submit, валидацию и внешний store. Как тестировать такую архитектуру изолированно.

Да, я победил спам! Не "в основном", а "полностью и окончательно". Без всяких "почти". По крайней мере, на 99.9% победил. Причем этот 0.1% - не спам, прорвавшийся через фильтры, а false positives, которые не "вытащил" обратно в Inbox.

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

В большинстве компаний линтинг со временем превращается в хаос: разные правила ESLint, устаревшие конфиги и копипаста между проектами.

Покажу, как навести порядок – собрать линт-инфраструктуру в один пакет и выстроить систему контроля кода для всех репозиториев.

Если описать NestJS-архитектуру как граф — вершины это модули и классы, рёбра — зависимости между ними, — утверждение «архитектура не деградирует» перестаёт быть оценочным. Формально доказывается, при каких условиях циклы между модулями топологически невозможны, при каких размер публичного API не растёт с каждой новой ручкой, и при каких стоимость добавления фичи остаётся константой, а не растёт с числом существующих потребителей. Три измеримых структурных свойства, а не ощущение. Для типовой feature-based-структуры, которую сегодня продвигают как стандарт, ни одно из них не выполняется.

Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна.

Часть 5 — финал серии. Архитектурный подход, при котором эти три свойства соблюдаются (Feature-Based Clean Architecture), нагружается тем же сценарием годового роста, под весом которого деградирует обычный feature-based: партнёрка, анти-фрод, рефералки, расширенная аналитика, утроение модуля пользователей. Без художественности: реальный код, граф зависимостей «до» и «после», и формальное доказательство трёх свойств — DAG-инвариант, граница связности, O(1)-стоимость инкремента — на языке теории графов. Точка, в которой «архитектура не деградирует» становится не похвалой, а конкретным структурным утверждением.

После трёх частей разбора деградации остаётся один вопрос: как написать NestJS-проект так, чтобы god-сервис и циклические зависимости были невозможны. «Писать аккуратнее», «лучше ревьюить», «выделять день в спринте на рефакторинг» — варианты, которые не работают: дисциплина не масштабируется на пятьдесят спринтов и пять команд. Работает другое — наложить на модуль структурные ограничения, которые TypeScript и NestJS DI просто не дадут нарушить. Слои, однонаправленные зависимости, изоляция домена от инфраструктуры — не папки ради порядка, а барьер, который физически не пропускает сценарии деградации из частей 1–3.

Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна.

Часть 4 — конкретная имплементация подхода на том же сквозном Twitter-подобном бэкенде. Как модуль режется на четыре слоя (domain / use-case / infrastructure / presentation), как раздутый сервис заменяется набором use-case’ов, куда уезжает работа с базой и почему оркестратор перестаёт быть god-функцией. Без художественности: реальный код, что именно изменилось по сравнению с feature-based-структурой из частей 1–3, и точка, в которой видно — прежние сценарии деградации теперь не запускаются не потому, что «все стали аккуратнее», а потому что нечем.

Циклическая зависимость между двумя модулями в NestJS лечится двумя строчками forwardRef. Документация прямо это рекомендует, ревьюер пропустит за тридцать секунд, билд снова собирается. Через полгода окажется, что эти две строчки имеют ROI –35 000% за первый год и –360 000% к десятому: $30–60k в год сжигается в маленькой команде, $6–15M — в big tech, без единой написанной фичи. Счёт приходит размазанным платежом по будущим спринтам — и винить уже некого: автор уволился, команда сменилась, forwardRef стоит как стоял.

Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна.

Часть 3 — расчёт стоимости одной типичной декомпозиции по feature-based на горизонте пяти лет. Как первый forwardRef морозит цикл, как через пару спринтов он начинает блокировать соседние фичи и заставляет придумывать обходные костыли вокруг старой ошибки, во что это превращается в маленькой команде и в энтерпрайзе, и почему именно отсюда команды уходят в преждевременные микросервисы.

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

Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна.

Часть 2 — что произойдёт, когда команда честно сделает напрашивающийся после части 1 рефакторинг. Без художественности: реальный код после декомпозиции, демонстрация того, что на верхнем уровне всё действительно стало лучше, и параллельный запуск ровно того же сценария деградации уровнем ниже. Точка, в которой видно: декомпозиция не убирает проблему.

Разбираю проблемы cross-platform onboarding между Telegram Mini Apps и native apps. Почему Android, iOS, Windows и Linux по-разному ведут себя при deeplink handoff внутри Telegram WebView.

Привет! Меня зовут Костя, я разработчик интерфейсов в ЮMoney. В этой статье разбираю, почему вкладка после возврата из фона начинает вести себя странно: интерфейс подвисает, таймеры съезжают, события приходят пачкой.

Материал особенно пригодится тем, кто делает сложные SPA с realtime‑обновлениями, WebSocket и насыщенным UI — CRM, дашборды, платёжные сценарии.

В статье разберём:

— как устроены Page Visibility API и Page Lifecycle API,
— зачем браузеры ограничивают фоновые процессы,
— что происходит при заморозке вкладок, системном сне и возврате страницы из BFCache,
— чем отличаются Chrome, Safari и Firefox,
— какие API уже устарели,
— а какие подходы помогают делать интерфейсы стабильнее в реальных пользовательских сценариях.

Если ваш NestJS-проект собран по рекомендованной документацией feature-based-структуре — через год активной разработки у вас будет god-сервис. Не «возможно», не «при стечении обстоятельств» — структурно неизбежно. У этой структуры нет встроенного барьера от деградации.

Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна.

Часть 1 — старт траектории: AuthService с двумя ручками, который через год становится god-функцией на 200 строк с шестью параметрами и четырьмя независимыми доменами бизнеса. Без художественности — только реальные продуктовые требования (анти-фрод, реферальная программа, маркетинг, партнёрская программа) и их кумулятивный эффект.

В прошлой статье я рассказывал, каково в одиночку тащить фуллстек-проект, который разросся до кино-соцсети. В комментариях несколько раз спросили про конкретику — «покажи код», «как сделал, что не выглядит как очередной пет-проект». Логично: дизайн — это то, по чему встречают. Поэтому держите вторую часть, уже техническую и с кодом. Без маркетинга, только решения, которые реально сделали интерфейс «дорогим», и пара бэкенд-хитростей в довесок.

Сразу дисклеймер: я не дизайнер. Всё нажито методом «смотрю на референсы (Letterboxd, Mubi, KinoPoisk HD) и пытаюсь повторить ощущение». Оказалось, премиальность — это не про дорогие шрифты, а про несколько повторяющихся приёмов. Разберём пять.

1. Акцентный цвет из постера фильма — фича, которая дороже всего «продаёт»

Самое заметное решение. Раньше у меня на всех страницах был один статичный фиолетовый акцент — и это выглядело дёшево и одинаково. Идея: пусть каждая страница фильма подсвечивается доминантным цветом его постера. Заходишь на мрачный нуар — интерфейс уходит в холодный синий, открываешь комедию — тёплый янтарь. Страница будто «сделана под этот фильм».

Делается без всяких ML, прямо в браузере через canvas: рисуем постер в крошечный буфер 32×48, усредняем цвета (выкидывая чёрные рамки и серость), переводим в HSL и принудительно «насыщаем», потому что постеры часто тусклые. Результат кладём в CSS-переменную — и весь интерфейс подхватывает её.

Привет, я Игорь Аникин, Frontend разработчик RUTUBE TECH. Медиадизайнер, специализируюсь на компьютерной графике. Увлекаюсь программированием более 15 лет.

Это небольшой мастер-класс, как визуализировать звук двумя способами. Текст подойдёт любому читателю, которому интересна выразительная часть цифрового мира.

ES6 ввел синтаксис деструктурирующего присваивания — лаконичный способ распаковки значений из массивов и объектов в отдельные переменные. Это одна из тех фич, начав использовать которые, ты удивишься, как раньше без нее жил.

Получится ли сделать полноценную 3D-игру на Qt Quick3D?

Именно такой вопрос у меня возник, когда я начал изучать Quick3D. Казалось бы, рендер и партиклы есть, базовая физика в лице Quick3D Physics тоже присутствует. Пример CharacterController из Qt указывал на то, что проблем быть не должно.

Но хотелось проверить это самому на чём-то реальном.

Поскольку моделлер и художник из меня никакой, да и в геймдеве опыта у меня меньше нуля, я решил переписать Quake — любимую игру своего детства. В ней я провёл сотни (тысячи?) часов, играя в мультиплеер на бесплатных серверах МТУ-Информ через модем US Robotics 33600.

В итоге получился проект Kwayk — попытка переписать Quake на Quick3D.

В современной веб-разработке SEO и производительность часто вступают в противоречие. SSR дает хорошую индексацию, но усложняет архитектуру. CSR быстрее в разработке и меньше нагружает сервер, но поисковые боты могут не понять страницу.

Мы разрабатываем продуктовый сайт на Angular 17 с микрофронтендовой архитектурой на Module Federation. Нам нужно было и хорошее SEO, и привычный CSR для пользователей. В итоге мы выбрали гибридный подход: для людей — клиентский рендеринг, для поисковых ботов — пререндеринг через доработанный сервис MTS botview.

В статье рассказываем, почему чистый SSR не подошел, как мы разделили рендеринг, что доработали в открытом решении и как отличаем ботов от людей без ошибок.

Недавно я увидел видео, где маленький мальчик собирает кубик Рубика за 2,76 секунды (вот оно), и мне тоже захотелось научиться его собирать. Конечно, не за такое время, но главное — суметь сложить хотя бы за 10 минут. Главная проблема в том, что кубика у меня нет; можно купить, но это как-то скучно, на троечку. Поэтому я подумал: а почему бы не написать за выходные простой код, чтобы побыстрее посмотреть и покрутить кубик, а потом уже можно и купить. Заодно и разберусь, где что находится у кубика.

Navigation API предоставляет возможность инициировать (программно запускать), перехватывать и управлять навигацией в браузере. Он также позволяет исследовать (traverse) сущности истории (history entries) приложения. Это улучшенный вариант предыдущих возможностей веб-платформы, связанных с навигацией, таких как History API и window.location, который решает их проблемы и специально предназначен для одностраничных приложений (single-page applications, SPA).

Заключительная часть серии статей про Laravel + Centrifugo и как его готовить.

Сравниваем альтернативы Centrifugo для Laravel: Reverb, Pusher, Ably, Socket.IO, SSE и polling. Разбираем плюсы, минусы и сценарии выбора real-time решения.

Kufar.by - это примерно как avito.ru, только в Беларуси. После очередного “улучшения” там стало невозможно выбирать авто и недвижимость: цены показываются только в белорусских рублях, хотя рынок всегда будет в долларах (боже, храни Америку). Поэтому я сделал небольшой Chrome Extension, который добавляет рядом ориентировочную цену в долларах. Пока только для авто и недвиги. И да, по ощущениям, ЛПРы, которые это выкатывали, никогда не покупали ни то ни другое на своём сайте.

Начинаете писать E2E-тесты? Думаете, нужно просто открыть страницу, нажать кнопку и написать expect?

Разберем на примере Playwright, почему отчёт может быть зелёным, но бесполезным.