Привет. Я фронтенд-разработчик. По мнению тех, кто, по мнению некоторых, перекладывает джейсончики туда-сюда, я крашу кнопочки. Но сам я себя идентифицирую иначе: я тоже перекладываю джейсончики, и у меня всё точно так же, как у них. Даже архитектура. У меня тоже есть контроллеры, сервисы и хранилища, и я также обрабатываю запросы пользователей. Даже больше, я делаю HATEOAS, «тру» RESTful, если хотите. Давайте расскажу, как я к этому пришёл.

Как я стал бэкендером во фронтенде

Когда-то давно я только верстал. Накидывал разметку, добавлял классы, идентификаторы и стилизовал CSS-ом. И было хорошо. Потом от меня потребовали динамичности — пришлось добавить JavaScript. И было очень хорошо. Мне всё время хотелось пробовать что-то новое, потому что технологии быстро развивались. Я попробовал AJAX. Это было так волнительно... Я сказал бэкендерам: основную разметку жду от вас, а опции для выпадающего списка, например, отдавайте джейсоном по запросу. Они были не в восторге. «Одному HTML подавай, другому CSV, третьему ещё что-то — безобразие!» Но мы нашли компромисс. Бэкендеры сказали: «Вот вам, мол, джейсон, дальше сами как-нибудь». И назвали это REST API.

Сначала было очень круто! Мы, верстальщики, организовались. Мы стали фронтендерами! Конечно же, мы сразу побежали решать ещё не решённые много раз решённые задачи. Мы писали библиотеки и фреймворки — четыре миллиона штук! Да у нас даже есть библиотека с функцией для умножения чисел! Мы придумывали свои паттерны и архитектуры. Короче, мы стали очень крутые.

Но то уже были «мы», а не я. Мне было сложно. Шутка ли, изучать по одному новому фреймворку в неделю? А ведь ещё переписывать всё надо, стек-то устарел... В общем, в какой-то момент я перестал поспевать за модой и справляться со сложностью. Переходишь из проекта на React в проект на Vue — а там всё иначе. Берёшь нового разработчика в команду с опытом в React, а ему нужно время, чтобы вникнуть, потому что в его предыдущем проекте, тоже на React, был другой «стейт-менеджер» и совсем другой код. Вавилон. Никто друг друга не понимает.

Почему фронтендеры говорят на разных языках

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

Когда-то было так: набираешь URL, сервер получает запрос, формирует HTML, браузер показывает. Всё. Но что такое этот HTML? Удивительно, но HTML — это hypermedia. Естественная реализация HATEOAS, задолго до того, как этот термин появился. Вот пользователь открыл страницу заказа, например. Сервер вернул HTML, а в нём уже зашито всё, что можно сделать дальше: ссылка на детали, кнопка «Отменить», форма с method="POST". Браузер не знал заранее, что будет доступно — состояние пришло вместе с доступными переходами. Это и есть HATEOAS. То же самое можно выразить джейсоном, например в HAL:

{
  "id": 42,
  "status": "pending",
  "_links": {
    "self":   { "href": "/orders/42" },
    "cancel": { "href": "/orders/42/cancel", "method": "POST" },
    "detail": { "href": "/orders/42/detail" }
  }
}

То есть клиент, в нашем случае браузер, не хардкодит URL-ы и не знает бизнес-логику заранее. Он смотрит, что сервер разрешил сделать в этом состоянии, и рисует соответствующий UI. Формула существовала всегда, задолго до появления фреймворков вроде React, а стейт для браузера — это HTML + окружение. Положение курсора на экране, выбранный размер шрифта или цветовая схема в настройках ОС и многое другое — это всё стейт. Раньше ту часть стейта, которая не относится к окружению, — фрагмент HTML — мы отдавали браузеру с удалённого сервера сразу целиком, сейчас с локального и частями. Мы перенесли во фронтенд то, что раньше выполнялось на бэкенде, но не переняли архитектурную дисциплину, и поэтому говорим на разных языках.

Почему фронтенд это сервер

Строя композицию из React или Vue компонентов, мы на самом деле описываем правила, по которым будут сформированы шаблоны, которые будут возвращены пользователю в ответ на какой-то запрос. Компонент получает один тип данных и трансформирует в другой, он буквально ResponseMapper. Результат этой операции — описание того, какой фрагмент HTML нужно сформировать. Тот фрагмент HTML, который будет сформирован, уже не содержит условных выражений, циклов и т.д. — только часть представления и доступные действия.

То есть всё, что мы делаем, используя обширный словарь «фичеризмов» (SPA, SSR, CSR и прочее), — не более чем формирование ответа на запрос пользователя в виде понятной браузеру разметки. REST-сервер, развёрнутый на клиенте: отдали разметку и ждём следующего запроса пользователя (ввод текста или клик), и, получив его, повторяем процесс. Фреймворки вроде React, Vue и Solid позволяют нам эффективно стримить HTML в браузер.

Если то, что мы в действительности делаем, не так уж радикально отличается от того, что делают бэкенд-разработчики, значит, у нас больше общего, чем мы думали, и мы можем перенять их опыт. У них всё как-то стабильнее... Сложно найти двух бэкендеров, спорящих, например, о том, кто должен валидировать параметры запроса — контроллер или сервис. А у нас сторы, стейты, композаблы и руны, то есть всегда есть о чём поспорить. 😎

Но я отвлёкся, давайте продолжим с аналогиями. Классический REST-сервер работает так: запустился, слушает входящие HTTP-запросы. Получил запрос — обработал, вернул ответ, забыл. Основное взаимодействие с «акторами» через HTTP Request. В бэкенде, независимо от языка программирования, сущность, обрабатывающая запросы, называется контроллером, и этот термин знаком всем. У контроллера чёткие архитектурные границы и ответственность.

Внешняя архитектурная граница — протокол (окружение). Контроллер «понимает» заголовки, куки, методы (GET/POST) и тело запроса. Внутренняя граница — бизнес-логика. Контроллер не содержит бизнес-правил, а взаимодействует с сервисным слоем через интерфейсы и DTO.

А ответственность — сопоставить путь с конкретным методом, проверить входящие параметры, преобразовать в DTO и передать в нужный сервис. Полученный ответ или ошибку преобразовывать в сущности протокола, например исключение в HTTP код, а доменную сущность в JSON.

Другие слои REST-сервера также ярко выраженные:

Backend

  웃  →  Request → Controller → Service → Repository  → → → → → → Database
  │     │         │            ↑         │                               │
  │     │         │            │         └─ Builds SQL                   │
  │     │         │            │                                         │
  │     │         │            └─ Business logic                         │
  │     │         │                                                      │
  │     │         └─ Extracts, validates & maps to DTO                   │
  │     │                                                                │
  │     └─ Environment detail - HTTP Request, Kafka message e.t.c        │
  │                                                                      │
  │                                                                      │
  │                                                                      │
  └─  ← Response ← Controller ← Service ← Repository  ← ← ← ← ← ← Database
        │          │                      │
        │          │                      └─ Maps to Domain Model
        │          │                             
        │          └─ Maps to environment format: HTTP/Kafka/gRPC Response
        │
        └─ Environment detail

Event = Request

Во фронтенде мы тоже «запускаемся» и «слушаем» запросы, а любой запрос пользователя к нам выражается событием, то есть для нас Event = Request. Как же мы называем сущность, которая обрабатывает эти запросы? Да как угодно — хук, стор, стейт, композабл, вью модель и т.д. Целое разнообразие терминов, подразумевающих разную ответственность и архитектурные границы. То есть мы перенесли во фронтенд то, что раньше выполнялось на бэкенде, и это не плохо, но мы не перенесли термины. Конечно, во фронтенде есть свои особенности, но и в бэкенде они есть. Тут CSS, LocalStorage и WebSockets, там SQL, S3 и Kafka. Детали разные, архитектура — одна:

Frontend
  
  웃  →  Event   → Controller → Service → Repository  → → → → → → Rest API
  │     │         │            ↑         │                               │
  │     │         │            │         └─ Builds HTTP Request          │
  │     │         │            │                                         │
  │     │         │            └─ Business logic                         │
  │     │         │                                                      │
  │     │         └─ Extracts, validates & maps to DTO                   │
  │     │                                                                │
  │     └─ Environment detail - Browser Event                            │
  │                                                                      │
  │                                                                      │
  │                                                                      │
  └─  ← Response ← Controller ← Service ← Repository  ← ← ← ← ← ← Rest API
        │          │                      │
        │          │                      └─ Maps to Domain Model
        │          │                             
        │          └─ Maps to framework format: JSX/Vue template
        │
        └─ Automatically mapped to HTML chunk from JSX by framework

Вы можете возразить, что стейт, стор или композабл это stateful, а REST-контроллер stateless, поэтому термин не подходит. Да, обычно на сервере один контроллер обрабатывает множество запросов от разных пользователей, поэтому stateless эффективнее. Но есть области где наоборот, например геймдев, IoT, WebSockets, gRPC streams. Там контроллер stateful, потому логика переходов между состояниями сложная, а гнать полный контекст с каждым запросом слишком дорого. Фронтенд — как раз такая область.

Хуки, атомы или сигналы — это инфраструктурная деталь. То, что требует сам фреймворк для выполнения своих задач. Мы их наделили избыточной ответственностью и позволили расползтись по коду. Сторы, стейты и композаблы подаются как более «чистый» слой управления состоянием, якобы отделённый от UI, но на деле лишь маскируют протекшие абстракции. Безобидное на первый взгляд создание собственных терминов в относительно новой области — фронтенде — привело в итоге к хаосу.

Архитектурная дисциплина

Стоит отметить, что в бэкенде тоже был хаос, а их среда также как и наша позволяет творить что угодно – лезть в БД из контроллера или передавать HTTP Request в репозиторий. Их архитектурная зрелость и дисциплина результат формальных договоренностей а не ограничений среды исполнения.

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

Любопытно, что создатель REST, Рой Филдинг, предвидел это с самого начала:

An interesting observation about network-based applications is that the best application performance is obtained by not using the network. This essentially means that the most efficient architectural styles for a network-based application are those that can effectively minimize use of the network when it is possible to do so, through reuse of prior interactions (caching), reduction of the frequency of network interactions in relation to user actions (replicated data and disconnected operation), or by removing the need for some interactions by moving the processing of data closer to the source of the data.

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

• Фронтенд — это REST-сервер.

• UI-фреймворк — инфраструктура со своими слоями.

• Компонент фреймворка — маппер из DSL (JSX/template) в лёгкое промежуточное представление, эффективное для вычисления дифа.

Сам компонент не работает напрямую с DOM. Сформированное им промежуточное представление превращается в HTML-чанк и стримится точечно в нужный DOM-узел в другом слое, скрытом от нас фреймворком. Мы могли бы стримить этот HTML с удалённого сервера, но делать это в браузере налету — просто эффективнее.

Теперь, когда мы определили, чем на самом деле занимается фронтендер, мы можем более чётко очертить границы архитектурных слоёв в своих приложениях, а главное — говорить на одном языке. Или хотя бы начать дискутировать по существу.

P.s. В этой части я намеренно не привожу примеры кода, это увело бы дискуссию из обсуждения концепции – совсем другую в сторону. Пример реализации будет в следующей части.

Ссылки:

Dewayne E. Perry, Alexander L. Wolf – Foundations for the Study of Software Architecture (1992) [PDF]
Conal Elliott, Paul Hudak – Functional Reactive Animation (1997) — [PDF]
Roy Fielding – Hypermedia as the Engine of Application State (2000) — [PDF]
Roy Fielding – Architectural Styles and the Design of Network-based Software Architectures (2000) – [PDF]
Evan Czaplicki – Concurrent FRP (2012) — [PDF]