Микросервисы в мобильных приложениях: почему растет популярность

Микросервисы дают командам свободу развивать отдельные части бэкенда независимо. Но если мобильное приложение обращается к каждому сервису напрямую, эта свобода может обернуться для клиента сложностью: экрану приходится собирать данные из разных источников, разбираться с несколькими форматами ответов и переживать сбои отдельных компонентов.

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

Микросервисная архитектура мобильного приложения сама по себе не ускоряет загрузку и не гарантирует масштабируемость. Она меняет способ организации бэкенда, а вместе с ним и место, где приходится управлять сложностью. Чтобы внутреннее устройство серверной части не перекладывалось на мобильный клиент, команды используют промежуточный слой для конкретного приложения. Один из распространённых вариантов такого слоя называется Backend for Frontend, или BFF.

Монолит и мобильный клиент: почему прямой доступ к сервисам не всегда работает

Схему «мобильное приложение → серверное API → база данных» часто воспринимают как наследие эпохи, когда веб был главным клиентом. Но история сложнее: iPhone и другие смартфоны давно стали значимыми платформами, а мобильный интерфейс нельзя считать просто уменьшенной копией сайта. У телефона свои условия работы: соединение может быть нестабильным, пользователь может переключаться между Wi-Fi и мобильной сетью, а приложение должно экономно обращаться с ресурсами устройства.

Проблемы возникают не из-за самого монолита и не из-за самого факта разделения бэкенда на сервисы. Они появляются, когда устройство вынуждено знать слишком много о внутренней структуре серверной системы.

Представим экран профиля. Для него могут понадобиться сведения об учётной записи, подписках, публикациях, настройках приватности и балансе. В монолитном API эти данные иногда доступны через один подготовленный ответ. После разделения системы они могут оказаться в разных сервисах. Если мобильный клиент обращается к ним напрямую, ему приходится самостоятельно собирать результат: отправлять запросы, учитывать порядок зависимостей, обрабатывать ошибки и решать, что показывать, если часть данных не пришла.

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

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

Появляются и другие издержки. Клиент должен поддерживать контракты нескольких сервисов, разбираться с их ошибками и адаптироваться к изменениям. Если схемы ответов различаются, часть логики преобразования данных оказывается в iOS- и Android-приложениях. Изменение серверного API может потребовать синхронной работы нескольких команд, а иногда и обновления уже выпущенного клиента, который пользователь не установит немедленно.

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

Разделение бэкенда полезно командам, но мобильный клиент не обязан повторять его внутреннюю карту.

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

Backend for Frontend: фасад для конкретного клиента

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

Идея не в том, чтобы заменить микросервисы ещё одним большим сервисом. BFF не должен становиться владельцем всей бизнес-логики. Его задача ближе к адаптации: объединить нужные ответы, убрать лишние поля, привести данные к удобному для клиента виду и определить поведение при частичной недоступности внутренних компонентов.

Название Backend for Frontend закрепилось в инженерной практике благодаря обсуждениям и материалам команд, в том числе SoundCloud. Позже паттерн получил широкое описание в литературе о микросервисах, включая книгу Сэма Ньюмана Building Microservices. Это не означает, что у каждого приложения непременно должен быть отдельный сервер. BFF полезен в тех случаях, когда различия между клиентами и сетевые требования достаточно велики, чтобы оправдать дополнительный слой.

Чем BFF отличается от API Gateway? Граница между этими решениями зависит от конкретной архитектуры, поэтому формула «шлюз делает только одно, BFF только другое» будет слишком жёсткой. Обычно API Gateway решает общие задачи входного трафика: маршрутизацию, применение базовых политик, лимитирование. BFF чаще настраивают под потребности определённого клиента: он может собрать данные для мобильного экрана, сократить ответ и скрыть от приложения изменения внутренних сервисов.

Один фасад способен обслуживать сразу несколько платформ, но это не всегда удобно. Если iOS, Android и веб-клиент требуют заметно разных моделей данных, общий BFF может обрасти ветвлениями и условной логикой. Тогда отдельные фасады позволяют развивать представления независимо. Решение зависит от цены дублирования и от того, насколько различаются сами сценарии. Правило «один клиент — один BFF» полезно как отправная точка, но не должно превращаться в обязательное требование.

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

Сетевая нагрузка: over-fetching и under-fetching

Две знакомые проблемы API особенно заметны в мобильном приложении.

Under-fetching возникает, когда одного ответа недостаточно для экрана. Клиенту приходится получать данные из нескольких источников, а иногда выстраивать вызовы в цепочку: следующий запрос зависит от результата предыдущего. Для приложения это означает дополнительную координацию, больше вариантов ошибки и более сложное состояние интерфейса.

Over-fetching — обратная ситуация. Сервер возвращает больше данных, чем нужно конкретному экрану. Например, в ответе на запрос карточки могут оказаться поля, которые этот интерфейс не использует. В каждом отдельном случае лишний объём может быть незаметен, но при частых запросах он влияет на трафик и объём работы по обработке ответа. Насколько существенно влияние, зависит от размера данных, частоты обращений и поведения приложения.

BFF позволяет подготовить ответ с учётом конкретного сценария. Для ленты он может запросить сведения о публикациях и авторах, объединить их и вернуть только те поля, которые нужны карточкам. Для профиля набор будет другим. Клиент получает структуру, близкую к модели интерфейса, а не вынужден собирать её из нескольких доменных представлений.

Обычно в таком слое решают несколько задач:

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

2. Проекция. В ответ попадают данные, нужные экрану или действию. Это сокращает лишний трафик, но требует аккуратно поддерживать контракт.

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

4. Частичный ответ. Если необязательный компонент временно недоступен, BFF может вернуть основную часть экрана. Такое поведение нужно проектировать заранее: для критичных данных частичный ответ может быть неправильным.

5. Преобразование ошибок. Внутренние ошибки сервисов можно привести к понятным для клиента состояниям, не раскрывая детали серверной реализации.

BFF не сокращает объём работы автоматически. Если он последовательно вызывает несколько сервисов, добавляет тяжёлые преобразования или становится перегруженным, дополнительный слой может увеличить задержку. Поэтому оценивать результат нужно по наблюдаемым показателям: времени ответа, объёму передаваемых данных, доле ошибок и поведению экрана при неполных ответах. Универсальные обещания вроде фиксированного сокращения времени загрузки или трафика здесь мало полезны: результат зависит от исходного API, данных и характера запросов.

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

Безопасность и оркестрация: что должен скрывать серверный слой

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

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

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

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

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

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

От SoundCloud до рекомендаций ThoughtWorks: как паттерн занял своё место

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

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

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

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

Поэтому вопрос «микросервисы или монолит для мобильного приложения» не сводится к выбору модного термина. Важно, какую проблему команда пытается решить. Монолит может быть хорошо спроектированным и предоставлять удобное API для мобильного клиента. Микросервисы могут дать независимость отдельным доменным командам, но потребовать продуманной границы для доступа с телефона. BFF способен связать эти решения, однако не исправит плохо определённые контракты и не заменит ясную ответственность за данные.

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

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

Где заканчивается польза BFF

Самая частая архитектурная ловушка — постепенно переносить в фасад правила, которые должны принадлежать доменным сервисам. На первых шагах это кажется удобным: нужная проверка уже рядом с запросом, её проще добавить в одно место. Со временем в BFF накапливаются расчёты, условия и собственные состояния. Он перестаёт быть адаптером и становится центральным компонентом, от которого зависит слишком много.

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

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

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

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

Хороший фасад прячет от мобильного клиента ненужную сложность, но не прячет от команды причины задержек и ошибок.

Популярность микросервисов в мобильной разработке объясняется не тем, что они всегда лучше монолита. Командам важно развивать систему по частям и давать независимость отдельным доменам. Но мобильному приложению редко полезно знать, сколько сервисов стоит за одним экраном. Если эта внутренняя структура начинает просачиваться в клиент, BFF становится одним из способов вернуть границу на место.

Решение о переходе стоит принимать по устройству системы и поведению приложения, а не по архитектурной моде. Иногда достаточно улучшить API монолита. Иногда нужен фасад, который собирает данные и адаптирует ответы. А иногда микросервисы уже создали столько распределённых зависимостей, что первым делом нужно разобраться с ними, прежде чем добавлять ещё один слой.

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