Переход к федеративному API GraphQL

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

Чтобы это сияло, мне нужно было иметь глубокое понимание того, как работает GrahQL и что происходит внутри.

В этом посте я расскажу о том, что входит в жизненный цикл федеративного GraphQL API. Мы возьмем очень простой Federated GraphQL API, созданный с помощью NodeJS, и перехватим его трафик с помощью HTTP Toolkit.

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

Проект размещен по адресу:

https://github.com/susamn/gateway?embedable=true

В службе Federated GraphQL шлюз отвечает за

1. Консолидация всех составляющих структур схемы службы GraphQL.
2. Проверьте все службы, выполнив запрос и убедившись, что API-интерфейс graphql, предоставляемый всеми компонентными службами, правильно интегрирован.
3. Когда вызов поступит на шлюз, поймите этот запрос и решите, какой запрос нужно сделать для всех предполагаемых служб.
4. Выполняйте параллельные запросы ко всем соответствующим службам и ждите ответа
5. Получите ответы, объедините их и отправьте вызывающему абоненту, а также добавьте соответствующие ошибки, если какая-либо ошибка была отправлена ​​любая ошибка.

Здесь у нас есть 2 федеративные службы.

Служба 1: Служба для сотрудников

https://gist.github.com/susamn/2a9ac5a98f3d605b9388fcc1c956d925#file-employee -graphql?embedable=true

Служба 2: Адресная служба

https://gist.github.com/susamn/9c424b2967626b17010674930fd9bcac#file-address -graphql?embedable=true

Тип Address расширяет тип Employee и предоставляет адресные данные для каждого сотрудника.

А вот и мой Шлюз.

https://gist.github.com/susamn/ae1457213017942153829dde3f8f87f0#file-gateway -js?embedable=true

Код готов и при запуске:

npm run server

мы готовим наш сервер шлюза

Перейдем к http://localhost:4001 и убедимся, что наш сервер готов, выполнив запрос.

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

Запустим HTTP Toolkit и выберем Fresh Terminal.

и запустите ту же команду, чтобы запустить службу в только что открытом терминале, чтобы HTTP Toolkit мог перехватывать трафик, и мы могли знать, что с ним происходит.

Давайте посмотрим, что происходит.

Первый запрос, сделанный шлюзом к службам Address и Employee, одинаков и выглядит следующим образом:

{"query": "query __ApolloGetServiceDefinition__ { _service{sdl} }"}

Это шлюз, проверяющий службы путем проверки схемы служб.

Служба сотрудников отвечает:

https://gist.github.com/susamn/88bae9a650ce35a10596730457b36650_definition_employee -graphql?embedable=true

И служба Адреса отвечает:

https://gist.github.com/susamn/1fc361ce93910c258e611e720c038ee7#file-address_definition -graphql?embedable=true

После проверки структур схемы шлюз готов принимать входящие вызовы. Давайте отладим и это.

Вот наш запрос:

{
  employeeData(id:332233){
    employeeId
    address{
      addressId
    }
  }
}

* Идентификатор сотрудника будет получен из службы сотрудников. * Идентификатор адреса будет получен из службы адресов.

Как и ожидалось, мы видим 2 звонка из шлюза в службу.

Первый вызов службы Employee.

https://gist.github.com/susamn/5c8cdd4302735e27317632d273b16c89#file-employee -graphql?embedable=true

и звонок в адресную службу.

https://gist.github.com/susamn/e147931dcb6ba348dbf67561835463d7#file-address_request -graphql?embedable=true

Обратите внимание на несколько вещей.

1. Первый звонок сотруднику говорит сам за себя, это простой звонок.
2. Второй вызов Address является фрагментом Employee. Выбор фрагмента — это только данные, необходимые из адреса, то есть addressId. Данные передаются в разделе переменных, и предоставляется только employeeId, поскольку он нужен только службе адресов.
3. Адресные данные используют переданные им данные и используют свой преобразователь для получения адреса сотрудника.
4. Здесь важно направление. Поскольку адрес зависит от сотрудника, а направление — от сотрудника → адрес, шлюз отправляет фрагмент в службу адресов для разрешения.

Теперь ответы.

Ответ службы сотрудников на шлюз n

https://gist.github.com/susamn/59078056793fbbbse69b7f004e907db8bc_file-employedres#file-employee_response-graphql?embedable=true -graphql?embedable=true

Ответ службы адресов на шлюз

https://gist.github.com/susamn/c459c51d24bc8486604c8be63231a591_responseaddress -graphql?embedable=true

n Шлюз, наконец, объединяется и отправляет ответ как:

https://gist.github.com/susamn/f0b953abc4caf076453b100720fd837a#file-gateway_gateway -graphql?embedable=true

Вот и все, наше путешествие завершено.

Несколько вещей, о которых следует помнить при разработке GraphQL Federated API

• После создания и размещения службы вручную выполните вызов HTTP GET с использованием запроса SDL, n {“query”: “query ApolloGetServiceDefinition { _service{sdl} }”}
• Внимательно посмотрите на схему, очень легко допустить ошибку, и вдруг федерация потерпит неудачу.
• Вызов всех служб должен быть параллельным и независимым. Позаботьтесь об этом.
• В случае возникновения ошибки возвращайте их разумно, чтобы клиент знал о них.

Надеюсь, вам понравилось путешествие. До скорой встречи.

Первоначально опубликовано здесь.