Комментарии 14
Изначально архитектура веб-сервисов (тогда они еще были сайтами) была простой и строилась по принципу монолита: один бэкенд напрямую общается с единой клиентской частью с одной стороны, и с базой данных — с другой.
Оправдывать нагораживание микросервисов историческим переходом от монолита к некст гену так сказать, это сильно
Я же не советую всем BFF-сервисы клепать, напротив, у меня есть блок, в котором я пишу когда BFF вообще не нужен. Но подходы с монолитами и вправду часто не дают компаниям быстро развиваться. Поэтому и появился этот архитектурный паттерн и его нужно уметь правильно готовить. По идее, статья об этом.
Но подходы с монолитами и вправду часто не дают компаниям быстро развиваться.
Слышу звон, не знаю где он. Вы просто повторяете за интернетом.
А откуда такое мнение сложилось? Вы точно прочитали статью или остановились на четвертом абзаце?
Изначально архитектура веб-сервисов (тогда они еще были сайтами) была простой и строилась по принципу монолита: один бэкенд напрямую общается с единой клиентской частью с одной стороны, и с базой данных — с другой.
Если вы про это, то данную цитату даже обсуждать...не стоит
Судя по вашим рисункам архитектуры, и правда архитектурные этапы собеседований проходятся количеством стрелочек и квадратиков...
Да я и не претендую на звание "лучшего архитектора систем". Я вообще руководитель клиентской разработки, в первую очередь. Приведенные здесь схемы не претендуют на правильность их проектирования в работе, это картинки из презентации моего доклада, не более того. Статья про общее понимание паттерна BFF фронтенд-разработчиками. Допускаю, что некоторые формулировки здесь упрощены. Буду благодарен, если дополните более развернутыми комментариями и подсветите то, что я не дораскрыл, на ваш взгляд.
Если честно много ответов перебирал в голове, но пришел к чему-то такому - докер открыл портал в ад, бизнесу подарил чувство новизны, как противоставление монолиту (в разрезе разговора про веб, у нас тут у всех как в гугле ы) и возможность закидать деньгами проблему, программисту дал отговорку - вместо внятной базы данных у нас куча баз данных, вместо внятного кода у нас куча сервисов, ответственность раскидана и размыта максимально, можно и работать потихоньку.
Беда в том что лично я страдаю не только как коллега, но и как пользователь вот таких вот микросервисов, думаю мне не дадут соврать что софт не становится качественно лучше для пользователей, получается что микросервис это не эволюция, правильно же? В отличии от того что вы говорите в статье.
Как по мне, тут на лицо смешение проблематик:
возможность закидать деньгами проблему, программисту дал отговорку - вместо внятной базы данных у нас куча баз данных, вместо внятного кода у нас куча сервисов, ответственность раскидана и размыта максимально, можно и работать потихоньку.
Разве только монолит дает чистоту архитектуры? Почем при микросервисной архитектуре мы не можем работать качественно? И что делать при увеличении монолита до масштабов, при которых любая доработка превращается в месяцы? Что делать по-настоящему большим сервисам с миллионами пользователей и петабайтами данных? Как масштабировать базу данных, которая выросла до неподдерживаемых размеров?
На лицо сравнение теплого с мягким.
софт не становится качественно лучше для пользователей
А тут точно проблема в инженерных подходах исключительно или есть ответственность продуктовой проработки и UX-исследований? Разве качество работы софта меряется исключительно наличием у этого софта микросервисной или монолитной архитектуры?
И тогда почему подход, в котором возможно строить что-то по-настоящему большое и масштабируемое, работающее быстро и способное выдержать хайлоад нагрузки не является эволюцией того, что устарело с точки зрения инженерных подходов и не подходит для использования с современном мире?
Вижу здесь переживания по тому, что мир изменился, а вы пока еще нет.
Это надо быть смелым, чтобы открыто признаться, что имеешь отношение к разработке rutube 😅
То есть 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.
Универсальный Backend for Frontend для всех платформ RUTUBE