1/7. Техническая деталь, которая незаметно ест деньги банка

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

Это BFF — Backend for Frontend, серверный слой под конкретный клиент: мобильное приложение, web, личный кабинет, инвестиционный экран.

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

Для пользователя это просто экран, который должен быстро открыться.

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

Я давно смотрел на одну повторяющуюся боль: фронтенд часто получает больше данных, чем ему нужно.

Не потому что кто-то плохо работает.

Скорее наоборот: это нормальное следствие большой корпоративной разработки.

REST-контракт — классический HTTP API — расширяется. DTO, то есть объект передачи данных, становится богаче. Разные команды добавляют поля под свои сценарии. Обратная совместимость не дает быстро удалить лишнее.

Через год один экран использует 10-20 полей, а endpoint, то есть HTTP-ручка, стабильно отдает 100+.

И каждый лишний байт проходит весь путь: - сериализация на BFF; - сеть; - CDN — сеть доставки контента; - JSON-парсинг на клиенте; - память; - reconciliation — сверка виртуального интерфейса с реальным UI; - latency — задержка ответа; - дополнительные pod'ы, то есть экземпляры приложения в Kubernetes, на пике.

В банке это особенно заметно.

Много пользователей. Утренние пики. Открытие торгов. Платежные дни. Пуши. Волатильность. Массовые заходы в приложение.

А рядом еще требования безопасности: audit — аудит действий, traceability — прослеживаемость запроса, идемпотентность финансовых операций, запрет на случайные публичные API-поверхности.

В какой-то момент я сформулировал вопрос иначе: не: "какую технологию выбрать", а: сколько стоит полезный клиентский payload — полезная нагрузка ответа — на единицу нагрузки?

Так началось исследование.

Я не пытался доказать, что GraphQL лучше REST. REST может быть быстрым. Java BFF может быть быстрым. GraphQL без дисциплины может быть дорогим и опасным.

Мне было интересно другое:

можно ли сделать GraphQL не как свободную публичную ручку, а как строгий банковский контракт, где клиент не может спросить что угодно?

И вот тут история стала интересной. Потому что первая версия GraphQL в этом исследовании проиграла REST почти в 3 раза.

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