always has been

То есть ответ на мой вопрос делать мне 1 или 2 апи - делать 3 апи?))

это один из вариантов, да

Да смысле. Статьи по BFF начинаются с того что делать general purpose api сложно и тяжело, поэтому давайте продолжим её делать, но сверху ещё слоёв трансформации наделаем? Логика алло

Ты либо делаешь продуманный general purpose api, либо под каждый тип клиента по апишке

По апишке на клиент понятно. Не понятно почему стать по BFF предлагают какие то слои траснформации поверху GPA. Либо я не так понял

Слои трансформации - это адаптеры к внутреннему апи твоего приложения

General purpose api такой же адаптер, но обслуживает все возможные юзкейсы

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

Точнее не непонятными, а вводящими в заблуждение

В твоём случае с аутентификацией будет примерно так. Для фронт-клиента

Function frontendApiAuth() { app.authenticate() }

Для интеграций
Function integrationApiAuth() { app.authenticate() }

Простой и понятный код когда ты его пишешь отличается от простого и понятного кода, когда ты его читаешь или модифицируешь

Я про то что относительно простые штуки люди любят описывать сложными словами

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

Нормально иметь для разных целей разные методы

Речь не про методы, а про разные апи

Без микросервисов не работает?)

Разные методы апи, это сути не меняет

суть та же будет. 2 разных набора эндпоинтов, а модули юзают общие

Такой вопрос. Есть отчёт, пусть будет отчёт ордеров. Клиент может получить его в 3 вариантах: агрегированный маленький отчетик в виде  json. Детальный в виде CSV. Такой же детальный в виде екселя.

Отчёт строится так: сервимс возвращает курсор типа Iterable<Order> orders. Эти orders передаются в builder и тот начинает строить. Итнрируетсчя по курсору и строит отчёт. Но для каждого вида строит по разному.

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

Для CSV  и екселя работает точно такой же цикл, точно так же высчитывается по тем же формулам суммарный агрегированный отчетик, но в дополнение ещё и по каждой записи, и каждая запись пишется в сам отчёт.

И тут проблема. Я не могу построить весь отчёт и вернуть его билдером. Я сразу пишу его в httpResponse.outputStream. тоесть метод у меня возвращает void а в первом случае возвращает объект, который потом преобразуется в json. Поэтому сейчас есть 3 класса в которых один и тот же алгоритм, и в то же время разный. Пробовал выделять абстрактные методы но не ложиться на задачу.

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