Как правильно сархитектурить graphQL в микросервисах?

Question

[Иван Веков]

Всем привет!

Есть приложение (точнее оно в процессе разработки). Изначально стали по старинке пилить взаимодействие микросервисов через ресты и очереди. Потом вспомнилось, что это уже не модно (я про фронт) и существует довольно интересная штука, под названием graphQL.

Сейчас написаны всего 2 сервиса. К одному уже прикрутили реализацию через граф (lumen+lighthouse). А дальше что-то я не справился. По хорошему, хочу сделать один общий graphql-сервис, для обработки запросов с фронта. Как это сделать?

Почитал про федерации, поставил Apollo... Ничего если честно не понял. Как это должно работать? Типа есть N сервисов, у каждого своя схема и Аполло их как-то сам должен подтягивать? Или все схемы должны находиться на Аполло Сервере и иметь запросы к сервисам? Какие тогда запросы - рест? Странно как-то.
У меня после прочтения, было ожидание, что я поставлю аполло и он сам всё сделает. В итоге с оф документации у меня получилось что отдельно есть Аполло со своей схемой и отдельно сервисы со своими схемами....

Мб я вообще не в ту степь копаю, и Аполло тут не при чем.

Answer 1

[Иван Шумов]

Не надо так делать. Graphql это только gateway. Использовать его как интерфейс к базе данных, даже через бизнес-логику это такое себе решение. Хотя можно, конечно, кто же спорит. Федерации это удобно, но на масштабе проще застрелиться, чем заниматься этим. Сам aplollo ничего не сделает за вас - это фреймворк, не больше) ну и большое комьюнити с готовыми модулями

Comments

[Иван Веков]

Резонный вопрос - а как тогда делать надо? :)

[Иван Шумов]

Иван Веков, апи делается по одному из готовых паттернов: тот же http rest или любой rpc. Все это заворачивается в резолверы и мутаторы на graphql gateway. Важно понимать что основная задача graphql - создание гибких view с минимальным числом запросов. То есть - для spa и мобилок. Остальное - дополнительные возможности

[Иван Веков]

Иван Шумов, хорошо, но я всё ещё не улавливаю конкретики. Речь о том, что не стоит делать свои граф-схемы для каждого сервиса? Типа делаем везде обычный рест апи и создаем схемы на гейтвее, которые резолвятся этими рест-запросами?

[Иван Шумов]

Иван Веков, да

Answer 2

[Иван Веков]

Иван Шумов, возможно дал дельный совет, но всё же я решил разобраться с федерациями. Нашёл готовый гейтвей nautilus, который на мой взгляд, идеально решает задачу.
То есть по факту у нас сейчас 3 сервиса, и один общий гейтвей, который ретранслирует расширенный API, автоматически собирая его с других сервисов.
Возможно, пока не столкнулся с проблемами, но на данный момент получил именно то, чего хотел.
Насчёт "Не надо так делать. Graphql это только gateway. Использовать его как интерфейс к базе данных, даже через бизнес-логику это такое себе решение. " - на данный момент не могу полностью согласиться. Получается очень удобно расширять схемы и достаточно независимо (в плане разработчиков - каждый меняет свой граф, а не общий).

Comments

[Иван Шумов]

Вот когда валидация атрибутов понадобится, а не только из тип - тогда и будет разговор) или когда сервис будет минуту прожёвывать схему при запуске )

[Иван Веков]

Иван Шумов, да, я понимаю что такое вполне возможно) Отметил оба ответа решением, потому что всё же, в некоторых случаях, использование федераций - мне кажется, приемлемым. Спасибо за ответ, удачно подсветили минусы такого подхода.
У нас планируется довольно ограниченное кол-во сервисов, каждый поддерживается разными командами, на фронте SPA. Пока что кажется, что проблем быть не должно) Если столкнёмся - вернусь к этому треду :)