внутренняя кросс-сервисная связь - подписка или другое? - PullRequest
1 голос
/ 22 января 2020

У меня вопрос по архитектуре, и я хотел бы услышать ваш опыт. в микро сервисной среде. когда 2 API-интерфейса GraphQl API, которые должны взаимодействовать друг с другом, asyn c через какой-то механизм pub-sub. Вы бы выбрали подписку на GraphQL? или что-то вроде системы типа kafka / rabitmq / et c. Есть ли какие-то архитектурные правила, которым я должен следовать? какие-либо критерии для такого решения? спасибо за ваши комментарии!

1 Ответ

0 голосов
/ 23 января 2020

GraphQL не обязательно является плохим выбором для межсервисного взаимодействия, но это не то, для чего GraphQL разработан и оптимизирован. В частности, для pub-sub популярны как Kafka, так и RabbitMQ. Подписки GraphQL теоретически могут быть реализованы через очередь, такую ​​как Kafka, но это добавит некоторую сложность по сравнению с использованием Kafka. GraphQL spe c мало говорит о том, как следует реализовывать подписки, а поддержка открытого исходного кода гораздо менее полная, чем для запросов и мутаций.

Плюсы подписок для сервис-публикаций. sub:

  • GraphQL предоставляет инструмент для задания формы сообщений (это также может быть достигнуто с помощью таких схем, как Avro или Protobufs).
  • Подписки GraphQL позволяют подписчикам настроить полезную нагрузку, которую они получают

Минусы:

  • Это усложняет вашу систему по сравнению с непосредственным использованием клиента Kafka
  • You потребуется больше инженерных циклов

Некоторые вопросы для рассмотрения:

  • Сколько времени вы хотите потратить на создание собственного решения по сравнению с использованием готовый код?
  • Какие аспекты GraphQL бы вам пригодились?
...