Тёмный

apollo federation пример графа с тремя независимыми сервисами 

Alexandr Marchenko
Подписаться 164
Просмотров 886
50% 1

Пытаюсь показать в чем суть федеративного графа
Получилось долговато, но надеюсь что суть понятна, ключевые плюшки:
- Я как разработчик сервиса могу его разрабатывать, запускать и деплоить независимо от всех остальных сервисов (читай для разработки мне не нужно подмывать окружения 100500 других сервисов)
- Я как разработчик сервиса не парюсь, что же понадобиться клиенту из другой сущности, т.к. я возвращаю только ее id, а дальше клиент по ней сможет забрать все что его душе угодно
- Мы как команды пилящие сервисы можем дополнять сущности друг друга, при этом не мешая друг другу и не вклиниваясь в спринты друг друга
- Используя graph manager я как разработчик сервиса, могу посмотреть какие поля больше не нужны и спокойно удалить их из своего сервиса, что бы не было хлама
- Используя graph manager я как разработчик сервиса, получу ранний фитбек, о том что внесенные мною изменения в сервис поломают пару клиентов с указанием на примеры запросов которые они шлют
Есть и пару минусов:
- В федерации начинаются проблемы если два сервиса обявили два типа с одинаковым именем и разными полями - гейт в таком случае говорит, что нет, я так работать не буду т.к. не знаю куда слать запросы, никто не объявил себя влядальцем сущности
- В graph manager нельзя просто так взять и удалить поле, нужно делать все по честному, аля объявлять его deprecated, обновлять клиентов и уже затем удалтять иначе оно просто не запустится

Опубликовано:

 

30 сен 2024

Поделиться:

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист
Посмотреть позже
Комментарии : 5   
@alexandersmirnov4274
@alexandersmirnov4274 3 года назад
спасибо за материал можете дать ссылку на сорцы чтобы можно было все вместе запустить
@marchenkoalexandr
@marchenkoalexandr 3 года назад
к сожалению pull request с имплементацией забуксовал, т.к. ребятам там сейчас пилят следующую мажорную версию и эта штука не в фокусе, можно подсмотреть тут - github.com/graphql-dotnet/graphql-dotnet/pull/1669 и там же есть ссылка на intro видео в котором примеры кода что бы все это завелось
@Влад-д2и4ъ
@Влад-д2и4ъ 2 года назад
хм, а как быть когда для каждой записи по связи выполняется запрос? Это крайне не оптимально. Может прикручивали dataLoader`ы?
@marchenkoalexandr
@marchenkoalexandr 2 года назад
Да, dataLoader'ы это must have без оговорчный, дело в том что даже если не предпологается история с федерацией и графами, dataLoader'ы защищают от ситуаций когда фронт почему то решил вычитать список идентификаторов, и затем для каждого запустить запрос за инфой - dataLoader'ы помогают бэку защититься от любых даже самых не лепых use case'ов. Для того что бы все работало есть смысл разрабатывать все таким образом, что бы всюду методы принимали список идентификаторов, условно за вместо getUserBy(id int) в сервисе/репозитории есть смысл забегая на перед делать сразу getUserBy(id int[]) тогда внедрение dataloader будет задачей на пять сек. PS: и нет в демках дата лодера нет исключительно для простоты, т.к. тут о федерации, а не оптимизации 🤷‍♂️
@Влад-д2и4ъ
@Влад-д2и4ъ 2 года назад
​@@marchenkoalexandr спасибо за развернутый ответ
Далее
React Tutorial for Beginners
1:20:04
Просмотров 3,2 млн
КВН 2024 Встреча выпускников
2:00:41
The architecture of Federation
24:58
Просмотров 10 тыс.