В этой статье мы обсудим проблему получения данных из нескольких источников, сохраняя при этом скорость работы нашего интерфейса, а также потенциальное решение: использование шлюза GraphQL.
Как инженеры-программисты, мы все сталкивались с проблемой объединения данных из многих систем. Даже для одной страницы требуются данные из нескольких сервисов.
Данные повсюду: от CRM до финансовых систем, от SaaS-платформ до баз данных. Каждый бизнес неизбежно покупает множество SaaS-платформ, а затем хочет получить единое бизнес-представление поверх всех них. Мы должны принять это и интегрировать все.
Шлюз GraphQL сочетает в себе преимущества традиционного шлюза API с GraphQL.
Мы начнем с обсуждения преимуществ шлюза API, а затем посмотрим, как GraphQL вписывается в него. Дочитайте до конца статьи, где мы рассмотрим некоторые платформы для создания собственного шлюза API.
Преимущества API-шлюза
Защита наших общедоступных API от хакеров — это работа на полный рабочий день. Со временем организации стали создавать множество API, от SOA до микросервисов. Вместо того, чтобы размещать эти API непосредственно в Интернете, организации предпочитают добавлять дополнительный уровень безопасности, который находится перед всеми этими API и гарантирует, что доступ к данным всегда соответствует одним и тем же правилам аутентификации.
Они делают это с помощью шлюза API.
Такие продукты, как Kong или Apigee, предоставляют внутренние API из централизованного расположения. Они действуют как обратный прокси-сервер с такими функциями, как управление ключами API, ограничение скорости и мониторинг.
Шлюз API позволяет нам контролировать, кто и что имеет доступ к каждому сервису, отслеживая соединения и регистрируя доступ.
Совсем недавно приложения стали обязаны объединять данные из шлюза API и других внешних поставщиков SaaS. Это означает, что старый централизованный инструмент, который обеспечивал соблюдение наших правил, теперь регулярно обходится.
Представьте, что мы создаем веб-приложение для нашей компании. У нас есть задача создать страницу профиля пользователя. В процессе входа нам необходимо объединить данные из многих систем:
- Salesforce CRM : содержит общие данные о клиентах, такие как имя и фамилия.
- Заказы : последние заказы находятся в системе заказов внутри организации.
- Служба уведомлений : настройки уведомлений и последние сообщения находятся в базе данных конкретного приложения, подключенной к службе Node.js.
Клиенту потребуется сделать три отдельных запроса для получения данных, как показано на рисунке ниже.
На изображении выше веб-клиент отправляет три отдельных запроса API, а затем должен объединить результаты в коде внешнего интерфейса. Отправка нескольких запросов влияет на производительность приложения, а объединение этих данных увеличивает сложность кода. Кроме того, если имеется более одного приложения, теперь все приложения должны знать обо всех серверных компонентах, и одно изменение API в одной службе может привести к обновлениям всех наших приложений.
Мы можем добиться большего. В идеале мы хотим сократить количество запросов с трех до одной выборки. Для этого мы могли бы создать новую службу — службу, которая организует запросы к серверным службам. У этой идеи есть название: паттерн BFF.
Шаблон архитектуры Backend -for-frontend (BFF) допускает один запрос от внешнего интерфейса.
Но как это работает? Давайте рассмотрим этот узор более подробно.
Преимущества шаблона BFF
При использовании шаблона BFF приложение отправляет один запрос шлюзу API. Затем служба BFF запрашивает данные от каждой серверной службы и объединяет их. Наконец, данные фильтруются, возвращая только те данные, которые необходимы для внешнего интерфейса, что сокращает объем данных, передаваемых по сети.
Как показано на изображении выше, мы добавили в стек дополнительный уровень для оркестрации запроса.
Конечная точка профиля пользователя возвращает данные, необходимые для этого приложения, на странице профиля. Сокращение трех запросов до одного устранило предыдущую проблему с производительностью.
Но мы еще не закончили.
Компания решила выпустить мобильное приложение. В мобильном приложении также есть страница профиля, но на этом экране отображается гораздо меньше информации о профиле.
На данный момент у мобильной команды есть два варианта. Команда может повторно использовать конечную точку веб-группы, что будет означать, что мы избыточно извлекаем данные (извлекаем больше данных, чем необходимо для мобильного приложения). Альтернатива заключается в том, что мобильная команда создает своего собственного лучшего друга.
Неудивительно, что мобильная команда решает создать свой собственный лучший друг, поскольку им нужна хорошая производительность своего приложения.
Как показано на изображении выше, ситуация начинает усложняться, и теперь у нас есть две новые проблемы:
- Каждой команде приходится создавать новый сервис BFF для каждого создаваемого ими приложения, что замедляет работу каждой команды и затрудняет стандартизацию.
- Каждый лучший друг должен быть проверен на проникновение, чтобы убедиться в его безопасности.
Как мы решаем эти проблемы?
Нам нужно решение, в котором каждое приложение сможет выбирать нужные ему данные, и это должен быть единый API, используемый всеми приложениями в компании.
По мере развития BFF многие разработчики начали экспериментировать с GraphQL вместо REST.
Давайте посмотрим, как эта технология может помочь.
Преимущества GraphQL для лучшего друга
GraphQL имеет множество сильных сторон, которые делают его идеальной технологией для лучшего друга:
- Эффективная выборка данных. GraphQL позволяет клиентам запрашивать именно те данные, которые им нужны, и не более того. Это повышает производительность за счет уменьшения объема данных, передаваемых из API.
- Единая конечная точка. Вместо предоставления доступа к множеству конечных точек через шлюз GraphQL использует одну конечную точку для всех запросов. Это упрощает обслуживание и необходимость версии.
- Гибкие запросы. Клиенты могут создавать запросы, объединяя поля и связи в один запрос. Это позволяет разработчикам внешнего интерфейса оптимизировать получение данных, повышая производительность. Кроме того, если требования к интерфейсу изменятся, его можно обновить для получения других данных без какого-либо изменения серверной части.
Фронтенды теперь могут выбирать только те данные, которые им нужны для каждого запроса.
Теперь мы можем подключить оба наших приложения к одному и тому же серверу GraphQL, что уменьшает необходимость во втором сервисе BFF.
Теперь мы можем поделиться лучшими друзьями для любого приложения в организации. У нас также есть единственная конечная точка, которую необходимо протестировать на проникновение.
Но опять же, мы представили новую проблему! Нам по-прежнему приходится управлять двумя системами — шлюзом API и GraphQL BFF.
Что, если мы объединим их в шлюз GraphQL?
Далее давайте посмотрим, как работает шлюз GraphQL.
Что такое шлюз GraphQL?
Шлюз GraphQL объединяет шлюз API с API GraphQL, чтобы получить лучшее от обеих технологий.
Подведем итоги преимуществ:
- У разработчиков есть одна конечная точка API для запроса данных. Это уменьшает избыточную или недостаточную выборку, поскольку каждое приложение выбирает только те данные, которые ему необходимы.
- Шлюз GraphQL используется многими приложениями в организации. Это означает, что мы сократили воздействие на безопасность до одной конечной точки API.
- Теперь, когда BFF объединен со шлюзом, нам нужно управлять только одной службой.
На диаграмме ниже показано, как запрос API профиля пользователя работает со шлюзом GraphQL.
На изображении выше клиент отправляет один запрос шлюзу GraphQL, запрашивая необходимые ему данные. Шлюз делает индивидуальные запросы к каждому сервису и объединяет результаты. Теперь у нас есть только один сервис для управления и развертывания.
Надеюсь, вы готовы попробовать это сами. Далее давайте посмотрим, как мы можем построить шлюз GraphQL.
Создание шлюза GraphQL
При выборе платформы шлюза мы хотим обратить внимание на некоторые ключевые особенности:
- Несколько источников. Шлюз должен подключаться ко многим источникам данных — от баз данных до SaaS — и мы должны иметь возможность создавать наши соединения.
- Маршрутизация. Шлюз должен иметь возможность напрямую запрашивать данные у базовых служб.
- Пакетирование. Несколько запросов к одной и той же службе отправляются пакетно, что сокращает количество запросов.
- Безопасность. Аутентификация и авторизация должны контролировать, кто может получить доступ к подключенным данным.
- Межисточниковая фильтрация. Должны быть доступны мощные фильтры, чтобы не допускать чрезмерной выборки данных, необходимых клиенту.
- Расширяемый. Разработчики должны иметь возможность расширять код с помощью промежуточного программного обеспечения или функций в соответствии со своими потребностями.
Существует множество фреймворков на выбор, но вот три лучших, которые я рекомендую изучить подробнее.
Hasura
Hasura приобрела популярность с годами, первоначально как сервер GraphQL-over-Postgres. Однако добавлена возможность подключения к внешним системам.
Мы можем подключить «Удаленную схему», которая объединяет GraphQL с других серверов.
У этого подхода есть некоторые недостатки. Во-первых, нам нужно создавать нашу удаленную схему и управлять ею в отдельном сервисе, и этот сервис должен быть конечной точкой GraphQL. Это приводит ко второй проблеме: мы не можем напрямую подключить источник данных.
Кроме того, Hasura не позволяет нам фильтровать данные в одном источнике данных на основе значений в другом. Это может показаться академичным, но на самом деле довольно часто мы хотим выразить что-то вроде: «Дайте мне заказы, в которых имя клиента — „ABC“.
Это обеспечивает гибкость, но за счет запуска нескольких сервисов. Давайте рассмотрим вариант, который будет подключаться напрямую.
StepZen
StepZen позволяет нам подключаться к источнику данных напрямую с сервера GraphQL. Это уменьшает необходимость запуска нескольких служб для создания шлюза.
Чтобы подключить Stepzen к источнику данных, мы создаем файл схемы GraphQL следующим образом:
type Query { anything(message: String): JSON @rest ( endpoint: "https://httpbin.org/anything" method: POST headers: [ {name: "User-Agent", value: "StepZen"} {name: "X-Api-Key", value: "12345"} ] postbody: """ { "user": { "id": "1000", "name": "The User" } } """ ) }
В этом примере мы подключаем сервер к базе данных, используя пользовательскую схему.
Есть еще один вариант, который вы можете предпочесть, — это подход, основанный только на коде. Давайте посмотрим на это дальше.
Graphweaver
Последние несколько лет я работал над продуктом с открытым исходным кодом под названием Graphweaver, который можно использовать в качестве шлюза GraphQL.
Он подключается напрямую к нашим источникам данных и мгновенно создает API GraphQL. Этот API включает в себя все операции CRUD, которые мы можем создавать, читать, обновлять и удалять. Он автоматически генерирует фильтры, аргументы сортировки и разбиения на страницы, экономя время. Мы можем расширить встроенные операции с помощью нашего кода для обеспечения полной гибкости.
Graphweaver имеет готовые коннекторы данных для таких баз данных, как Postgres и Mysql, а также поставщиков SaaS, таких как Xero и Contentful.
Внесение изменений или подключение источников данных предполагает написание машинописного кода, что дает нам полную настройку.
Заключение
В этой статье мы рассмотрели, как заменить текущий шлюз API и шаблон BFF одним шлюзом GraphQL.
Мы рассмотрели преимущества шлюза API и почему организации их используют. Контроль версий, ограничение скорости и управление доступом — вот некоторые из причин.
Мы также рассмотрели шаблон BFF и то, как он организует запросы API для внешних приложений.
Наконец, мы рассмотрели GraphQL и то, насколько эта технология полезна для лучших друзей.
В конечном итоге это привело нас к созданию шлюза GraphQL, и мы рассмотрели три варианта создания собственного: Hasura, StepZen и продукт, над которым я работал, Graphweaver.
Я надеюсь, что эта статья убедила вас попробовать собственный шлюз GraphQL, и если да, то вы рассмотрите возможность попробовать Graphweaver.
