Сегодня в нашем современном мире разработчиков совершенно невозможно представить жизнь без таких технологий, как React, Node JS, GraphQL и так далее. Они имеют солидные ранги и занимают лидирующие позиции в предоставлении данных. 70% случаев, с которыми я сталкиваюсь, — это проекты, которые интегрированы с GraphQL или собираются на него мигрировать. Все больше и больше компаний предпочитают использовать синтаксис запросов данных Graphql, и сегодня это обязательные знания.

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

Apollo Server предоставляет инструменты для отправки ответов на запросы клиентов. Клиент Apollo дает возможность использовать Graphql API, включая кеширование и связывание.

О чем это?

Мы собираемся создать два сервера Apollo, которые будут обрабатывать слияние схем Graphql. Это ситуация, когда какой-то внешний сервер отвечает API-интерфейсом Graphql, а какой-то другой сервис использует собственную схему GraphQL, включая внешнюю схему. На уровне узла мы собираемся обернуть результаты с внешнего сервера в одну схему и отправить ее клиенту. Буквально мы собираемся просто объединить две схемы в одну и отправить ее клиенту.

Давайте углубимся в код

Для реализации мы собираемся использовать среду Node JS, промежуточное ПО Koa и сервер Apollo с инструментами GraphQL.

Нам нужно запустить два сервера. Оба должны иметь сервер GraphQL Apollo. Вот схема.

Пришло время создать шаблоны и запустить их оба. Для этого нам нужно создать две папки и назвать одну папку примерно так: boilerplate-raphql-koa-server-external и вторую папку так: boilerplate-graphql-koa-server

Прежде чем начать, взгляните на структуру папок в обоих проектах. Довольно просто. Разница между этими двумя репозиториями будет в коде.

├── package.json
└── src
    ├── index.js
    ├── resolvers.js
    └── schema.js

Внешний сервер GraphQL

Теперь давайте настроим boilerplate-graphql-koa-server-external

Затем создадим сам сервер. В папку src в папкеindex.js добавляем настройку сервера:

Асинхронная функция server позаботится о самом приложении koa, и мы собираемся создать сервер apollo с исполняемой схемой, где мы должны предоставить типы из схемы и преобразователей. Из официальных документов мы должны позвонить apopServer.start() заранее перед apolloServer.applyMiddleware . Это позволяет выявлять потенциальные проблемы и предпринимать действия в случае сбоя процесса при запуске Apollo Server вместо того, чтобы начинать обслуживать запросы.

Вторая часть — это схема установки boilerplate-graphql-koa-server-externallet и преобразователи.

Резолверы для схемы.

Теперь пришло время проверить ответы сервера. Перед этим не забудьте установить пакеты: npm i, а затем выполнить команду npm run start и ввести в браузере Chrome URL: http://localhost:4000/api/v1/graphql. Нажмите на кнопку Запросить ваш сервер, и вы сможете получить интерфейс apollographql. Это позволяет вам увидеть запрошенную схему с сервера. Откройте страницу Схема самоанализа. Там вы увидите нашу схему:

Если вы смогли изучить схему, это означает, что мы закончили с нашим boilerplate-graphql-koa-server-external

Сервер GraphQL для слияния схем

Теперь перейдем к boilerplate-graphql-koa-server настройкам. В package.json есть почти все то же самое, что и в external, но с дополнительными пакетами и другими PORT, названием и описанием.

Давайте сразу настроим новую схему. В схеме есть почти такие же, но немного разные данные.

И резольверы:

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

Самое главное, мы должны быть уверены, что наша схема загрузилась и внешний сервер не выдает никаких ошибок. Мы должны поймать эту ситуацию. Как видно в коде, мы получили просто массив схем. По умолчанию у нас есть только наш собственный internalSchema, а затем, если доступен внешний сервер, мы проталкиваем в этот массив externalSchema, а затем используем инструмент mergeSchemas, который помогает предоставить объединенную схему прямо в ApolloServer

Установите все пакеты и запустите сервер, который будет доступен на PORT=3000 . Перейдем к тому же интерфейсу apollographql, но URL должен быть с правильным ПОРТОМ: http://localhost:3000/api/v1/graphql. Теперь, если мы откроем страницу Introspection Schema, мы сможем увидеть объединенные схемы. Один с внешнего и другой с последнего созданного сервера.

Имейте в виду, что если некоторые из ваших серверов получат одно и то же поле, сервер GraphQL выдаст ошибку, примерно такую:

Error: Unable to merge GraphQL type “Query”: Field “getFakeDataExample” already defined with a different type. Declared as “DataExample”, but you tried to override with “DataExternalExample”

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

Репозитории GitHub
https://github.com/antonkalik/boilerplate-graphql-koa-server
https://github.com/antonkalik/boilerplate-graphql -koa-сервер-внешний

Документы по загрузке схемы
https://www.graphql-tools.com/docs/schema-loading

Заключение

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

Спасибо за внимание.