Меня недавно позвали в папку IT On и я согласился почти не раздумывая, потому что давно искал что-то похожее.

Там собраны люди, которые реально шарят в своей теме: разработчики, продакты, основатели стартапов, эксперты по карьере в tech. Каждый пишет про своё и в сумме получается полная картина индустрии.

Читаешь и чувствуешь что находишься внутри IT, а не наблюдаешь снаружи. Разница есть, проверено на себе.

Добавляй папку себе, советую!

Anti-corruption layer на фронте: зачем адаптеры между API и UI

Принято считать, что фронтенд просто берёт данные из API и рисует интерфейс.

На практике это быстрый путь к тому,
чтобы внешний контракт начал диктовать архитектуру UI.

В чём проблема

API почти никогда не совпадает с тем,
как думает интерфейс.

Бэкенд может отдавать:

👉 странные названия полей
👉 лишние вложенности
👉 nullable там, где UI ждёт значение
👉 статусы в формате, удобном серверу, а не экрану

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

Что делает anti-corruption layer

Он ставит прослойку между API и приложением.

Не компонент получает сырой ответ,
а адаптер превращает его в нормальную фронтовую модель.

function mapUserDtoToUser(dto: UserDto): User {
  return {
    id: dto.user_id,
    name: dto.full_name ?? 'Unknown',
    isAdmin: dto.role === 'admin',
  }
}

Компоненту уже не нужно знать,
как именно бэкенд назвал поле.

Почему это важно

UI становится чище

Компоненты работают с понятной моделью,
а не с набором компромиссов из API.

Изменения API дешевле

Поменялся контракт —
меняем адаптер,
а не ищем user_id по всему проекту.

Меньше бизнес-логики в JSX

Все эти проверки:

user?.profile?.data?.attributes?.name

не должны жить в компоненте.

Компонент должен рендерить состояние,
а не расшифровывать ответ сервера.

Где адаптер особенно нужен

👉 API старое или нестабильное
👉 несколько источников данных
👉 разные форматы одной сущности
👉 сложные статусы и enum
👉 много nullable-полей

Чем грязнее внешний мир —
тем полезнее слой нормализации.

Где можно не усложнять

Если проект маленький,
API стабильное,
а модель почти совпадает с UI —
отдельный слой может быть лишним.

Не нужно строить enterprise там,
где достаточно одной функции рядом с запросом.

Главная мысль

Anti-corruption layer — это не архитектура ради архитектуры.

Это защита UI от чужих компромиссов.

API может быть неудобным, историческим или странным.
Но ваш интерфейс не обязан таким становиться.

Frontend как монолит: когда микрофронтенды не решают проблему

Принято считать, что если фронтенд стал большим и тяжёлым,
значит пора пилить его на микрофронтенды.

Звучит логично.

👉 большой монолит — плохо
👉 много маленьких приложений — хорошо

На практике всё чуть сложнее.

Микрофронтенды не чинят плохие границы

Если в монолите непонятно:

👉 где заканчивается одна фича
👉 где начинается другая
👉 кому принадлежит состояние
👉 кто отвечает за общие зависимости

После нарезки лучше не станет.

Просто хаос переедет
из одной кодовой базы в несколько.

Проблема часто не в размере

Большой фронтенд сам по себе не проблема.

Проблема, когда:

👉 любая правка ломает соседний экран
👉 команда боится трогать shared
👉 релиз одной фичи блокирует остальные
👉 архитектура держится на устных договорённостях

Это не лечится микрофронтендами автоматически.

Микрофронтенды добавляют свою цену

Вместо одного приложения появляется набор новых задач:

👉 версионирование контрактов
👉 общая авторизация
👉 дизайн-система
👉 роутинг между частями
👉 observability
👉 деплой и rollback

И всё это тоже нужно поддерживать.

Когда они реально помогают

Микрофронтенды имеют смысл, если:

👉 команды независимы
👉 доменные границы уже понятны
👉 части продукта можно релизить отдельно
👉 есть зрелая платформа и инфраструктура

Сначала нужны границы.
Потом — микрофронтенды.

Не наоборот.

Частая ошибка

Команда берёт микрофронтенды
как способ «разобраться с монолитом».

Но если вы не можете выделить модуль внутри одного репозитория,
вы не сможете нормально выделить его в отдельное приложение.

Физическое разделение не заменяет архитектурное.

Что попробовать до микрофронтендов

👉 разделить проект по фичам
👉 навести порядок в shared
👉 описать владение модулями
👉 ограничить зависимости
👉 сделать независимые релизные зоны внутри монолита

Иногда этого уже достаточно.

Главная мысль

Микрофронтенды — это не лекарство от монолита.

Это способ масштабировать уже понятные границы.

Если границ нет,
вы получите не распределённую архитектуру,
а распределённый беспорядок.

Кошмар вайбкодера

✖️ xCode Journal