У аббревиатуры BFF кроме Backend for Frontend есть и другая расшифровка — Best Friends Forever. И в контексте статьи это только отчасти шутка. Общение фронтенда и бэкенда не всегда происходит гладко (опустим тот факт, что существует множество мемов о противостоянии фронтендеров и бекендеров): клиент запрашивает данные, бэкенд отдаёт то, что запросили, но часто данных сильно больше, чем нужно, а это значит, что запрос будет возвращаться дольше, фронтенд будет отрисовываться тоже дольше и всё это отразится на опыте конечного пользователя.

А что если между фронтендом и бэкендом построить мостик, который распределит нагрузку и сделает всех дружелюбнее? Примерно в этом и состоит суть паттерна BBF, а в статье разберём подробнее: зачем его внедрять и какую роль он играет в масштабировании современных сервисов; как мы реализуем этот подход в рамках RUTUBE, какой профит он нам даёт; почему мы отказались от GraphQL; в чём отличия от API Gateway и как вообще проектировать такие сервисы.

Меня зовут Максим Ульянов, я руковожу отделом веб-разработки в RUTUBE, отвечаю за все браузерные интерфейсы: сайта rutube.ru, студии блогеров studio.rutube.ru, всех сателлитов и внутренних продуктов платформы. В свободное время я веду подкаст «Куда расти?» и Telegram-канал ULYANOV.LIFE. Этот материал написан по мотивам моего доклада на FrontendConf.

Предыстория, или Зачем нужен BFF 

Изначально архитектура веб-сервисов (тогда они еще были сайтами) была простой и строилась по принципу монолита: один бэкенд напрямую общается с единой клиентской частью с одной стороны, и с базой данных — с другой.

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

Backend for Frontend или BFF — архитектурный паттерн, который предполагает создание отдельного бэкенда под каждый фронтенд (клиентский интерфейс или приложение). Его задача — собирать и проксировать данные, необходимые для конкретного клиента. 

Термин Backend for Frontend появился в SoundCloud в 2013 году. Тогда их сайт выглядел примерно так:

На примере SoundCloud посмотрим, как идет развитие сервисов от монолита к микросервисам — в данном случае к архитектуре BFF. 

Основная проблема, которую решали в команде, заключалась в том, что существующая монолитная архитектура очень ограничивала скорость развития сервиса: мешала проводить A/B-тесты на разных платформах, реализовывать редизайн и быстро выкатывать обновления.  

Самая простая архитектура схематично изображена на следующей картинке слева: есть клиенты, например, веб, iOS, Android и партнёрские приложения, которые завязаны на один бэкенд. В таком случае бэкенд должен готовить данные для всех клиентов, учитывать особенности каждого из них и реализовывать все специфичные сценарии. 

Если же вы хотите быстрее развиваться и тестировать гипотезы на отдельных приложениях — на схеме справа это iOS и Android — а также проводить A/B-тесты и готовить разные наборы данных для разных клиентов, то для этого можно создать отдельный сервис, который будет называться Backend for Frontend. BFF с точки зрения данных будет завязан на всё тот же монолит, но при этом iOS- и Android-приложения будут получать данные через него, а не напрямую от бекенда. BFF будет передавать только те данные, которые нужны в данный конкретный момент времени и в той структуре, чтобы снизить количество операций при подготовке данных на клиенте и быстрее отрисовать интерфейс.

Можно пойти дальше и заменить в этой схеме монолитный бэкенд на Public API и постепенно реформировать то, что скрывается за фасадом: распиливать монолит, добавлять (микро)сервисы и т.д. Либо можно добавлять отдельные модули под конкретный BFF. 

Такая архитектура позволяет постепенно эволюционировать и добавлять отдельные, независимые BFF под каждый клиент, постепенно отрезая куски от монолита, а за ними реализовывать контроллеры и shared-утилиты, которые могут переиспользоваться между разными BFF. 

Эта архитектура в первую очередь направлена на то, чтобы обеспечивать хороший time to market клиентских приложений.

Так развивалась архитектура SoundCloud и это отчасти похоже на путь RUTUBE. 

Контекст RUTUBE

Посмотрим на страницу с плеером RUTUBE. На первый взгляд она выглядит достаточно просто и кажется, что её легко заверстать и она может жить на монолите.

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

Также у нас есть серийный контент, на странице с которым показывается список сезонов и серий. 

А ещё есть трансляции блогеров и телеканалов c чатом и переключением между эфирами. 

Страницу отдельного видео можно поделить на смысловые блоки: само видео, которое мы запрашиваем чанками, чтобы в реалтайме подстраивать качество стриминга; информация о видео; настройки и пр. Чтобы отрисовать только блок с плеером, необходимо опросить разом девять API. 

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

Всё усложняется ещё тем, что у RUTUBE сейчас более 17 млн ежедневных пользователей и более 400 млн единиц контента — сервис высоконагруженный и должен быть рассчитан на масштабирование. 

Эволюция BFF в RUTUBE

RUTUBE — сервис с 19-летней историей, за это время веб-технологии сильно изменились, и архитектуру сервиса, естественно, требовалось перестраивать под актуальные задачи и подходы. Большая часть кодовой базы сейчас не старше 2022-го, но при этом, естественно, все изменения происходили постепенно: мы заменяли устаревшие решения одно за другим, уходя от монолита и переключаясь на более гибкие схемы. 

Ниже — примерная архитектурная схема RUTUBE. В ней более 120 микросервисов и оставшиеся ещё легаси-элементы, сложно связанные между собой. 

BFF как подход помогает нам перестраиваться, но 3,5 года назад ему тоже требовалось обновление. Когда я пришел в RUTUBE, BFF уже существовал, он был написан на Express.js, и там был in-memory cache, который кешировал данные на каждом конкретном инстансе приложения, запущенного в продакшене. 

Архитектура нашего BFF тогда выглядела стандартно: несколько ручек, описанных в контроллерах.

Данное решение было реализовано «на коленке» в качестве эксперимента и не было эталоном гибкости или надёжности. 

Например, мы собирались выкатить один A/B-тест и думали, что раз у нас есть BFF, сейчас всё будет быстро и здорово. Но в итоге та задача заняла порядка трех месяцев вместо пары недель! Тогда мы поняли, что надо что-то менять. 

Мы стали исследовать варианты и выяснили, что лучшим решением для организации Node.js-приложений является фреймворк Nest. У Nest сильное комьюнити и хорошая документация.

Мы используем многие классные инструменты, которые есть в Nest и, кроме того: 

• Redis для распределенного кэширования;

• RxJS для асинхронных операций;

• Fastify в качестве роутера вместо Express. 

Fastify мы взяли, потому что это самый быстрый на сегодняшний день Node.js роутер по количеству обрабатываемых запросов за секунду. 

В обновлённом BFF мы смогли добиться такой стабильности, что его захотели использовать и другие клиенты: мобильные приложения, Студия RUTUBE (приложение для авторов), Smart TV.  Поэтому сейчас наш BFF обслуживает 5 сервисов и выглядит следующим образом.

Здесь есть важный момент — насколько правильно с точки зрения архитектурного паттерна иметь один BFF для пяти клиентов? Чтобы BFF соответствовал своей изначальной идее — обеспечивать быстрый доступ к нужным данных для разных независимых клиентов — в Nest есть Workspaces. В результате сейчас у нас каждый сервис может разрабатываться и катиться полностью независимо, SLA всех клиентов, которые к нам обращаются, полностью соблюдается.

Таким образом BFF является центральным сервисом для агрегации и проксирования данных для всех наших клиентов. За ним стоят бэкенды, к которым мы обращаемся.

С точки зрения структуры модули нашего BFF организованы в концепции Nest: мы не стали «изобретать велосипед», действовали в соответствии с документацией фреймворка.

В модуле есть, разумеется, тесты, DTO-объекты, из которых впоследствии генерируются типы данных и которые мы можем переиспользовать, а также мапперы, которые нужны для обработки определённых запросов: 

Мы используем Swagger-документацию, которая автогенерируется из DTO-объектов. Её очень удобно передавать бэкендерам, тестировщикам и всем, с кем надо согласовать контракт.

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

Запрос за видео состоит из нескольких параллельных запросов и раскладывается в такую схему: 

• клиент отправляет запрос по одному конкретному URL;

• URL через балансер попадает на наш BFF-сервис;

• если ответ на этот запрос закеширован, то он автоматически отдаётся из кеша на клиент, не создавая дополнительной нагрузки на API;

• если в кеше ответа нет, то идём в API;

• полученный по API ответ кешируем в Redis с указанием временного ключа кеширования (ключи можно посмотреть на иллюстрации выше);

• далее прогоняем некоторые мапперы — это позволяет убрать часть бизнес-логики с клиента на сторону BFF и при этом предоставлять клиенту конститентные данные;

• отдаём данные через сервис на клиент;

• пользователь смотрит видео :)

Итого, суммируем, когда BFF нужен, а когда — это погоня за хайпом.

Когда BFF полезен:

• У продукта несколько клиентов. У нас это web, iOS, Android, Smart TV и ещё партнёры — нам необходимо поддерживать для них различную структуру данных.

• Частые изменения UI: A/B-тесты, быстрые MVP, редизайны.

• Нужно собрать много данных в один ответ. Как в примере выше, когда чтобы отрисовать страницу, нужно опросить 9-10 API ручек, то через BFF это будет сильно дешевле с точки зрения сетевых задержек.

• Требуется изоляция контрактов — то самое распиливание монолита и постепенная замена его на микросервисы. При этом есть возможность поддерживать на уровне BFF старые версии ручек, что очень важно для клиентов типа Smart TV и мобильных приложений, которые медленно обновляются и имеют очень длинный хвост поддержки. 

Когда BFF — хайп: 

• Если у вас всего один клиент, например, одно, пусть даже большое, SPA-приложение, то BFF не нужен. 

• Если все клиенты могут работать с универсальным API, то проще иметь public API вокруг монолита или микросервисов — неважно. 

• Если дополнительный слой не ускоряет работу и не упрощает контракты — этот слой, т.е. BFF не нужен.

• Если нет ресурсов на поддержку ещё одного сервиса, то он вместо пользы может превратиться в узкое горлышко. 

Best practices при проектировании BFF-сервиса

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

Один сервис — один ответственный

Это правило справедливо для большинства инфраструктурных сервисов и их поддержки. В нашем случае оно означает, что если при большом количестве разных клиентов, каждый из которых имеет свой бэклог, свои сроки и хочет работать стабильно, сделать один большой монолитный BFF, то это не даст никаких преимуществ. Разным клиентам нужны отдельные BFF — то есть свои ответственные.

У нас это устроено следующим образом: у нас в веб-отделе есть платформенная команда, это фронтендеры, которые умеют писать на Node.js, и именно они поддерживают BFF. А чтобы каждый конкретный сервис мог катиться отдельно, как уже говорилось выше, у нас есть Workspaces и конкретные договоренности по SLA со всеми клиентскими командами. 

Прозрачное логирование

BFF — так или иначе бэкенд-сервис и ему необходимо прозрачное логирование, чтобы мы понимали, что происходит.

У нас стандартный стэк: Kibana (интерфейс к данным в Elasticsearch) + Senry + Prometheus + Grafana. 

Выше скрин наших дашбордов, туда можно вывести все метрики жизнеспособности сервиса и быстро реагировать, если что-то идёт не так. 

Заголовки trace-id

Как мы помним, на одну страницу у нас опрашивается несколько ручек — если не подписать изначальный запрос, то будет трудно проследить дальнейшую цепочку.  

С trace-id через тот же самый интерфейс Kibana можно проследить весь поток запросов и то, какой сервис отдавал или принимал данные, какие были заголовки и т.д. Это позволит воспроизвести всю цепочку запросов для конкретной ручки конкретного клиента и понять, на каком из звеньев и в каком сервисе произошла ошибка.

Передать сервис в службу мониторинга

Очевидная штука: это бэкенд-сервис, если за ним не следить, то можно слишком поздно узнать о проблемах. Для продукта с миллионами пользователей это недопустимо.

Распределённый кеш

Выше я уже говорил, что в первой, экспериментальной версии нашего BFF был in-memory cache Проблема заключалась в том, что у RUTUBE несколько ЦОДов и много инстансов сервисов, чтобы выдерживать нагрузку и горизонтально масштабироваться. Кеширование данных в памяти на конкретном инстансе приводит к тому, что они становятся неконсистентными. Чтобы обеспечить валидные данные для наших пользователей при перезаходах и обновлениях страниц, а так же, чтобы не плодить лишнюю нагрузку на бэкенды, необходим распределенный кеш. В данном случае мы выбрали Redis.

Договориться об SLA с клиентскими командами

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

BFF и GraphQL

Возможно, вам сейчас кажется, что описанная в статье схема работы с данными похожа на ту, что есть в GraphQL. Действительно, GraphQL и BFF — пересекающиеся подходы. Но есть существенные различия, из-за которых мы отказались от GraphQL.

Почему мы отказались от GraphQL:

• Ценность GraphQL реализуется с помощью BFF. Конечно, это разные вещи, но с помощью BFF на REST можно сделать то же, что и с GraphQL. 

• В GraphQL есть сложности с кешированием данных (на GraphQL запросы идут, по факту, через метод POST и ответы просто так не закешировать), а с BFF мы избегаем этих проблем. 

• В GraphQL запросы произвольные, а в REST легко строить метрики/алерты по явным маршрутам (/video/:id), что нам необходимо для качественной аналитики и мониторинга.  

• В GraphQL нужны защиты от N+1 сложности запросов, а в REST вы контролируете форму и «вес» ответа на уровне проектирования контаракта.

• Time-to-market в нашем случае с GraphQL просел бы: нам понадобилось бы перестраивать архитектуру внутри бэкенда, ребятам пришлось бы учиться работать с новой технологией и писать все эти запросы и guards. 

BFF vs API Gateway

Также может показаться, что подход BFF похож на API Gateway, но это не так. 

API Gateway — центральная точка входа в систему, которая принимает запросы клиентов и передаёт ответы обратно клиенту. Обычно управляется платформенной или DevOps-командой и меняется сравнительно редко.

BFF — как мы ранее говорили, это архитектурный паттерн, который подразумевает создание отдельного бэкенда под каждый фронтенд, чтобы в моменте отрисовать тот или иной UI. 

Архитектурная схема взаимодействия API Gateway и микросервисов выглядит примерно так:

API Gateway отвечает за то, чтобы балансировать вообще все запросы и перенаправлять их к сервисам. А также за безопасность, логирование и мониторинг. Кроме того, бывает, что на стороне API Gateway присутствует такой аспект, как трансформации, но я считаю, что все трансформации должны происходить на уровне микросервисов. Можно сказать, что BFF как раз и является тем самым микросервисом, который за это должен отвечать.

Итого: BFF не серебряная пуля

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

• Относитесь к BFF, как к полноценному бэкенд-сервису.

• Избегайте харкода и размазывания бизнес-логики. Если занести в BFF большую часть обработки данных, место которой на уровне клиента или бэкенда, то весь смысл BFF пропадет и потеряется гибкость решения. 

• Не превращайте BFF в API Gateway на стероидах. Пускать все запросы через BFF не нужно, это имеет смысл только для запросов, которые требуют сложной агрегации или предварительных подготовки данных для конкретного клиента. 

• Не переусложняйте! Когда вы внедряете новый сервис, ваша система сразу становится сложнее. Соответственно это решение должно решать какую-то вашу задачу и хорошо бы убедиться, что нет более простого способа это сделать. 

Подписывайтесь на этот блог и канал Смотри за IT, если хотите знать больше о создании медиасервисов. Там рассказываем об инженерных тонкостях, продуктовых находках и полезных мероприятиях, делимся видео выступлений и кадрами из жизни команд Цифровых активов «Газпром-Медиа Холдинга» таких, как RUTUBE, PREMIER, Yappy.

А если вы хотите знать больше о трендах в IT-отрасли, следите за обновлениями и анонсами новых конференций на сайте «Онтико». Например, в Москве 3 декабря состоится бесплатная конференция про разработку системного ПО, ядра Linux и open source OS DevConf 25 powered by GigaChat.