Как менялся наш подход к архитектуре фронтенда
За пять лет существования компания Purrweb выпустила более 300 MVP. В основном это были различные CRM, CMS, приложения для фотографов или мерчандайзеров, то есть продукты с большой фронтчастью. За это время мы пробовали подходить к разработке фронтенда несколькими способами.
Вначале не было никакой конкретной методологии. Код для константы складывали в папку constants, хуки — в hooks. В итоге выросла связанность кода: в одном модуле проекта что-то меняем и получаем десяток ошибок в других. Со временем такой подход привёл к быстрому росту технического долга.
Затем команда перешла к методологии Ducks. Мы начали делить код проекта на «даки» (контейнеры) по предметной области. Например, в одном месте хранили всю логику для пользователей, в другом для сообщений. Технический долг уменьшился, отдельные куски кода стало проще поддерживать, но сильная связанность сохранялась.
После этого мы узнали об идее «умных» и «глупых» компонентов. Принцип простой: складываем бизнес-логику в «умные» контейнеры, а UI — в «глупые» презентационные компоненты.
Большим плюсом этой концепции было то, что в ней быстро разбирались новички в команде, — достаточно было дать им ссылку на статью Дэна Абрамова Presentational and Container Components. Мы получили хороший баланс между скоростью разработки и удобством поддержки, но всё ещё не могли полностью изолировать бизнес-логику от представления UI.
Наконец, команда пришла к Feature-Sliced Design. Это молодая архитектурная методология строго для фронтенда, которая помогает структурировать проект, изолировать модули и снизить связанность.
Сейчас мы используем FSD во многих клиентских проектах и видим, что код в них проще поддерживать. Это особенно важно, когда требования бизнеса постоянно меняются: легче подправить отдельный кусок кода, а не всю логику проекта, проще предсказать поведение зависимостей. Ещё один плюс для команды — структурно все проекты выглядят одинаково, поэтому разработчикам проще переходить между ними.
Принципы Feature-Sliced Design
Методология FSD предполагает, что код приложения делится на слои по принципу: чем выше, тем ближе к бизнесу. Верхний слой app содержит основную бизнес-логику и может обращаться к любому другому слою, чтобы переиспользовать какие-то его элементы. Нижний слой shared общедоступный, самый «глупый» и может использовать только те элементы, что относятся к нему. Такое разделение позволяет разработчику работать с предметной областью, избегая дублирования кода.
Внутри каждого слоя есть срезы (слайсы), которые делят код на модули по назначению. Например, один отвечает за всё, что связано с пользователем, другой — с постами, третий — с комментариями. А каждый срез содержит сегменты: уникальные компоненты UI, модели, обращения к API.
Такое детальное разделение даёт строго однонаправленное движение: в верхних слоях мы можем как угодно использовать простые элементы из нижних слоёв. При этом практически все фичи бизнес-логики будут изолированными.
Самое важное, что FSD даёт, — это низкая связанность и одновременно высокая сцепляемость (low coupling, high cohesion). Это значит, что модули почти ничего не знают друг о друге и не зависят друг от друга, при этом получается единая, логически связанная сущность.
FSD лучше всего подходит для больших проектов, где постоянно меняются требования к бизнес-логике приложения. При этом у неё довольно высокий порог вхождения: новичкам бывает сложно разобраться в сути методологии.
Наконец, нужно закладывать дополнительное время на проектирование, то есть из-за FSD растёт time to market. Чтобы этого избежать, можно использовать упрощённую версию методологии.
О чём спросить самого себя, чтобы выбрать подходящую методологию или архитектурный подход
На самом деле FSD — это не архитектура. Сам по себе фронтенд — это слой представления, его задача корректно отобразить данные. Вся логика его работы в любом случае хранятся на бэкенде, поэтому любая «архитектура фронтенда» в действительности является методологией. Правда, это не касается больших сервисов, таких как Figma, у которых действительно сложная бизнес-логика или функции работы с офлайновыми базами данных могут храниться на клиентской стороне.
Но фронтенд в приложениях с годами становится всё больше: в нём постепенно появляется своя бизнес-логика, множество разных состояний, работа с данными, офлайн базами данных. Поэтому разработчикам полезно понимать разные архитектурные подходы: layered, event driven, FSD и другие, — уметь с ними работать и применять даже в проектировании фронта.
Выбирая подход к разработке фронтенда, стоит задать себе четыре вопроса:
- Что должна делать система?
- Как она должна себя вести?
- Какие у неё есть ограничения?
- Какие фичи важны, а от каких можно отказаться?
Ответив на них, вы, скорее всего, уже поймёте, что нужно использовать FSD, модульную или какую-то другую методологию. А ещё может оказаться, что клиентская часть очень простая и для разработки вообще не нужен архитектурный подход.
Ответы на эти вопросы помогут ещё до старта проектирования понять, как будут взаимодействовать разные элементы приложения, какие у него функциональные и нефункциональные требования. Всё это в любом случае улучшит качество проекта, облегчит его разработку и поддержку.
Другие интересные мысли Сергея и примеры проектирования фронтенда по методологии FSD смотрите в записи выступления.