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

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

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

Первостепенная задача была — настроить централизованное управление статическим контентом и настроить приватность блоков на основе конфигурации (layout), приходящей с бекенда. Сюда так же входило управление фичами.

Передо мной встала задача подготовки этой структуры. Ну, конечно, без переколбаса некоторых частей приложения не обошлось. На тот момент у нас было 4 потенциальных маркета. Как было описано выше, я вынес настройку статики в централизованный конфиг, построил структуру данных на основе общего шаблона лейаута, добавил опциональность блоков для различных брендов и фич на будущее:

«Можно привести аналогию централизованной настройки прав доступа или даже прошивка приложения под мультиязычность, второе конечно чуть попроще.»

1. На бекенде можно было создать навигацию по заранее составленной структуре для статических страниц. При открытии роута уходил запрос на сервер, который присылал html и формировал необходимую статику. Для создания статики, как правило, использовался базовый набор тегов p, img, h, который заранее был стилизован на клиенте. Сама html могла гибко настраиваться в специальной админ-панели простым редактором на основе библиотеки quill. Кстати, для стилей тоже можно было придумать обработку. 2. Роутинг был разбит на сегменты: header-top, header-bottom, footer. Аналогично другие особенности навигации логотипов и разного рода информации. В основу этого конфига закладывалась централизованная наполняемость платформы любыми частями. Несмотря на то что в этой задаче был упор на статику, я допустил, что таким образом можно настроить абсолютно все. 3. Обработка событий и состояния ui отдельных частей приложения. 4. Например: основная платформа имела вид карточки товара с кнопкой добавить, а версия b2b имела характерно отличное состояние «согласовать» и соответственно обрабатывала совершенно другой запрос. 5.Сюда же легла централизованная настройка дизайна, которая, конечно, была не так хорошо продумана. Но я в силу своей фантазии всё таки заложил чуть более гибкое управление, а дизайнер подготовил набор токенов под разные бренды.

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

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

Хорошо проработанная структура на фронтенде (и бекенде) позволяет сосредоточиться больше на оптимизации, анимациях и вообще любых свистелках, улучшающих пользовательский опыт.

Подобный опыт сподвиг меня реализовать свою ERP-систему, которая позволит одновременно прокачать навыки архитектурного подхода, системного анализа и взаимодействия между модулями на уровне базы данных и сервисов.