Структура frontend-приложений. Миф или реальность?

Привет, меня зовут Александр Шальнев. Я фронтенд-разработчик в компании Флайкод. В этой статье я хотел бы затронуть архитектуру frontend-приложений.

1313

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

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

Основной проект голый, то есть дает примитивный функционал в виде формы авторизации. Рабочий проект собирается из крупных модулей, которые независимы друг от друга.
Есть встроенные базовые модули (авторизация, api, базовый ui, базовая админка), есть подключаемые модули. У каждого модуля есть публичная часть - компоненты, которыми он может «поделиться» с другими модулями.
Оркестрация осуществляется на уровне ядра, которое подключает необходимые модули, хранит в себе конфиги, состояния и доступные извне компоненты модулей.
Сами по себе модули независимые, но могут использовать как куски базовых модулей, так и интегрироваться в другие модули. Все взаимодействие модулей осуществляется через ядро. К примеру - к стандартной админке добавляетсяся администрирование из кастомного модуля. Или один из подключённых модулей расширяет функционал другого модуля. При этом отключение какого-либо модуля не ломает проект, он просто теряет функциональность.
Конфигурируется одним файлом, который включает в себя набор нужных модулей и кастомные настройк .
При сборке в бандл включаются только база и модули из конфига.

1

Звучит как повод уволиться, я на этапе собеседования пытаюсь выяснить обычно насколько всё перевязано через вопросы о UI-ките, там обычно всякая хуйня быстро вылазит

2