13 мая 2021
Блог
Backend-for-Frontend: когда простого API не хватает
Подход Backend-for-Frontend (BFF) разработали в компании SoundCloud. Pуководитель департамента разработки SoundCloud Фил Калсадо (Phil Calçado) ещё в 2015 году описывал BFF как закономерный этап эволюции, которую прошли современные ИТ-продукты.
В прошлом, аналоговом мире корпоративными системами пользовались только сами компании. Чем больше развивалась цифровизация и омниканальность, тем больше фокус перемещался из корпоративной инфраструктуры вовне. Покупатели стали покупать товары онлайн и со смартфонов, бизнес-партнёры – взаимодействовать с компанией через веб-платформы. Бизнесу стало важно выстроить такую архитектуру, которая позволила бы открывать такой доступ к корпоративным ресурсам.
Разработчики начали создавать API, чтобы сторонние ИТ-сервисы могли подключиться к инфраструктуре. Недостаток этой технологии в том, что она предлагает всем один и тот же набор возможностей. Если вам нужно ограничить объём трафика на смартфонах, а пользователям планшетов предложить собственный метод ввода данных, могут начаться трудности.
Ещё сложнее была задача SoundCloud – компании нужно было интегрироваться со сторонними разработчикам, чтобы те могли встраивать плеер в свои площадки. Для этого API из коробки должно взаимодействовать с любыми платформами, а при каждом обновлении команде нужно убедиться, что доработка не сломает все эти интеграции. На практике этого добиться нереально.
Так и родилась концепция Backend-for-Frontend – легковесного сервиса, который лежит ближе к фронтенду, чем к бэку.
Возможности BFF
Ключевое слово – «легковесный», список возможностей у BFF гораздо меньше, чем у API:
- Работать с микросервисами продукта и получать от них данные.
- Форматировать эти данные, чтобы они корректно обрабатывались на фронтенде.
- Отправлять данные фронтенду.
Компания может параллельно поддерживать несколько BFF: для пользователей на ПК, для Android, для iOS и т.д. А с точки зрения разработчиков главные преимущества – это избавление от многих технических ограничений бэкенда и ускорение выпуска фич:
- Можно строить бэкенд и API от выстроенного клиентского пути и продукта, а не наоборот.
- Можно уже на ранней стадии разработки согласовать контракт взаимодействия и сделать мокап, чтобы строить приложение, вызывая API.
- Становится проще управлять доступом мобильного приложения к бэкенду.
Сейчас BFF в своей практике используют многие крупнейшие технологические компании – например, Netflix и Flickr. Его рекомендуют Microsoft и IBM. Мы поделимся своим опытом из одного из недавних проектов.
Как мы используем BFF
В одном из наших мобильных приложений основным ресурсом для всех сервисов со стороны заказчика выступает сайт. За ним находится шина RabbitMQ, которая подхватывает с сайта входящие события и возвращает результат запросов.
У сайта есть API, но для мобильного приложения его функций не всегда хватало. Не углубляясь в детали, скажем, что это примерно те же трудности, о которых мы писали выше. Поэтому, когда мы запускали в приложении продажу нового продукта, мы построили собственный BFF, чтобы обрабатывать его запросы. В итоге мы можем сами отправлять сообщения Rabbit-у и читать его ответы.
Такая архитектура ускоряет обновление данных в нашем продукте, которые периодически возникали при работе через API. Раньше наш продукт получал данные из собственной БД интернет-магазина, и при работе напрямую с Rabbit просто так обновить данные было невозможно. С внедрением BFF мы запустили новый модуль Data Provider, которая позволяет не ходить в ИМ за обновлениями информации.
Вдобавок, так мы смогли организовать работу асинхронного API заказчика с нашим синхронным сервисом – логика BFF позволяет дождаться, пока обработаются все запросы, прежде чем передавать данные нашему продукту. А когда в перспективе заказчик решит своё API обновить, с нашей стороны доработки потребуются минимальные – просто переориентировать BFF на новые условия.
О чём нужно помнить, создавая BFF
BFF-сервис должен быть лёгким – в этом его главное отличие от API. Не надо прописывать в коде сложную бизнес-логику, строить БД и т.д. Приоритетом должен быть простой обмен данными.
Как мы говорили, у продукта может быть несколько BFF-сервисов под разные клиенты. Они неизбежно будут в какой-то части друг друга дублировать, но нужно следить, чтобы это не выходило за рамки разумного, иначе вы будете тратить лишние ресурсы на их поддержку.
Нужно понимать, что BFF – это что-то вроде переводчика между бэкендом и фронтендом. Поэтому безопасность, отказоустойчивость, мониторинг нужно выстраивать дополнительно.