Архитектура GraphQL и Microservice

Ответ 1

Определенно подход № 1.

Когда ваши клиенты разговаривают с несколькими службами GraphQL (как в подходе № 2), полностью побеждает цель использования GraphQL, в первую очередь, чтобы обеспечить схему по всем вашим данным приложения, чтобы обеспечить ее выборку в одном обратном направлении.

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

GraphQL и микросервисы идеально подходят, потому что GraphQL скрывает тот факт, что у вас есть микросервисная архитектура от клиентов. С точки зрения бэкэнда вы хотите разделить все на микросервисы, но с точки зрения внешнего вида вы хотели бы, чтобы все ваши данные поступали из одного API. Использование GraphQL - это лучший способ, которым я знаю, что позволяет вам обоим. Он позволяет разделить ваш сервер на микросервисы, одновременно предоставляя единый API всем вашим приложениям и позволяя объединять данные из разных служб.

Если вы не хотите использовать REST для своих микросервисов, вы можете, конечно, иметь каждый из них собственный API GraphQL, но у вас все равно должен быть API-шлюз. Причина, по которой люди используют шлюзы API, - сделать ее более управляемой для вызова микросервисов из клиентских приложений, а не потому, что она хорошо вписывается в шаблон микросервисов.

Ответ 2

Смотрите статью здесь, где рассказывается, как и почему подход № 1 работает лучше. Также посмотрите на изображение ниже, взятое из статьи, которую я упомянул:

Одним из основных преимуществ наличия всего за одной конечной точкой является то, что данные могут маршрутизироваться более эффективно, чем если бы у каждого запроса была своя собственная служба. В то время как это часто рекламируемое значение GraphQL, снижение сложности и проскальзывания сервиса, результирующая структура данных также позволяет очень четко определять и четко определять владение данными.

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

Следующая статья объясняет эти два преимущества вместе с другими очень хорошо: https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/

Ответ 3

Для подхода № 2, по сути, такой способ я выбрал, потому что это намного проще, чем поддерживать надоедливый API-шлюз вручную. Таким образом, вы можете развивать свои услуги самостоятельно. Сделай жизнь намного проще: P

Есть несколько отличных инструментов для объединения схем в одну, например, graphql-weaver и apollo graphql-tools. Я использую graphql-weaver, он прост в использовании и отлично работает.

Ответ 4

По состоянию на середину 2019 года решение для 1-го подхода теперь носит название "Федерация схемы" , придуманное людьми из Аполлона (ранее это часто называли GraphQL шить). Для этого они также предлагают модули @apollo/federation и @apollo/gateway.

ДОБАВИТЬ: Обратите внимание, что с федерацией схемы вы не можете изменять схему на уровне шлюза. Так что для каждого бита, который вам нужен в вашей схеме, вам нужен отдельный сервис.

Ответ 5

Я работал с GraphQL и микросервисами

Исходя из моего опыта, мне подходит комбинация обоих подходов в зависимости от функциональности/использования, у меня никогда не будет единого шлюза, как в подходе 1... но я буду использовать graphql для каждого микросервиса как подход 2.

Например, основываясь на изображении ответа от Enayat, в этом случае я хотел бы иметь 3 шлюза графика (не 5, как на рисунке).

• Приложение (продукт, корзина, доставка, инвентарь, необходимые/связанные с другими услугами)

• Оплата

• пользователь

Таким образом, вам нужно уделить дополнительное внимание дизайну необходимых/связанных минимальных данных, предоставляемых различными сервисами, такими как токен авторизации, идентификатор пользователя, платежное состояние, статус платежа

Например, по моему опыту, у меня есть шлюз "Пользователь", в котором GraphQL у меня есть пользовательские запросы/мутации, вход в систему, вход, выход, изменение пароля, восстановление электронной почты, подтверждение электронной почты, удаление учетной записи, изменение профиля, загрузка изображения и т.д. сам по себе этот график довольно большой !, он разделен, потому что в конце другие службы/шлюзы заботятся только о получающейся информации, такой как идентификатор пользователя, имя или токен.

Этот способ легче...

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

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

• История ваших репозиториев более понятна, и у вас может быть репозиторий/разработчик/команда, предназначенная для шлюза и задействованных микросервисов.

Ответ 6

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

Ответ 7

Подробнее о микросервисах, я думаю, что GraphQL может отлично работать и в серверной архитектуре. Я не использую GraphQL, но у меня мой собственный подобный проект. Я использую его как агрегатор, который вызывает и концентрирует многие функции в одном результате. Я думаю, вы можете применить тот же шаблон для GraphQL.