Тема 2/5: Микрофронты для существующего стека → Урок 6/6
Паттерн Backend for Frontend
В традиционных архитектурах фронтенд опирается на API общего назначения. Когда архитектура усложняется, эффективность такого подхода снижается.
При переходе на микросервисы и микрофронтенды команды всё чаще используют паттерн Backend for Frontend как альтернативу традиционному API. В этом уроке расскажем, что это, как работает и когда его стоит использовать.
Проблемы традиционного API в сложной архитектуре
В архитектуре с микрофронтендами классическое API — это зачастую неэффективный подход. Почему так — проще объяснить на примере.
Представьте, что вы разрабатываете онлайн-магазин «Шайба».
Как правило, компания переходит на микрофронтенды, когда в проекте уже есть микросервисы. Это логично: в этой точке приложение уже сложное, а разработчиков много.
Допустим, бэкенд «Шайбы» состоит из четырёх микросервисов:
Первые проблемы с общим API возникнут уже здесь. Каждый микросервис отдаёт свою часть данных. Фронтенду приходится заниматься агрегированием.
Но идём дальше. Чтобы всё приложение можно было разрабатывать по кусочкам, нужно уйти от монолитного фронтенда. Поэтому в «Шайбе» внедрили микрофронтенды.
Домашняя страница состоит из трёх микрофронтендов:
Допустим, вы разрабатываете первый микрофронтенд — корзину. Чтобы отобразить товары в корзине, вам нужно проверить, авторизован ли пользователь. Затем взять список товаров из корзины, взять описания товаров из каталога, показать их на странице корзины и отобразить итоговую стоимость.
В итоге микрофронтенд делает запросы:
- к сервису авторизации,
- к сервису корзины,
- к сервису каталога.
Фронтенд-разработчики, которые работают над корзиной, должны знать зависимости микросервисов. Иначе непонятно, у какого сервиса какую информацию запрашивать.
На практике это неудобно, потому что:
- Процесс разработки усложняется. Фронтенд-разработчики вынуждены следить за всеми изменениями в микросервисах. Команды начинают зависеть друг от друга — это нивелирует преимущества архитектурных решений.
- Код фронтенда усложняется. Каждый микросервис отдаёт лишь часть информации, которая нужна фронтенду. Приходится объединять данные на стороне фронтенда.
- Безопасность снижается. Если приложение работает с чувствительными данными, выносить логику на фронтенд опасно.
Эти проблемы и решает паттерн Backend for Frontend.
Что такое Backend for Frontend
📎 Backend for Frontend (бэкенд для фронтенда, BFF) — это подход к проектированию, при котором каждый фронтенд обслуживает специальный бэкенд.
BFF возник как часть концепции микросервисов. Чтобы абстрагировать фронтенд от сложностей бэкенда, решили создать промежуточный слой между фронтендом и внутренними сервисами. BFF отвечает за сбор информации от разных микросервисов, её обработку и доставку на фронтенд в удобном формате.
Изначально паттерн разработали, чтобы решить проблемы взаимодействия микросервисов с разными клиентами.
Пока забудем про микрофронтенды. Допустим, у приложения «Шайбы» есть два клиента — мобильное приложение и веб. Мобильное приложение принимает данные по протоколу REST API, а веб-приложение — по GraphQL.
В такой ситуации разработчикам бэкенда приходится учитывать потребности разных клиентов. Это усложняет разработку.
Проблема решается так: создают промежуточный слой, который обрабатывает запросы конкретного фронтенда, — BFF.
BFF тесно связан с клиентом и развёртывается вместе с ним. Вместо того чтобы напрямую вызвать метод API на сервере, клиент будет вызывать метод API на уровне BFF.
Паттерн можно реализовать с помощью любого технологического стека. Вы выбираете технологии, которые отвечают потребностям конкретного фронтенда. Мобильное приложение может вызывать методы BFF по протоколу REST API, а веб-приложение — по протоколу GraphQL.
В свою очередь BFF вызовет методы API на нужном сервере или серверах, извлечёт данные и выполнит все необходимые операции перед отправкой этих данных клиенту. Фронтенд получит готовую картинку.
Сфера применения BFF расширилась. Сейчас паттерн используют не только для того, чтобы адаптировать данные под требования разных клиентов.
Когда использовать BFF
Есть три типа архитектуры, когда стоит использовать BFF:
- Монолитный фронтенд и микросервисы. Здесь BFF помогает абстрагировать фронтенд от сложностей бэкенда.
- Несколько клиентов, которые используют разные технологии. У вас есть мобильное приложение, веб-приложение, настольное приложение (desktop) или любые два из них. Клиенты используют разные протоколы передачи данных, а это усложняет разработку бэкенда. В этой ситуации неважно — бэкенд монолитный или разбит на микросервисы.
- Микросервисы и микрофронтенды. BFF помогает настроить взаимодействие между ними. Автономность модулей повышается, если один микрофронтенд взаимодействует с одним бэкендом.
Первый сценарий относительно простой. Один фронтенд — один BFF. Последний запрашивает данные у микросервисов и обрабатывает их.
Второй сценарий мы уже рассмотрели.
Перейдём к третьему сценарию.
BFF для микрофронтендов
Одна из задач композитного слоя микрофронтендов — это взаимодействие с бэкендом. Всё чаще это делают через слой-посредник — BFF.
У каждого микрофронтенда — свой BFF. Его настраивают в соответствии с требованиями конкретного фронтенда. BFF агрегирует данные из нескольких бэкенд-сервисов, преобразовывает их в нужный формат и отправляет на фронтенд. Ещё можно настроить кэширование.
В итоге взаимодействие фронтенда и бэкенда выглядит так:
Преимущества BFF
Подход Backend for Frontend позволяет:
- Подготовить данные для конкретного фронтенда. Подгоняя ответы API под требования каждого фронтенда, вы снижаете необходимость дополнительной обработки данных на стороне клиента.
- Упростить логику на стороне клиента. BFF обрабатывает сложные логические операции на стороне сервера. Это относится к агрегации, композиции и преобразованию данных. Так вы снизите сложность кода фронтенда — он будет проще и удобнее в обслуживании.
- Увеличить производительность. С BFF вы передаёте меньше данных по сети, а фронтенд выполняет меньше запросов. Это значительно повышает производительность приложения. Как итог — оно будет удобнее для пользователей.
- Усилить безопасность. Вы можете использовать BFF как дополнительный уровень абстракции: аутентифицировать и авторизовывать здесь запросы пользователей перед передачей внутренним службам. Это повысит безопасность приложения.
Рекомендуем использовать BFF в архитектурах с микрофронтендами. Этот слой поможет оптимизировать производительность и убрать лишние зависимости от бэкенд-сервисов. Тогда приложение будет работать быстро, а разрабатывать его будет удобно.
Правда, есть один нюанс. Чтобы получить все преимущества BFF, его нужно спроектировать по определённым правилам.
Задание 3
Сопоставьте каждое преимущество использования паттерна Backend for Frontend (BFF) с его описанием.
Обработка чувствительных данных на сервере снижает риск утечки
Повышение безопасности данных
BFF позволяет обрабатывать чувствительные данные на сервере, что снижает риск утечки данных и повышает безопасность приложения.
Агрегация данных на сервере снижает количество запросов от фронтенда к бэкенду
Улучшение производительности за счет уменьшения числа запросов
BFF агрегирует данные на сервере, что уменьшает количество запросов от фронтенда к бэкенду, снижает объём передаваемых данных и улучшает производительность приложения.
Перенос логики обработки данных на сервер упрощает код на стороне клиента
Упрощение логики на стороне клиента
BFF переносит логику обработки данных на сервер, что упрощает код на стороне клиента и облегчает его поддержку и развитие.
Возможно использовать различные технологии на стороне клиента без изменений на стороне сервера
Независимость от конкретного фреймворка фронтенда
BFF в первую очередь фокусируется на взаимодействии между фронтендом и бэкендом, а не на улучшении взаимодействия между микросервисами.
Что важно учесть при дизайне BFF
- Подберите оптимальный технологический стек. Выберите технологический стек так, чтобы он был совместим с технологией фронтенда и легко обрабатывал необходимые взаимодействия с бэкендом.
- Внедрите стратегии кэширования. Чтобы улучшить время отклика и снизить нагрузку на внутренние сервисы, нужно внедрить механизмы кэширования.
- Разработайте систему обработки ошибок. BFF нужна надёжная система обработки ошибок. Иначе ошибки, которые возникли в BFF при работе с бэкенд-сервисами, повлияют на работу фронтенда.
- Внедрите мониторинг и ведение логов. BFF — это критически важный компонент архитектуры. Чтобы быстро обнаружить и устранить проблемы, нужно внедрить комплексный мониторинг и протоколирование.
Итоги
Традиционный API — не лучшее решение для архитектур с микрофронтендами и микросервисами. Такой подход усложняет разработку фронтенда. Фронтенд-разработчикам приходится следить за всеми изменениями в микросервисах, код фронтенда усложняется, а безопасность приложения, напротив, — снижается.
Вместо традиционного API лучше использовать паттерн Backend for Frontend. Сокращённо — BFF. Это подход к проектированию, при котором каждый фронтенд обслуживает специальный бэкенд.
BFF используют в трёх вариантах архитектур. Он подойдёт, если у вас:
- монолитный фронтенд и микросервисы,
- несколько клиентов, которые используют разные технологии,
- микросервисы и микрофронтенды.
С микрофронтендами паттерн используют так. У каждого микрофронтенда — свой BFF. Его настраивают в соответствии с требованиями конкретного фронтенда. BFF агрегирует данные из нескольких бэкенд-сервисов, преобразовывает их в нужный формат и отправляет на фронтенд. Может ещё и кэшировать.
Backend for Frontend позволяет настроить данные для конкретного фронтенда, упростить логику на стороне клиента, увеличить производительность и усилить безопасность приложения.
Чтобы паттерн дал максимум пользы, при проектировании BFF надо учесть четыре момента:
- подберите технологический стек, который будет совместим с фронтендом и сможет взаимодействовать с бэкендом,
- внедрите стратегии кэширования,
- разработайте систему обработки ошибок,
- внедрите мониторинг и ведение логов.
Вот и всё! Это последний урок первой темы. Дальше перейдём к бэкенду — расскажем, как разбить монолит и какие технологии стоит использовать.