Архитектура фронтенд приложений

Архитектура фронтенд приложений

По сути архитектура - это то как мы раскладываем файлы по папкам, и насколько удобно потом с этим работать.

Существует множество различных приемов и видов архитектур фронтенд приложений.

Мы рассмотрим основные три вида архитектур которые встречается на практике.

Архитектура без архитектуры

Это просто набор файлов и папок, беспорядочно расположенных на сервере без какой-либо логики, к примеру набор папок:

pages
api
components
assets
utils
core
widgets
public
etc
docker
tools
src
http

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

Можно сделать вывод.

Структура папок в проекте не задает его архитектуру.

Например, у нас есть набор страниц сайта:

Страница 1
Страница 2
Страница 3

И компоненты сайта:

Компонент 1
Компонент 2
Компонент 3
Компонент 4
Компонент 5

И вот например Страница 1 вызывает Компонент 2, вроде бы все нормально, и логично.

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

Компонент 1
  Компонент 4
    Компонент 5
     Компонент 1
Компонент 3
  Компонент 1
    Компонент 2 
Компонент 5
  Компонент 2
    Компонент 4 
      Компонент 1  
        Компонент 5
         Компонент 2          

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

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

ChangeApplication
ChangeApplication2
ChangeApplication3
ChangeApplication4

или так

GetProfileUserForOne
GetProfileUserForManyClient1
GetProfileUserForManyClient2
GetProfileUserForManyClient3

То есть, здесь не понятно к чему привязан компонент, и какой следует использовать.

Явных модулей не выделено, стандартизации нет, хаотические связи.

Когда это может понадобиться

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

Самое главное, чтобы проект был без длительной поддержки иначе - это превратиться в ад поддержки.

Модули

Идем дальше, теперь посмотрим на модульную архитектуру проекта.

Могут быть выделены слои, но не папки!

Например, может быть следующая структура проекта:

pages - страницы
    MainPage
        api
        components
modules - самостоятельные и самодостаточный модули, их можно использовать в любом проекте
    Article
    Blog
    RegistrationForm
    BlogComment
        index.ts
        components
        constant
        helpers
        modules
        api
components - куски кода которые могут быть подключены в модулях, могут иметь бизнес логику
    CommentTable
    UserProfile
    CardTable
UI - кнопки, селекты, инпуты. Эти компонеты можно переиспользовать. Не могут иметь бизнес логику
    button
    select
    input
    table

В нижестоящих слоях нельзя использовать код в слоях выше, то есть поток данных будет направлен вниз

Особенности модульной архитектуры

• modules должны решать одну конкретную задачу.
• Наружу из модуля должен быть доступ только к предусмотренным разработчиком вещам, это и есть изоляция.
• Модуль может быть очень сложный, состоять из тысячи файлов.
• На слое pages должно быть перечисление модулей и компонентов.
• Слой modules это самодостаточный функционал готовый к использованию.
• components могут использовать на pages, как отдельная вещь не принадлежащая не к одному модулю
• Слой UI - это компоненты которые можно использовать на уровнях выше.
• Один модуль не может использовать внутри себя другой модуль.
• Модуль можно легко удалить, он не затронет другой функционал.

Так же можно выделить недостатки данного подхода:

• Где хранить вот этот код console.log(123), в модуле, в компоненте, может в api. Не всегда понятно.
• Если нужно использовать один модуль в другом.
• Глобальные свалка файлов никуда не денется, со временем тоже будет то же самое как с подходом без архитектуры.

Уже лучше, но все же это не то.

Feature Sliced Design

FSD - на данный момент лучшее решение для фронтенда.

Составляющие:

• слой - набор папок верхнего уровня их число ограничено
• слайс(модуль) - модуль примерно как в модульной архитектуре
• сегмент - составляющие модуля

app
    index.tsx
processes
    ManyRegistration
pages
widgets
    Header
    Sidebar
    MainCard
features
    RegisterFromEmail
    ChangePhone
    SendEmail
entity's
    User
        UI
        model
        lib
        config
        api
        consts
    Order
    Blog
    Contract
    Application
shared
    Modals
    Button
    Select

Особенности

• Каждый слой обладает своей зоной ответственности.
• Слой ниже не может использовать слой выше.
• Линейный однонаправленный поток данных.
• Чем ниже расположен модуль, тем сложнее вносить изменения в него.
• shared - Максимально пере-используемый код
• entity's - Бизнес сущности приложения, могут и не быть
• features - Пользовательские use cases, могут и не быть
• widgets - блоки страниц, используемые самостоятельные
• pages - страницы приложения
• processes - процессы над страницами, может и не быть
• app - логика приложения

Если абстрактно представить набор слоев, то можно изобразить так:

shared
    Макеты коробок
    Общий пере-используемый код
entities
    Коробки
    Бизнес-сущность
features
    Управление коробками 
    Действие пользователя   
widgets
    Ящики из коробок
    Блок с действиями
pages
    Расстановка ящиков
    Конкретная страница
app
    Инициализация        

Что это нам дает

• Явные однонаправленные связи
• Стандартизация решений
• Каждый слой своя зона ответственности
• Такую архитектуру легко освоить
• Масштабирование решений
• Не зависит от фреймворка

Об методологии Feature Sliced Design напишу отдельную статью, так как это обширная тема.

При должном внимании и умении даже из плохой архитектуры можно сделать хорошую!