🏘 Frontend Архитектура — это не только папки

Я думаю многие из вас изучали FSD, Atomic Design, модульную организацию кода, разные подходы и best practices. И да, это всё действительно относится к архитектуре, но чаще всего — только к одному её уровню: архитектуре кода приложения.

То есть это история про то, как у вас организован frontend внутри самого приложения: как разделены модули, где лежит бизнес-логика, как устроены зависимости, shared-слои, UI, entities и всё остальное. По сути — как разработчику комфортно жить внутри кодовой базы.

Но проблема в том, что многие начинают воспринимать архитектуру только как “структуру папок”, хотя в реальности frontend architecture в больших продуктах намного шире.

А есть ещё архитектура данных — и это вообще отдельный слой, не про “какой стор выбрать”. Это про то, как приложение работает с состоянием и данными в целом.

Client state и server state — разные миры: для серверного уже нужны React Query, SWR или RTK Query, потому что там кеш, фоновые обновления и оптимистичные апдейты, а не просто глобальный store. Дальше сразу встают вопросы: как инвалидировать кеш — полностью или точечно, где источник правды — backend, URL или локальный state, и нужно ли нормализовать данные или можно хранить как есть. Плюс API-контракты (REST, GraphQL, BFF) напрямую влияют на то, как вообще живёт фронт.

Например, есть архитектура приложения. И это уже не про FSD и не про папки, а про то, как frontend устроен как система. У вас это монолит, модульный монолит или платформа из микрофронтов? SPA, SSR или гибрид? Один runtime или несколько независимых приложений внутри платформы? Как разделены домены и product boundaries? Тут уже думаешь не про структуру src, а про то, как будет жить продукт целиком.

Дальше — архитектура репозиториев. Допустим, у вас есть микрофронты. Где они живут: в монорепозитории или в разных репах? Как шарится код между ними? Где лежит UI Kit? Как живут SDK, shared types, api clients? Через npm packages, internal registry или shared workspace? Это тоже архитектура, потому что напрямую влияет на скорость разработки, CI/CD и управляемость системы.

Есть ещё runtime architecture — то, как frontend работает во время выполнения. Module Federation, shell app, event bus, shared state, communication between microfrontends — это всё про то, как независимые части системы взаимодействуют и не разваливаются после очередного релиза :)

Плюс архитектура команд. Это часто недооценивают, но в enterprise frontend всё сильно завязано на бизнес. Появляются ownership-зоны, продуктовые команды, домены и границы между ними. И архитектура начинает отражать не только код, но и то, как работают люди.

Ну и инфраструктурная история. Потому что задеплоить обычную SPA — это одно, а когда у тебя 15 микрофронтов, multirepo, shared SDK, federation и разные release cycles — это уже совсем другой уровень сложности :)

И отдельно UI architecture: design systems, UI Kit, токены, темы, shared components — всё это тоже часть общей картины.

Frontend Архитектура — это не только “как красиво разложить папки”. Это вся система организации frontend-разработки: от кода до платформ, инфраструктуры, runtime и команд.

Поэтому умение хорошо работать с FSD или писать UI Kit ещё не делает тебя архитектором. Архитектура больших frontend-систем — это уже про управление сложностью, границы ответственности, масштабирование и понимание системы целиком.

🚀 База собесов — 💪 Frontend Элита — 📚 Менторство — 📹 YouTube