Пару кварталов назад наша команда занималась декомпозицией API. Вынос бизнес-логики из монолитного приложения и ее локализация в ограниченных контекстах ведут к выделению более целостных и идиоматичных API (в противовес монолитным, где данные из различных предметный областей перемешаны воедино). Вместо одного удобного энд-пойнта "обо всем" логично появляется несколько независимых. С другой стороны, не всегда есть возможность мигрировать на новый API по ряду причин: - сложности в обновлением клиентов (например мобильное приложение) - невозможность отключить старых клиентов (если их много) - потенциальное замедление клиента (вместо одного запроса с нужной информацией - нужно делать несколько запросов в разные сервисы) При этом поддержка совместимости API со старыми клиентами выглядит как тех. долг, который на мой взгляд разумно вынести на BFF (backend for frontend), реализовав композицию новых энд-пойнтов для совместимости старых клиентов. Это не очень типовой сценарий использования BFF, ведь обычно концепцию применяют для композиции API, а в случае в выделением сервисов - это декомпозиция (надо разобрать старый энд-пойнт на запчасти, каждая из которых получается из отдельного сервиса). Чтобы процесс был безопасным мы применили Strangler-паттерн, сравнивали результат работы декомпозированной системы с легаси. Это дало возможность постепенно доводить новый функционал до ума, и плавно выкатываться без ущерба для продакшена. С таким фокусом на надежность, требовалось очень много бойлерплейт-кода, по манипулированию трафиком и расчетом метрик "совпания/точности" (о которых я рассказывал в статье). Поэтому коробочное решение нам не подходило (в индустрии используется Krakend). И мы приняли решения писать композицию вручную. Поскольку работа предполагалась на нескольких эндпойнтах, мы допилили OSS решение со странглер-паттерном, для поддержки композиции, описанной через DSL. Получилось удобно: более гибко, чем конфигурировать композицию в манифесте (например в Krakend), но при этом достаточно стандартизованно, чтобы строить унифицированные метрики композиции. ⁉️Но делать композицию вручную - решение частное (и дорогое), и не может быть масштабировано на всю компанию (иначе каждая команда будет делать это по своему). 📦После всех работ, когда все стабилизировалось, планируем мигрировать на стандартное коробочное. Несмотря на то, что предстоит еще раз все переделать (а код частично пойдет на выброс), эта история скорее успешная, потому, что: - декомпозирован монолитный API-легаси системы, и случился безопасный и постепенный разьезд на сервисы (при сохраненном API) - мы получили опыт работы с композицией (в каком-то смысле композиция - это антипаттерн, т.к. в результате получаем сильную связность), и как ее варить, чтобы система не была подвержена каскадному сбою 🙄О полученном опыте расскажу в след посте, но прошу Вас в комментарии выбрать, что более Вам более интересно: 1️⃣каким принципами нужно руководствоваться, чтобы композиция не превратилась в ад 2️⃣подробней, почему решили делать самописное на первом этапе и какие нюансы 3️⃣как и за счет чего композиция позволила ускорить эндпойнты в x3