Комментарии 35
Все куда проще. Есть клиент, например, клиентский веб портал. Вам нужно получить информацию из системы в разрезе данного конкретного пользователя. Нужно пройти аутентификацию и при отображении интерфейса делать срез / представление для данного пользователя. Бэкенд же генерик. Он позволяет мутировать данные и получать данные. Он не беспокоиться, а кто их запросил, а есть ли у него права. Он концентрируется на бизнес логике (данные и их мутации). Работу по созданию проекции для пользователя, агрегации данных и ТД выполняет BBF. Такой же BFF может быть и для приложения портал авторов, которое взаимодействует с тем же бэкендом, но уже в другой проекции, другими правилами авторизации и тд. И третий BFF будет у приложения бэк офиса, где например модерируется контент. Например в веб приложении могут использоваться к http-only cookie для хранения полезной инфы, в том числе авторизации; а мобильные приложения могут использовать более удобный для них jwt.
Чем отличается от API Gateway? Только степенью узконаправленности: API Gateway широкое направлен и чаще всего обслуживает публичный АПИ. Это выражается во всем: от широты спектра возможностей авторизации: oAuth2, API ключи и до очень обобщенного контракта API, чтобы можно было сделать буквально любого клиента или любую интеграцию.
Мой рецепт такой - если клиент "ваш" нативный - делайте БФФ, в перспективе не будет ошибкой 100%. Если вам нужно предоставит точки интеграции "внешним" сервисам в рамках вашей компании или других компаний - делайте API Gateway и проектируйте публичный API. При этом в обоих случаях ядро системы будь то монолит или микросервисы предоставляют только операции с бизнес логикой + оркестраторы или менеджеры процессов, не парятся за авторизацию и доступны только в приватной сети. За авторизацию и пользовательский контекст отвечают BFF и API Gateway.
Изначально архитектура веб-сервисов (тогда они еще были сайтами) была простой и строилась по принципу монолита: один бэкенд напрямую общается с единой клиентской частью с одной стороны, и с базой данных — с другой.
Оправдывать нагораживание микросервисов историческим переходом от монолита к некст гену так сказать, это сильно
Я же не советую всем BFF-сервисы клепать, напротив, у меня есть блок, в котором я пишу когда BFF вообще не нужен. Но подходы с монолитами и вправду часто не дают компаниям быстро развиваться. Поэтому и появился этот архитектурный паттерн и его нужно уметь правильно готовить. По идее, статья об этом.
Но подходы с монолитами и вправду часто не дают компаниям быстро развиваться.
Слышу звон, не знаю где он. Вы просто повторяете за интернетом.
А откуда такое мнение сложилось? Вы точно прочитали статью или остановились на четвертом абзаце?
Изначально архитектура веб-сервисов (тогда они еще были сайтами) была простой и строилась по принципу монолита: один бэкенд напрямую общается с единой клиентской частью с одной стороны, и с базой данных — с другой.
Если вы про это, то данную цитату даже обсуждать...не стоит
Судя по вашим рисункам архитектуры, и правда архитектурные этапы собеседований проходятся количеством стрелочек и квадратиков...
Да я и не претендую на звание "лучшего архитектора систем". Я вообще руководитель клиентской разработки, в первую очередь. Приведенные здесь схемы не претендуют на правильность их проектирования в работе, это картинки из презентации моего доклада, не более того. Статья про общее понимание паттерна BFF фронтенд-разработчиками. Допускаю, что некоторые формулировки здесь упрощены. Буду благодарен, если дополните более развернутыми комментариями и подсветите то, что я не дораскрыл, на ваш взгляд.
Если честно много ответов перебирал в голове, но пришел к чему-то такому - докер открыл портал в ад, бизнесу подарил чувство новизны, как противоставление монолиту (в разрезе разговора про веб, у нас тут у всех как в гугле ы) и возможность закидать деньгами проблему, программисту дал отговорку - вместо внятной базы данных у нас куча баз данных, вместо внятного кода у нас куча сервисов, ответственность раскидана и размыта максимально, можно и работать потихоньку.
Беда в том что лично я страдаю не только как коллега, но и как пользователь вот таких вот микросервисов, думаю мне не дадут соврать что софт не становится качественно лучше для пользователей, получается что микросервис это не эволюция, правильно же? В отличии от того что вы говорите в статье.
Как по мне, тут на лицо смешение проблематик:
возможность закидать деньгами проблему, программисту дал отговорку - вместо внятной базы данных у нас куча баз данных, вместо внятного кода у нас куча сервисов, ответственность раскидана и размыта максимально, можно и работать потихоньку.
Разве только монолит дает чистоту архитектуры? Почем при микросервисной архитектуре мы не можем работать качественно? И что делать при увеличении монолита до масштабов, при которых любая доработка превращается в месяцы? Что делать по-настоящему большим сервисам с миллионами пользователей и петабайтами данных? Как масштабировать базу данных, которая выросла до неподдерживаемых размеров?
На лицо сравнение теплого с мягким.
софт не становится качественно лучше для пользователей
А тут точно проблема в инженерных подходах исключительно или есть ответственность продуктовой проработки и UX-исследований? Разве качество работы софта меряется исключительно наличием у этого софта микросервисной или монолитной архитектуры?
И тогда почему подход, в котором возможно строить что-то по-настоящему большое и масштабируемое, работающее быстро и способное выдержать хайлоад нагрузки не является эволюцией того, что устарело с точки зрения инженерных подходов и не подходит для использования с современном мире?
Вижу здесь переживания по тому, что мир изменился, а вы пока еще нет.
Разве только монолит дает чистоту архитектуры? Почем при микросервисной архитектуре мы не можем работать качественно?
Монолит или микросервис никак не влияет на кодовую базу проекта, уже есть понятие как распределенный монолит, правильно же? Чистоту архитектуры дает хороший архитектор.
И что делать при увеличении монолита до масштабов, при которых любая доработка превращается в месяцы?
Позвать архитектора из пункта выше, который знает как внутри кода разбить отвественность, а не раскидывать все по микросервисам
Как масштабировать базу данных, которая выросла до неподдерживаемых размеров?
Например почитать книжки, базу так сказать, а не плодить базы данных и поддерживать консистентность за счет кода приложения?
А тут точно проблема в инженерных подходах исключительно или есть ответственность продуктовой проработки и UX-исследований? Разве качество работы софта меряется исключительно наличием у этого софта микросервисной или монолитной архитектуры?
Не знал что из-за UX иследований может просто зависать приложение, показывать кучу рекламы подряд и еще кучу кучу всего что содержить в себе явно программный характер, а не внешний. Вы сейчас и пытаетесь сместить фокус. Когда заходишь на сайт с микросервисами, лучше не открывать консоль разработчика, а то 150 запросов на начальную страницу проекта это конечно инженерный верх веб технологий))
И тогда почему подход, в котором возможно строить что-то по-настоящему большое и масштабируемое, работающее быстро и способное выдержать хайлоад нагрузки не является эволюцией того, что устарело с точки зрения инженерных подходов и не подходит для использования с современном мире?
Вы заменяете взаимодейсвтие внутри ОС на взаимодействие по сети, это разве оптимизация? Размываете ответственность, плодите зоопарк технологий. Про современный мир - оставьте это вашим менеджерам и людям которые зависят от вашей работы, либо говорите технически чем монолит хуже, желательно с цифрами, все же должны (кроме меня) понимать очевидное приемущество микросервисов, вот и цифры бы показали его.
К слову вы опять ровняется на какие-то компании которые запустили эту "революцию" с хайлоад. Как монолит устарел? Просветите пожалуйста.
То что вы делаете как все, не значит что вы делает так потому-что это диктует вам инженерный подход, скорее просто маркетинг, это все что я хотел сказать по сути
Вижу здесь переживания по тому, что мир изменился, а вы пока еще нет.
За что мне переживать? За то что компании одна за одной пишут какие они классные, как у них все современно, но качество приложений не становится лучше? Зато везде микросервис это современно, круто, классно, всем нравится (особенно менеджерам и верхушке). Подстраиваться под них и закрывать глаза на свои технические знания - ну это торговля задом)
Или переживать что я не хочу идти работать и делать вид что я тут в чем-то разбираюсь просто повтаряя мантру из интернета и не понимаю даже что я делаю на самом деле?) Да как-то наоборот кажется что надо свою линию гнуть) Рано или поздно люди начнут задумываться над тем что они делают и как.
Позвать архитектора из пункта выше, который знает как внутри кода разбить отвественность, а не раскидывать все по микросервисам
Вы серьезно? Архитектор должен ходить в код разработчиков и помогать разработчикам декомпозировать их код? а зачем тогда разрабочики?
Например почитать книжки, базу так сказать, а не плодить базы данных и поддерживать консистентность за счет кода приложения?
Вы таки не ответили на вопрос: в чем противоречия и неконсистентность, когда у вас конкретный сервис отвечает за конкретную задачу?
Не знал что из-за UX иследований может просто зависать приложение, показывать кучу рекламы подряд и еще кучу кучу всего что содержить в себе явно программный характер, а не внешний.
Искренне рад, что теперь вы знаете, что показы рекламы происходят за счет реализации рекламомест по заказу бизнеса, который за счет этой рекламы оплачивает ЗП своим сотрудникам и сервера, на которых крутятся приложения и благодаря которым вы этим сервисом пользуетесь.
Размываете ответственность, плодите зоопарк технологий
Откуда вы это взяли? JS разработчики пишут на JS, бекенд разработчики пишут на своих языках. Каждый занимается своим делом, ответственность четко регламентирована и определена.
либо говорите технически чем монолит хуже, желательно с цифрами, все же должны (кроме меня) понимать очевидное приемущество микросервисов, вот и цифры бы показали его.
А вы обратили внимание на название статьи? И точно ее прочитали полностью или все же остановились на 4-м абзаце? Почитайте, правда. Будет полезно. Я там говорю, что и сейчас используется монолит. Но есть кейсы, когда его использование мешает быстрому развитию и масштабированию продукта.
Подстраиваться под них и закрывать глаза на свои технические знания - ну это торговля задом)
Мне искренне жаль, что у вас так болит эта тема, не знаю какое зло и кто вам причинил. Мы тут про наш кейс вам говорим и ни чем не торговали, никаким менеджерам не угождали, а делали так, чтобы наша команда и сервис могли развиваться дальше. Надеюсь на этом мы поставим точку в неконструктивных обсуждениях вопроса.
Верю, что ваш подход у вас работает, наш подход работает у нас. И не только у нас, почитайте комментарий ниже https://habr.com/ru/companies/habr_rutube/articles/970690/#comment_29180070
Хорошего вам дня!
Согласен, с вашими перетягиваниями конструктивизма тяжело добиться.
И вы мне опять рассказываете что микросервис это будущее, почему оно будущее вы так и не ответили, кроме того что это будущее у вас как у всех, ну окей.
Да и ваши примеры за микросервис (плейлист, доступ к видео и все такое) как я вам выше и сказал эти примеры только для менеджеров и верхушки которые ничего не понимают в программировании)
Для меня это звучит примерно так - я не знаю как построить код так что-бы его функционал не развалился и не превратился в лапшу через пол года работы, поэтому у нас все на микросервисах (как в гугл кстати) дайте деняг))))
Вот вам кстати и размытие ответственности, одни делает доступ к видео, другие плейлист собирают, третии описании видео отдают и тд и тп, а не то что вы мне про JS написали))
Почитайте, все же, статью. Пока все комментарии в стиле "слышу звон, да не знаю где он", забуксовали на четвертом абзаце а потом начались додумывания.
Много буков, понимаю, но такой уж тут формат, приходится осиливать, чтобы конструктивно вести диалог.
В чем додумывания? И чего я не прочитал в вашей статье?)
Разным клиентам нужны отдельные BFF — то есть свои ответственные.
Если нет ресурсов на поддержку ещё одного сервиса, то он вместо пользы может превратиться в узкое горлышко.
Собственно вы отрицаете то что говорите сами, только если это произнесено мной, а не вами.
Перечитал статью по вашей просьбе, просто заметил.
Не отрицаю. Если команда решает внедрять BFF, то она должна понимать, что BFF - это отдельный сервис, который требует поддержки и ресурсов. Если дополнительных ресурсов нет нет, то идти в разработку этого сервиса нет смысла.
Я бы сказал так - BFF и API Gateway это логические единицы. Физически это может быть даже один контейнер, в котором будет приложение, которое по путям /app, /checkout, /admin или по заголовку host будет маршрутизировать запросы на соответствующий модуль BFF или Gateway. А логическое ядро (команды, запросы, оркестраторы, бэкграунд обработчики) будет так же запущено в рамках того же приложения. Получаем модульный монолит. Такая архитектура знакома многим, кто разрабатывал приложения до появления тренда на микросервисы - тот же классический WordPress яркий пример такой архитектуры. Там модули вообще можно было подключать как плагины. И все на одном сервере.
Если модули не спутаны между собой, то всегда можно взять какую-то особо нагруженный модуль и при явной необходимости вынести его в отдельный инстанс/инстансы и масштабировать его независимо. То же самое и с базой данных. Может вообще оказаться, что инстанс приложения тянет и его масштабировать не надо, а БД не тянет. Для высокой нагрузки - соответствующее решение с соответствующим SLA. Для низкой нагрузки - простое решение. Например, модуль поиска видео и просмотра видео очень нагруженный и может быть потребоваться десятки инстансов БД, с репликацией и ТД чтобы выдержать нагрузку и обеспечить высокую доступность и отказоустойчивость. Эти сервера могут даже географически быть раскинуты, для обеспечения SLA. А вот модуль пользовательских плейлистов кратно менее нагружен и куда проще (т.к. там скоуп не весь сервис или категория видео, а конкретный пользователь). С таким на десятки тысяч активных пользователей и один относительно небольшой инстанс справится, да и требования к доступности и устойчивости у него наверняка поменьше. Ну не получилось добавить в свой плейлист видео, неприятно, но не конец света. На крайний случай можно на клиенте записать, что была попытка добавить и потом в бэкграунде обновить данные на сервере.
Т.е. на мой взгляд проблема не в микросервисах. А в преждевременной оптимизации, которую инициируют сами разработчики. Может ими движет психологический аспект, желание показать свои "лучшие" навыки. Может они реально верят, что делают "лучше". А по факту получается пушка для стрельбы по воробьям. И когда адепты прагматизма смотрят на объективно переусложненную для решения текущих задач систему, они понимают, что огромное количество вещей сделано "чтобы было, на будущее"; и это будущее не наступило, а цена уже заплачена, и немаленькая и счета приходят до сих пор.
UPD: А так как объективно число пользователей интернета ограничено, как и их время в сутках, то не может быть так, чтобы у всех приложений был трафик как у Озон, Вайлдберриз, Амазон, Гугл и тд. Т.е. чаще всего приложениям пользуются пару тысяч человек в общем случае одновременно, и тут объективно чаще всего монолита хватит. Даже чуть вскрою карты, я работаю в крупнейшем провайдере IP телефонии в Серверной Америке. У нас трафик на самых нагруженных сервисах, о которых мне известно, оценивается тысячами RPM, максимум десятками тысяч в самое пиковое время. И микросервисная архитектура используется во многом для независимого деплоя модулей, недели для масштабирования. Хотя там такая связность, что даже и эта возможность почти никогда не работает. Буквально многие сервисы могли быть сделаны монолитами и ничего бы в худшую сторону не изменилось.
И снова спасибо за здравый взгляд на ситуацию. Полностью с вами согласен.
Эхо микросервисов все разносится по интернету. Наверное вы не дочитали статью либо вы как автор считаете что 150 инстансов и мешанина из квадратиков и стрелочек (с циклическими связями) это верх веб технологий. Просто сюр такое наблюдать на техническом портале.
Эта мешанина, в которой даже на компе не видно как подписаны квадратики, зато с ходу видны циклические зависимости. И это даже не код одного приложения! Это 150 инстансов которые вам подают за 1 приложения, а какая архитектура кода у всей этой поделки? Какая связанность внутри кода? Устойчивость всего этого?) Смешно конечно.
Я лишь показал схематично сложность системы. Это архитектура 2024, много легаси наша команда переписала на более чисты архитектурные патерны. Да и в принципе, у сервиса 19-ти летняя история, много технических команд сменилось, наша команда существует 3,5 года и благодаря нашим усилиям, инфраструктура систем и приложений работает безотказно для 18M ежедневных пользователей.
А вам предлагаю все же успокоиться и перестать искать все новый и новые попытки захейтить сервис, к которому испытываете неприязнь. Оставьте свои личные психологические травмы для психотерапевта и не вываливайте их в комментариях на технической площадке. Спасибо!
Чистите ботинки, скоро опять переобуваться придётся)))
Я вижу что вас чужая точка зрения задевает. Вы видимо думали что вам тут будут микросервесные дифирамбы петь...
Посмотрите выше сами, вы же и просили меня развернуть мою позицию, теперь рот затыкаете, что, у вас менеджерским речам не учат начальников?) Беседу вы тяжело ведёте)
вас никто не затыкает. вам привели много объективных и адекватных примеров того, почему так сделано у нас и как можно сделать по другому, вы упорно доказываете ту точку зрения, которая даже к теме статьи не относится. что мне еще остается вам сказать? я вижу в ваших комментариях лишь попытку доказать свою правоту любыми способами, вы манипулируете фактами и подкидываете разные медиа материалы, которые якобы подтверждают ваши слова, но только они вообще не метчатся с идеей статьи.
что мне остается делать? вероятно, не стоит просто поддерживать ваш энтузиазм своими ответами, в попытке объяснить свою позицию и суть неуместности ваших набросов. чтож, так и поступлю. всего вам доброго!
То есть BFF, это когда пишут api gateway для каждого фронта?
И да, и нет. Бывают кейсы, когда через BFF пускают все запросы с клиента и он действительно превращается в api gateway на стероидах. Я придерживаюсь мнения, что BFF нужен только в тех случаях, когда для конкретного элемента интерфейса нам необходимо получить данные из нескольких API бэкенда. Если подобный элемент мы отрисовываем часто и бизнес-логика приложения по агрегации данных начинает пухнуть, потому что нам нужно писать много кода для подготовки данных на клиенте, такой запрос стоит оптимизировать и вынести на уровень BFF. Здесь же мы можем снизить нагрузку на бэкенд, добавив кеширование на уровне BFF слоя. Ну и ходить напрямую от BFF до бекенда внутри закрытой сети дешевле и быстрее, чем ходить через балансер и провайдеров на каждый чих.
API Gateway должен заниматься маршрутизацией запросов и делать это очень быстро. Нагружать его логикой агрегации данных — не лучшее решение.
Все куда проще. Есть клиент, например, клиентский веб портал. Вам нужно получить информацию из системы в разрезе данного конкретного пользователя. Нужно пройти аутентификацию и при отображении интерфейса делать срез / представление для данного пользователя. Бэкенд же генерик. Он позволяет мутировать данные и получать данные. Он не беспокоиться, а кто их запросил, а есть ли у него права. Он концентрируется на бизнес логике (данные и их мутации). Работу по созданию проекции для пользователя, агрегации данных и ТД выполняет BBF. Такой же BFF может быть и для приложения портал авторов, которое взаимодействует с тем же бэкендом, но уже в другой проекции, другими правилами авторизации и тд. И третий BFF будет у приложения бэк офиса, где например модерируется контент. Например в веб приложении могут использоваться к http-only cookie для хранения полезной инфы, в том числе авторизации; а мобильные приложения могут использовать более удобный для них jwt.
Чем отличается от API Gateway? Только степенью узконаправленности: API Gateway широкое направлен и чаще всего обслуживает публичный АПИ. Это выражается во всем: от широты спектра возможностей авторизации: oAuth2, API ключи и до очень обобщенного контракта API, чтобы можно было сделать буквально любого клиента или любую интеграцию.
Мой рецепт такой - если клиент "ваш" нативный - делайте БФФ, в перспективе не будет ошибкой 100%. Если вам нужно предоставит точки интеграции "внешним" сервисам в рамках вашей компании или других компаний - делайте API Gateway и проектируйте публичный API. При этом в обоих случаях ядро системы будь то монолит или микросервисы предоставляют только операции с бизнес логикой + оркестраторы или менеджеры процессов, не парятся за авторизацию и доступны только в приватной сети. За авторизацию и пользовательский контекст отвечают BFF и API Gateway.
чтобы отрисовать страницу, нужно опросить 9-10 API ручек, то через BFF это будет сильно дешевле с точки зрения сетевых задержек.
А если создать папочку, условно bff-public-module, в изначальном апи-сервисе. И уже в нём сделать одну "ручку". которая будет дёргать другие 9-10 "ручек". Это не тоже самое? зато ещё быстрее (минус сетевые задержки). И пусть уже в этой папке "заказчики" конкретных агрегаций - крутят и вертят что хотят)
Можно и так, вопрос конкретной задачи и дальнейшего развития сервисов. У нас получилось много таких кейсов, где приходилось собрать данные из разных апишек или как-то изменять структуры данных для разных клиентов. Мы решили, что отдельный сервис нам поможет с этим, так и получилось.
В свою очередь, бэкенд из большого и тяжелого монолита получил возможность трансформироваться в несколько десятков сервисов, которые теперь отвечали за конкретную задачу, а не за то, чтобы сходить в разные базы данных и учесть потребности каждого из клиентов, которые очень быстро менялись с точки зрения визуализации интерфейса.
Ваш вариант похож скорее на реализацию Public API, который могут использовать как собственные клиенты, так и партнеры. Но это API должен быть достаточно стабилен и клиенты должны подстваиваться под него, а не он под клиентов. Ключевое преимущество BFF в том, что он меняется так же часто, как и перестраивает свой интерфейс клиентское приложение.
Универсальный Backend for Frontend для всех платформ RUTUBE