про свою зону ответственности. И есть некоторое SPA приложение, которое работает одновременно с пачкой микросервисов. То есть оно само знает когда, куда и что нужно сделать. Когда надо в один сервис стукнутся а когда в другой. Нет кейсов про распределенные транзакции или чего то подобного. Ребята с команды SPA поднимают вопрос, что им не очень то и удобно. Они владеют инфой по каждому сервису, и сложность кода возрастает. Поэтому у них есть идея, организовать некий "еще один сервис" который как бы в себе с агрегирует все общение между сервисами внутри себя. Я вроде как то читал что такое вполне себе допустимо, и вроде как правильно. Но есть всякого рода риски, что теперь это третий сервис должен всегда следить за всеми изменениями в других сервисах. То есть по сути они предлагают переложить часть логики работы SPA в новый агрегационный сервис. Скажите плюсы и минусы, и стоит ли так делать или нет?
backend for frontend, BFF
угу, спс, я помню что читал про такое.
Это один из самых важных паттернов в микросервисной системе, ИМХО
у нас в целом даже речь пошла про шаринг кода между проектами. Забыл как называется гугловская штука.
protobuf кажется, вспомнил
bff, graphql federation и подобные штуки
ну это прям координально для нас все ломает. Если мы по bdd до этого не работали, и экспертизы нету, то прикинь сколько его придется внедрять везде. Графкл тоже по сути не очень нужен, потому что договоренность сложилась уже про рест и jsend форматы.
ну graphql federation это скорее на почитай подумать, это спокойно заменяется какими гейтвеями. просто как идею покрутить посмотреть.
угу, это обязательно сделаю раз советы такие даете. Вот про применимость у нас это конечно большой вопрос. Н
А можно вопрос, ты говоря про gql federation имел ввиду то, что у тебя 1 мкросервис в который ты обращаешься, а он уже сам понимает в какой Микросервис ему идти за нужной схемой или ты говорил про резолвинг схем одного Микросервиса на другой ? (Просто вторая штука рождает пробоемки)
Первое, но схема тянется заранее. Обращение к gw, он знает кто отвечает за query(или конкретные поля внутри)/mutation/subscription
Да, она уже в гейтвее находится, просто я на практике сталкивался со 2ым вариантом, но там еще поверх этого был прикручен rmq и получилось, что у вас 2 варианта общения между микросервисами, редкостное г...вно
Обсуждают сегодня