Архитектура front-end приложений — react, react native, angular. Обзор

Продолжим цикл статей нашей компании легко и непринужденно, с темы из мира front-end. Тем более хабр томит с модерацией уже несколько дней. Надеюсь, что статья будет полезна тем, кто хоть как то связан с миром front-end. Предупреждаю, что backend разработчикам может быть скучновато из-за того, что у них давно все стандартизировано)

Когда я участвую в собеседовании на позицию React разработчика, обычно задаю общий вопрос об архитектуре - "как бы ты строил архитектуру своего приложения и почему?". После обсуждения, я начинаю рассказывать небольшую часть материала из этой статьи, 5% по содержанию, приводя тезисы, по которым можно будет собрать общую картину моего видения. И обычно получаю положительную обратку. Поэтому решил изложить этот материал более развернуто здесь. Тем более делиться ссылкой на vc будет очень удобно)

В статье я рассмотрю ключевые, на мой взгляд, подходы в построении архитектуры front-end приложений, а так же к чему пришли мы в ходе заказной разработки. Мы называем свой подход модульным и одинаково понимаем этот термин внутри команды. Он прост, местами банален и очень хорошо показал себя при разработке как мобильных приложений на React Native, так и front-end на Angular, React и не вижу проблем применять его на Vue. И поэтому договоримся сразу, что все описанное в первую очередь нужно рассматривать через призму front-end разработки

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

В итоге архитектура фронта зачастую скудна на практике, что-то более менее годное применяют IT гиганты, потому что деваться некуда, нужны микросервисы на фронте, сеньеры с испариной на лбу пишут код. А что делать остальным? Там пропасть - архитектура приложений React уровня tutorial для новичков: api, components, containers и т.п.

Надеюсь, ни у кого не подгорело и мы начнем.

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

Простота

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

Масштабируемость кода

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

Масштабируемость команды

Структура позволяет участникам команды работать над разделами проекта с определенной долей изоляции друг от друга. Например, коллега работает с фичей оплат, другой с пользователями, а третий - с общим модулем форм на проекте.

Универсальность

Структура и правила не должны зависеть от бизнес логики проекта, его тематики. Архитектура должна позволять быстро начать и не обосраться через 4 месяца разработки.

Удобная и быстрая навигация

Если мне нужно найти компонент, я сразу пойму где его искать. При этом, размер проекта не будет играть определяющую роль.

Components, Store, Containers

Термин “Container components” ввел Дэн Абрамов, когда придумал Redux. Простой и понятный подход, с него начинали все, кто изучал Redux. Примерами такого подхода пестрят многие туториалы по ReactJS.

Суть подхода:

Проект делится на компоненты, за исключением компонентов, которые имеют связь с Redux. Например, компонент авторизации если у него есть понятные входные и выходные данные будет обычным переиспользуемым компонентом, но как только мы подключили его к Redux, то есть отправляем какие либо actions из компонента или достаем данные из стора и используем в нем - он стал контейнером. Если у нас этот компонент лежал доселе в components, то теперь его отправят в containers.

Минусы подхода:

1. Горизонтальный рост папок components, containers
   Когда проект разрастается, растет и количество компонентов в каждой папке - components или containers. Есть решение - группировать компоненты по бизнес логике.
   
2. Лишние перемещения
   Как только мы подключаем к компоненту Redux, его нужно переместить в соответствующую папку containers. Если проект пестрит такими перемещениями, то архитектурно он построен неправильно или недостаточно удобно.
3. Элементы бизнес логики находятся в разрозненных местах
   В таком случае я привожу метафору как мы размазываем 5 грамм масла на 2-х метровый кусок батона. Тоже самое происходит с нашей бизнес логикой. Например, у нас на проекте появился блог. Появляется api для загрузки, интерфейсы описывающие сущности, компоненты, страницы и навигация. Бизнес сущность одна, а мест где она представлена - много. Работать с этим сложнее, когда проект разрабатывается командой и ежегодно растет по кодовой базе.
   
   

Atomic Design

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

Суть подхода:

Для компонентов придумали правила для их группировки, не по бизнес логике, а по их сложности. Подход выделяет следующие группы компонентов:

1. Атомы
   Базовые элементы, которые дальше не делятся: кнопки, ссылки, элементы текста.
   
2. Молекулы
   Это компоновка атомов. То есть молекулы переиспользуют атомы. Например, группа кнопок или кнопка + текст, которые можно переиспользовать дальше.
   
3. Организмы
   Компоновка молекул и атомов в более сложные интерфейсы или фичи. Например форма для расчета стоимости проекта, в которой есть кнопки или составные из молекул, элементы.
   
4. Шаблоны
   Это layout’ы, которые представляют собой правила расположения элементов внутри. Могут содержать любые элементы: атомы, молекулы, организмы.
   
5. Страницы
   Элемент навигации, который содержит шаблон, по которому располагается контент внутри.
   

Минусы подхода:

1. Сложно
   Заставить себя выучить всю эту историю
   
2. Бесконечные споры
   О том, где проходит четкая граница между группами компонентов
   
3. Перемещение компонентов
   Компоненты все так же могут перемещаться между группами при изменении их степени сложности
   

Feature Oriented

Отдельно упомяну, что в сообществе встречается так называемый Feature Oriented подход. Несложно догадаться, что он строится вокруг фич приложения. Можно нагуглить много примеров на эту тему, кто-то называет их модулями.

Суть подхода:

Основной для разделения проекта на компоненты является не их техническое происхождение, а бизнес логика. Что‑то это напоминает, неужели Domain Driven Design (Привет, Эванс). Но мы уже создавали папки posts и users в самом первом подходе про Components и Containers, так в чем разница? Отличие как раз в основе разделения. То есть мы не группируем по папкам users и posts, когда компонентов в общей папке components стало слишком много, мы создаем отдельные модули или фичи users и posts, а внутри них будет находиться все что относится к этим модулям. Наглядно - на рисунке ниже.

Минусы подхода:

Непонятно что внутри
В целом подход неплохой. С верхним уровнем более менее ясно, что творится внутри фичи - каждый сам себе художник и "лепит" как знает.

И следом приложу пример структуры по папкам на таком проекте.

Feature sliced design

Архитектурная методология для front-end проектов, разработка свежая - 2021 года. Собрались хорошие ребята, учли ошибки, которые уже давно научились избегать в архитектуре на бэкенде и придумали как их решать на фронте. Ссылка на проект здесь.

Суть подхода:

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

Минусы подхода:

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

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

Модульный подход GetGain или "Наш велосипед"

Глобально основывается на понятии модули и подходе Domain Driven Design. Внедрили мы его примерно в 2017-2018 году.

Модули

Суть в уже знакомом делении проекта на модули / фичи. Создаем папку modules, если есть пользователи, посты, какой нибудь конструктор сценариев, то появляются модули users, posts, scenarios-constructor. Все просто. Конечно есть shared модули и конечно мы взяли некоторые фишки из Feature Sliced Design, например public api, но об этом ниже.

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

Функциональность не всегда означает бизнес логику. Существуют функциональные или инфраструктурные модули, такие как core, ud-ui (общие компоненты), не привязанные к бизнес логике.

Domain Driven Design

Внутри модуль состоит из простых уровней. Подход и некоторые элементы, правила подсмотрены у Эрика Эванса (Domain Driven Design) и интерпретированы на front-end: domain, store, ui.

У каждого слоя модуля есть ограничения, он не может иметь доступ и использовать код с уровня ниже (напоминает Feature Sliced Design).

И пример структуры реального проекта

Другие фишки в модульном подходе

Public API

Удобно и подсмотрено в feature sliced design. Например, у нас есть модуль для работы с файлами, а именно их загрузкой. В модуле создается файл index.ts, который экспортирует наружу все, что разрешено использовать. Таким образом модуль решает каким будет интерфейс его использования, можно изолированно работать с этим модулем и не ломать API, не натыкаться на side effects и лишние ошибки. Как это может выглядеть:

Файл index.ts

Пример использования

Libs

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

Выглядит как костыль, в чем же смысл? Мы занимаемся заказной разработкой, нам важна скорость и предсказуемость в повторяющихся кейсах, потому что мы ни раз уже потратили время на их разработку, тестирование и стабилизацию. Разработчик возьмет уже протестированный сборник утилит (libs) с другого проекта. Если предыдущий опыт не учел особенностей текущего проекта, или появились новые поводы для создания библиотек - допишет. Но он будет дописывать код, который уже создавался как кросс-проектный.

Через несколько таких итераций выделяются стабильные библиотеки, затем они дополнят общий npm пакет, который устанавливается на новых проектах.

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

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