Не совсем это api gateway - я бы тут привел аналогию, что фронтальное приложение становится само клиент-сервисным, у него появляется бэк, на который переносится обработка, а задача фронта просто красиво и удобно работать с пользовталем и "кушать" меньше ресурсов
Что касается разработчиков:
- вариант 1 - делают бэк-разработчики, которые делают и обычные сервисы (если говорить про знание логики фронта, то в этом случае что с bff, что без bff , то на это есть системный аналитик, который как раз и проектирует функционал на всех трех уровнях: фронт, bff, основной бэк и по моим подсчетам времени это знаимает столько же - есть и новые затраты на новый уровень, где-то экономия на том, что упрощается постановка - например, постановки для фронта значительно упростились и в разработке и в понимании для разработчика - например, фронтендеру не надо думать, как собрать данные с бэка в случае множества источников - у него есть один-два метода которые предоставят нужную информацию)
- вариант 2 - это могут делать фронт-енд разработчики (используя js на node.js и аналогах) - выше как раз есть комментарий по этому поводу (там команда шла к bff от фронта)
Причем все-таки рекомендуется выделять отдельную команду для bff (мы сейчас к этому идем) - так как у разработчиков bff релизный цикл такой же как у фронта - т.е. изменения могут вноситься достаточно быстро, когда на основной бизнес-логике изменения могут реализовываться и доходить до прода достаточно долго (пока все протестируют, согласуют)
Если смотреть по человеко-часам (по тому что у нас получилось), то основные потери это на то, что это просто отдельный сервис (сделать "каркас" приложения, например) и на дополнительные коммуникации этого сервиса - задачу надо все равно реализовать, неважно где она будет реализована (либо на фронте потратим время фронтенд разработчика, на бэке - тот же бекендер будет ее делать, аналитик, также, потратит время на проектирование, тестировщик - тестировать) - сама функция не исчезает, она только переносится на отдельный слой
Но, опять же, надо смотреть в комплексе - какую проблему мы решаем, сколько от нее потери, и, если она решается за счет bff, то есть ли выигрыш. На большой системе с разнообразными фронтальными приложениями он, скорее всего, будет, на маленькой или средней - нет.
Если сервис публично доступен для пользователя, то он должен сам обрабатывать права пользователя. Если он не обрабатывает права пользователя, он не должен быть доступен. Должен быть бэкенд, который его использует в своей логике, как любое другое third-party API с доступом по API KEY. Но это не BFF, а именно бэкенд с бизнес-логикой приложения.
Вот этот комментарий скорее всего к "Во-первых, не всегда есть возможность (или желание) реализовывать в источнике данных дополнительные функции, помимо бизнес-логики. Например, в качестве источника выступает вендорское ПО, в которое нельзя просто так взять и прикрутить управление правами доступа, нужными фронту." Потому что при наличии BFF готовить данные для фронта - его задача, в отсутствие BFF - ну либо задача самого фронта, либо выбирается один бизнес-сервис, который сам, при необходимости, опрашивает другие сервисы на предмет получения дополнительных данных, либо в него реплицируются данные других сервисов (это вполне себе вариант решения, если он дешевле создания BFF). Как я писал в статье - всегда надо смотреть, что дешевле. На простой системе, с парой интерфейсов, которые к тому же не часто меняются (например, системы для внутренних пользователей) - то слой BFF лишний. Если у системы есть внешние пользователи, если есть маркетинг, который постоянно "дорабатывает" GUI для них - то стоит задуматься. Тут просто то, что изменения для фронта будут внедряться быстрее уже может быть выигрышным (так как не надо будет при каждом изменении запроса фронта дергать бэк с основной бизнес-логикой).
Ну многие проекты и до сих пор без этого живут. DDD не говорит о том, как сделать удобно пользователю работать с данными, он определяет базовую бизнес-логику. Он говорит о самих данных и какие основные действия с ними надо совершить чтобы получить требуемый результат, добавляет словарь чтобы разработчик с бизнесом говорил на одном языке - это как раз про "чистый" бэк, в котором реализована бизнес-логика. А BFF - это как раз про взаимодействие с пользователем.
Нет никакой проблемы из класса с бизнес-логикой возвращать модель, а в слое представления рендерить ее в нужное DTO.
А разве это не есть разделение на слои? Да, тут внутри одного сервиса. в случае BFF разные сервисы. Но раз внутри одного сервиса, то могут быть еще другие факторы - например, тот же разный цикл реализациии презентационной логики и бизнес-логики.
А когда то же самое происходит в десятке разных BFF, то это вдруг становится нормально?
Ненормально - поэтому я и отнес это в минусы. Но тут вопрос в том, что сколько у нас должно быть сервисов BFF и насколько они однотипные (идеал идеален в теории, но есть реальность и тут можно пойти на определенные уступки - то есть делить сервисы по группам ролей пользователей, например, один сервис для внешних пользователей, другой для внутренних бизнес-пользователей, третий для админов - некоторые проблемы, конечно, останутся, но тут хотя бы можно будет как-то разделить поток требований к фронту от разных групп пользователей - то есть и методы станут хоть и универсальные (например, один метод и для веб и для мобилки), но проще, да и реализацию изменений можно ускорить).
Если для разного набора полей не хочется добавлять полноценный GraphQL, то можно сделать GET-параметр со списком запрашиваемых полей, и обрабатывать его в слое представления.
И как озвучивал в проблемах - получим монструозный метод, оторванный от потребителя.
Наличие слоя BFF можно обыграть с помошью спецификаций . Например, я логику методов BFF описываю в рамках постановки на GUI (конечно, разделяя документы, что тоже не получался архидокумент, но они по крайней мере лежат рядом) - и сразу видно для чего тот или иной метод нужен.
Когда же я смотрю на спецификацию метода бэка (особенно, если сервис уже прожил больше года и активно развивался) я не всегда понимаю зачем это надо и как мои изменения могут это использовать или как на это повлиять (согласен, что это также вопрос документирования и комментирования, но я все-таки говорю про реальный мир, где работают реальные люди).
Если это новые колонки, которых не было в ответе API, то без изменения бэка это не сделать. BFF тут ничего не меняет.
А если были? И просто до какого-то момента не показывались? Например, в методе поиска не всегда для списка возвращают все данные - стараются ограничиться только тем, что надо показывать, а полные данные, например, получить когда уже пользовтаель откроет сущность на просмотр или редактирование.
Нет никакой проблемы отдать на клиента список прав текущего пользователя. Это его права, он их и так знает.
Если, конечно, нет ограничений по требованиям ИБ (это реальный случай в одном из крупных банков - безопасники требовали, чтобы в токене для внешних пользователей был только идентификационная информация, а уже привилегии добавляли в запрос на пути от фронта к бэку в слое API Gateway - естественно, фронт не знал какие там у пользователя привилегии).
Да, иногда может быть рассинхронизания изменений, кнопка на фронтенде доступна, а на бэке действие возвращает ошибку, это просто следствие того, что у вас 2 независимые системы.
Ну так давайте сделаем это в виде одной системы? Как раз на слое BFF.
Это называется слой представления. Если у вас всё распилено на микросервисы, то фронтенд все равно не должен обращаться к ним напрямую. Должен быть бэкенд, который обращается к ним, в нем и будет слой представления. В этом случае микросервисы это внутренние сервисы, они являются аналогом базы данных и возвращают сущности.
А еще этот слой называется Backend for Frontend. Я дальше по тексту как раз про это и сказано.
В части подготовки данных (точнее в части представления фронте только тех данных которые нужны) - да, как один из вариантов следует рассматривать. Но то же скажу, что это тоже не простое решение (может мне не везло, но сталкивался с тем, что многим аналитикам и разработчикам эта технология тяжело давалась - им проще было рядом еще один метод сделать).
Абстракция ради абстракции (как и подход ради подхода) всегда плохо. Они должны решать какую-то проблему, причем это решение должно, по итогу, быть дешевле чем потери от самой проблемы и минусы нового решения.
Я, собственно, в статье и есть оговорка про то, что перед внедрением BFF надо подумать - а стоит ли это того.
И Вы тут как раз повторяете то, что я вначале озвучил в проблемах - просто на начальном этапе это незначительная дополнительная логика, а при росте системы, при возрастании количества разных потребителей оно становится проблемой.
Например, "При условии что у компании есть возможность контролировать исходный источник данных, почему бы не делать этот слой в сам бэкэнд сервис? " - можно, и это делают - в самом начале не трудно дополнительно сделать метод получения данных для формы списка, почему бы вместе со статусом не передать цвет его отображения и ссылку на иконку - сейчас то, это не займет много места в БД да и мы еще помним зачем эти странные поля status_color и status_icon_url добавили в таблицу payments?
Но а если система будет расти, что будет потом, когда появятся новые требования? Например, из практики - разные статусы для внешних клиентов и админов, разные комментарии к статусам для разных ролей пользователя, разные цвета для одного и того же статуса, разные иконки (это только по оформлению). Потом для разных ролей пользователей выясняется, что одной роли надо показать один набор данных, другой - другой набор (да, можно решить одним методом, либо добавляя кучу if'ов внутри метода, либо отсылая на фронт один набор данных - фронт разберется -, но тут приходят безопасники и говорят - а почему простой оператор видит остаток на счет - а это потому, что мы отправили на фронт его (в контракте же он есть) и, хотя форма его не показывает, любопытный оператор освоил F12 и смотрит ответы от бэка в оригинале).
И в результате мы имеем проблему, которую надо решать, так как она мешает развитию (долгое время на анализ существующего решения при внесении изменений, постоянные доработки методов для фронта ломающие бизнес-логику или из-за бизнес-логики не позволяющие быстро донести изменения для фронта до прода - так как надо все протестировать, чтобы убедиться, что ничего дополнительно не сломали). И вот когда мы решаем проблему, мы вспоминаем, что есть такой вариант решения как добавить слой BFF (а статья как раз о том, чтобы сказать, что вот есть такой вариант), считаем сколько это будет стоить (и не только в "моменте", но и в перспективе) и когда поймем что выигрыш есть - тогда и добавляем.
На самом деле не совсем такие же (тут я скорее не совсем точно выразил мысль).
Я тут вижу только в части сложности кода и разработки.
В случае без BFF, например, в случае сложности разработки стоит говорить о том, что когда смешивается и бизнес-логика и логика взаимодействия с пользователем, в этом случае код получится запутанным, сложным в понимании что для чего (а как показала практика спецификация не всегда помогает потом), ну и как уже писал, сложность разработки также в том, что при внесении изменений в методы для фронта можем случайно сломать бизнес-логику (и такое, в моей практике, было достаточно часто).
Плюс проблема в разных циклах разработки для бэка и фронта. Т.е. проблемы больше организационно-технические.
А сложность разработки и дублирование кода в минусах BFF возникает просто из-за очевидного факта того, что добавляется новый сервис. Но поддержка и понимание в дальнейщем получается в целом дешевле.
И, понятное дело, что эта проблема возникает не на одном фронте и не на паре сервисов бэка - т.е. должна накопиться критическая масса, чтобы плюсы BFF превысили минусы без BFF и минусы BFF.
Не совсем это api gateway - я бы тут привел аналогию, что фронтальное приложение становится само клиент-сервисным, у него появляется бэк, на который переносится обработка, а задача фронта просто красиво и удобно работать с пользовталем и "кушать" меньше ресурсов
Что касается разработчиков:
- вариант 1 - делают бэк-разработчики, которые делают и обычные сервисы (если говорить про знание логики фронта, то в этом случае что с bff, что без bff , то на это есть системный аналитик, который как раз и проектирует функционал на всех трех уровнях: фронт, bff, основной бэк и по моим подсчетам времени это знаимает столько же - есть и новые затраты на новый уровень, где-то экономия на том, что упрощается постановка - например, постановки для фронта значительно упростились и в разработке и в понимании для разработчика - например, фронтендеру не надо думать, как собрать данные с бэка в случае множества источников - у него есть один-два метода которые предоставят нужную информацию)
- вариант 2 - это могут делать фронт-енд разработчики (используя js на node.js и аналогах) - выше как раз есть комментарий по этому поводу (там команда шла к bff от фронта)
Причем все-таки рекомендуется выделять отдельную команду для bff (мы сейчас к этому идем) - так как у разработчиков bff релизный цикл такой же как у фронта - т.е. изменения могут вноситься достаточно быстро, когда на основной бизнес-логике изменения могут реализовываться и доходить до прода достаточно долго (пока все протестируют, согласуют)
Если смотреть по человеко-часам (по тому что у нас получилось), то основные потери это на то, что это просто отдельный сервис (сделать "каркас" приложения, например) и на дополнительные коммуникации этого сервиса - задачу надо все равно реализовать, неважно где она будет реализована (либо на фронте потратим время фронтенд разработчика, на бэке - тот же бекендер будет ее делать, аналитик, также, потратит время на проектирование, тестировщик - тестировать) - сама функция не исчезает, она только переносится на отдельный слой
Но, опять же, надо смотреть в комплексе - какую проблему мы решаем, сколько от нее потери, и, если она решается за счет bff, то есть ли выигрыш. На большой системе с разнообразными фронтальными приложениями он, скорее всего, будет, на маленькой или средней - нет.
Вот этот комментарий скорее всего к "Во-первых, не всегда есть возможность (или желание) реализовывать в источнике данных дополнительные функции, помимо бизнес-логики. Например, в качестве источника выступает вендорское ПО, в которое нельзя просто так взять и прикрутить управление правами доступа, нужными фронту."
Потому что при наличии BFF готовить данные для фронта - его задача, в отсутствие BFF - ну либо задача самого фронта, либо выбирается один бизнес-сервис, который сам, при необходимости, опрашивает другие сервисы на предмет получения дополнительных данных, либо в него реплицируются данные других сервисов (это вполне себе вариант решения, если он дешевле создания BFF).
Как я писал в статье - всегда надо смотреть, что дешевле. На простой системе, с парой интерфейсов, которые к тому же не часто меняются (например, системы для внутренних пользователей) - то слой BFF лишний.
Если у системы есть внешние пользователи, если есть маркетинг, который постоянно "дорабатывает" GUI для них - то стоит задуматься. Тут просто то, что изменения для фронта будут внедряться быстрее уже может быть выигрышным (так как не надо будет при каждом изменении запроса фронта дергать бэк с основной бизнес-логикой).
Ну многие проекты и до сих пор без этого живут.
DDD не говорит о том, как сделать удобно пользователю работать с данными, он определяет базовую бизнес-логику. Он говорит о самих данных и какие основные действия с ними надо совершить чтобы получить требуемый результат, добавляет словарь чтобы разработчик с бизнесом говорил на одном языке - это как раз про "чистый" бэк, в котором реализована бизнес-логика.
А BFF - это как раз про взаимодействие с пользователем.
А разве это не есть разделение на слои? Да, тут внутри одного сервиса. в случае BFF разные сервисы. Но раз внутри одного сервиса, то могут быть еще другие факторы - например, тот же разный цикл реализациии презентационной логики и бизнес-логики.
Ненормально - поэтому я и отнес это в минусы.
Но тут вопрос в том, что сколько у нас должно быть сервисов BFF и насколько они однотипные (идеал идеален в теории, но есть реальность и тут можно пойти на определенные уступки - то есть делить сервисы по группам ролей пользователей, например, один сервис для внешних пользователей, другой для внутренних бизнес-пользователей, третий для админов - некоторые проблемы, конечно, останутся, но тут хотя бы можно будет как-то разделить поток требований к фронту от разных групп пользователей - то есть и методы станут хоть и универсальные (например, один метод и для веб и для мобилки), но проще, да и реализацию изменений можно ускорить).
И как озвучивал в проблемах - получим монструозный метод, оторванный от потребителя.
Наличие слоя BFF можно обыграть с помошью спецификаций . Например, я логику методов BFF описываю в рамках постановки на GUI (конечно, разделяя документы, что тоже не получался архидокумент, но они по крайней мере лежат рядом) - и сразу видно для чего тот или иной метод нужен.
Когда же я смотрю на спецификацию метода бэка (особенно, если сервис уже прожил больше года и активно развивался) я не всегда понимаю зачем это надо и как мои изменения могут это использовать или как на это повлиять (согласен, что это также вопрос документирования и комментирования, но я все-таки говорю про реальный мир, где работают реальные люди).
А если были? И просто до какого-то момента не показывались? Например, в методе поиска не всегда для списка возвращают все данные - стараются ограничиться только тем, что надо показывать, а полные данные, например, получить когда уже пользовтаель откроет сущность на просмотр или редактирование.
Если, конечно, нет ограничений по требованиям ИБ (это реальный случай в одном из крупных банков - безопасники требовали, чтобы в токене для внешних пользователей был только идентификационная информация, а уже привилегии добавляли в запрос на пути от фронта к бэку в слое API Gateway - естественно, фронт не знал какие там у пользователя привилегии).
Ну так давайте сделаем это в виде одной системы? Как раз на слое BFF.
А еще этот слой называется Backend for Frontend. Я дальше по тексту как раз про это и сказано.
В части подготовки данных (точнее в части представления фронте только тех данных которые нужны) - да, как один из вариантов следует рассматривать. Но то же скажу, что это тоже не простое решение (может мне не везло, но сталкивался с тем, что многим аналитикам и разработчикам эта технология тяжело давалась - им проще было рядом еще один метод сделать).
Да, спасибо за комментарий - пропустил при вычитке.
Сейчас попробую поправить.
Абстракция ради абстракции (как и подход ради подхода) всегда плохо. Они должны решать какую-то проблему, причем это решение должно, по итогу, быть дешевле чем потери от самой проблемы и минусы нового решения.
Я, собственно, в статье и есть оговорка про то, что перед внедрением BFF надо подумать - а стоит ли это того.
И Вы тут как раз повторяете то, что я вначале озвучил в проблемах - просто на начальном этапе это незначительная дополнительная логика, а при росте системы, при возрастании количества разных потребителей оно становится проблемой.
Например, "При условии что у компании есть возможность контролировать исходный источник данных, почему бы не делать этот слой в сам бэкэнд сервис? " - можно, и это делают - в самом начале не трудно дополнительно сделать метод получения данных для формы списка, почему бы вместе со статусом не передать цвет его отображения и ссылку на иконку - сейчас то, это не займет много места в БД да и мы еще помним зачем эти странные поля status_color и status_icon_url добавили в таблицу payments?
Но а если система будет расти, что будет потом, когда появятся новые требования? Например, из практики - разные статусы для внешних клиентов и админов, разные комментарии к статусам для разных ролей пользователя, разные цвета для одного и того же статуса, разные иконки (это только по оформлению).
Потом для разных ролей пользователей выясняется, что одной роли надо показать один набор данных, другой - другой набор (да, можно решить одним методом, либо добавляя кучу if'ов внутри метода, либо отсылая на фронт один набор данных - фронт разберется -, но тут приходят безопасники и говорят - а почему простой оператор видит остаток на счет - а это потому, что мы отправили на фронт его (в контракте же он есть) и, хотя форма его не показывает, любопытный оператор освоил F12 и смотрит ответы от бэка в оригинале).
И в результате мы имеем проблему, которую надо решать, так как она мешает развитию (долгое время на анализ существующего решения при внесении изменений, постоянные доработки методов для фронта ломающие бизнес-логику или из-за бизнес-логики не позволяющие быстро донести изменения для фронта до прода - так как надо все протестировать, чтобы убедиться, что ничего дополнительно не сломали). И вот когда мы решаем проблему, мы вспоминаем, что есть такой вариант решения как добавить слой BFF (а статья как раз о том, чтобы сказать, что вот есть такой вариант), считаем сколько это будет стоить (и не только в "моменте", но и в перспективе) и когда поймем что выигрыш есть - тогда и добавляем.
На самом деле не совсем такие же (тут я скорее не совсем точно выразил мысль).
Я тут вижу только в части сложности кода и разработки.
В случае без BFF, например, в случае сложности разработки стоит говорить о том, что когда смешивается и бизнес-логика и логика взаимодействия с пользователем, в этом случае код получится запутанным, сложным в понимании что для чего (а как показала практика спецификация не всегда помогает потом), ну и как уже писал, сложность разработки также в том, что при внесении изменений в методы для фронта можем случайно сломать бизнес-логику (и такое, в моей практике, было достаточно часто).
Плюс проблема в разных циклах разработки для бэка и фронта. Т.е. проблемы больше организационно-технические.
А сложность разработки и дублирование кода в минусах BFF возникает просто из-за очевидного факта того, что добавляется новый сервис. Но поддержка и понимание в дальнейщем получается в целом дешевле.
И, понятное дело, что эта проблема возникает не на одном фронте и не на паре сервисов бэка - т.е. должна накопиться критическая масса, чтобы плюсы BFF превысили минусы без BFF и минусы BFF.