Как организовать архитектуру большого фронтенд-приложения?
- Что такое Feature-Sliced Design?
- Как разделить фронтенд на модули?
Цель — чтобы изменение в одной функции не задевало остальные и новый человек быстро находил код. Основа — разделение по функциональности (features, страницы, сущности), а не по типу файлов (components, utils, hooks), явные публичные API модулей, направление зависимостей (верхние слои зависят от нижних, не наоборот) и проверка границ линтером. Популярная методология — Feature-Sliced Design: слои app, pages, widgets, features, entities, shared.
- Серверное состояние — в кэше запросов, клиентское — рядом с местом использования
- Общие компоненты UI — в дизайн-системе, без бизнес-логики
- Границы проверяются автоматически (eslint-plugin-boundaries, правила импорта)
А ещё Архитектура должна соответствовать размеру: для маленького приложения FSD избыточна
Подробно
Признаки проблем: циклические импорты, «utils» на тысячи строк, изменение формы ломает три страницы, страх рефакторинга.
Принципы:
- модуль по бизнес-функции, внутри — всё нужное ей;
- импорт только через публичный
indexмодуля; - зависимости в одну сторону: страница → фича → сущность → общее;
- типы API генерируются из контракта бэкенда;
- состояние: серверное — TanStack Query, глобальное клиентское — минимум.
FSD:
| слой | что внутри |
|---|---|
| app | инициализация, провайдеры, маршруты |
| pages | страницы из виджетов |
| widgets | крупные блоки интерфейса |
| features | действия пользователя (добавить в корзину) |
| entities | бизнес-сущности (товар, пользователь) |
| shared | UI-кит, утилиты, клиент API |
Эволюция: при росте до нескольких команд — монорепозиторий с пакетами, затем, если нужно независимое развёртывание, микрофронтенды.
Что хотят услышать
- Деление по функциональности и явные границы.
- Направление зависимостей и автоматическая проверка.
- Соответствие архитектуры масштабу.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Раскладывать файлы только по типу: components, utils, hooks, — тогда границы модулей очевидны
- ✓Делить по функциональности с явными публичными API модулей и направлением зависимостей
- ✗Любой модуль может импортировать внутренности любого другого
- ✗Вся логика — в одном файле App
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.