Имеет ли смысл использовать GraphQL для взаимодействия микросервисов?

Question

Я много читал об использовании GraphQL в качестве шлюза API для внешнего интерфейса перед микро-сервисами.Но мне интересно, все ли преимущества GraphQL перед Rest не имеют отношения и к микросервисам.Будем благодарны за любые входные данные, плюсы / минусы и примеры успешного использования.

Answer 1

У меня нет опыта использования GraphQL в среде микросервисов, но я склонен думать, что он не самый лучший для микросервисов.

Чтобы добавить немного больше цвета в ответ @Lior Bar-OnGraphQL - это больше язык запросов и более динамичный характер.Он часто используется для объединения наборов данных в результате одного запроса, который, в свою очередь, может потребовать много запросов ко многим службам в среде микросервиса.В то же время это также усложняет необходимость перевода сбора информации из соответствующих источников информации (других микросервисов).Конечно, насколько сложным будет зависеть то, насколько микро ваши сервисы и какие запросы вы можете поддерживать.

С другой стороны, я думаю, что монолит, использующий архитектуру MVC, может иметь преимущество, потому что онвладеет большим объемом данных, которые он может запросить.

Answer 2

Ключевые примечания к сведению r:

• GraphQL не волшебная пуля и не "лучше", чем REST.Он просто другой.
• Вы можете определенно использовать оба одновременно, поэтому это не так и / или.
• Для конкретного использования GraphQL (или REST) ​​может находиться в любом месте шкалыот великого до ужасного.
• GraphQL и REST не являются точными заменами:
  • GraphQL - это язык запросов, спецификация и набор инструментов, предназначенных для работы с одной конечной точкой через HTTP, оптимизирующих производительность и гибкость.
  • REST - это архитектурный стиль / подход для общего общения, использующий единый интерфейс протоколов, в которых он существует.

Некоторые причины, по которым следует избегатьРаспространенное использование GraphQL между микросервисами :

• GraphQL в основном полезен, когда клиенту требуется гибкий ответ, которым он может управлять без внесения изменений в код сервера.

  • Когда вы предоставляете клиентскому сервису контроль над поступающими данными, это может привести к раскрытию слишком большого количества данных, что может поставить под угрозу инкапсуляцию в обслуживающем сервисе.Это долгосрочный риск, связанный с ремонтопригодностью системы и возможностью ее изменения.

• Между микросервисами задержка является гораздо меньшей проблемой, чем между клиент-сервером, поэтому идет на агрегациюВозможности.

• Унифицированный интерфейс действительно полезен, когда у вас много сервисов, но GraphQL может быть непродуктивным для этой причины.

• Гибкийзапросы, определенные QueryQL, могут быть более сложными с точки зрения оптимизации производительности.

• Одновременное обновление иерархии объекта (естественная структура graphQL) может добавить сложности в атомарности, идемпотентности, сообщении об ошибках,и т. д.

Подведем итог :

• GraphQL может быть очень полезен для обмена данными между серверами, но, скорее всего, это будетхорошо подходит для небольшого процента вариантов использования.
• Есть ли у вас сценарий использования для шлюза API между службами?Может быть, это вопрос, который вы должны задать себе.GraphQL - это просто (популярный) инструмент.
• Как всегда, лучше всего сопоставить проблему с инструментом.