В рамках продвижения нашего нового курса Apache Kafka для разработчиков недавно мы рассматривали RESTful API к этой Big Data платформе потоковой обработки событий на примере Confluent REST Proxy. Сегодня разберем альтернативу REST-интерфейсам в виде GraphQL и применимости этой технологии к разработке распределенных Kafka-приложений.
Что такое GraphQL и чем он лучше REST
Напомним, REST – это архитектурный стиль взаимодействия компонентов распределенного приложения в сети, который использует HTTP-протокол для передачи данных. Подробно об этом мы писали здесь. Такая архитектура проектирования API позволяет реализовать веб-сервисы с предопределенным набором операций без сохранения состояния, включая запросы GET, POST, PUT и DELETE. При гибкости и масштабируемости RESTful API за счет возможности обработки разных форматов данных, а также разделения клиентов и сервера, эта технология имеет следующие ограничения [1]:
- излишек данных, когда конечная точка API предоставляет гораздо больше информации, чем требуется клиенту;
- невозможность передать все нужные данные в рамках одного запроса, когда конечная точка API не предоставляет всю необходимую информацию сразу и клиент должен сделать несколько запросов, чтобы получить все, что нужно приложению.
В масштабе Big Data эти ограничения выливаются в огромный объем трафика, который передается между распределенными узлами сети, в т.ч. от множества клиентов до сервера. Поэтому в 2015 году корпорация Facebook разработала GraphQL и запустил его в производство для собственных проектов. В феврале 2017 года был опубликован первый общедоступный GraphQL API [2].
GraphQL – это язык запросов, используемый клиентскими приложениями для работы с данными, независимо от источников их изначального хранения: СУБД, файловое или объектное хранилище и пр. Можно сказать, что GraphQL (GQL) развивает REST-технологию, используя для передачи данных клиенту и получения их от него, простые GET или POST-запросы. При этом реализуются все четыре CRUD-функции (Create, Read, Update, Delete), которые являются базовыми при обработке данных. В GraphQL простые запросы (query) обеспечивают чтение данных. А запросы на изменение данных называются мутациями (mutation). Они выполняют операции создания (Create), обновления (Update) и удаления (Delete) записей. Мутации могут быть в виде базового механизма RPC (Remote Procedure Call, вызов удалённых процедур) для решения различных задач, например, для передачи пользовательских данных внешнему API. Работа технологии на клиенте сопряжена с передачей запроса на GQL-сервер, который обычно представляет собой обычный HTTP-сервер, куда присоединена GraphQL-схема. Схема обеспечивает возможность работы с различными форматами данных: JSON, AVRO и пр. [3].
Рассмотрим простой пример сравнения REST и GQL на кейсе отображения фида пользователя со списком сообщений его самого и подписчиков. Необходимо отображать автора сообщения, само сообщение, а также подписчиков этого пользователя. При использовании REST-технологии потребуется сделать 2 или 3 запроса [1]:
- / user / <id>, чтобы получить сведения о пользователе (авторе), такие как имя;
- / user / <id> / posts, чтобы получить список сообщений, опубликованных этим пользователем;
- / user / <id> / followers, чтобы получить список подписчиков этого пользователя.
При этому во всех этих запросах передается слишком много данных. Например, в первом запросе нужно только имя, но в ответ придут все подробности о пользователе.
В случае GraphQL нужно указать запрос, и получить желаемый результат:
query {
User(id: ‘123’) {
name
posts {
title
}
followers {
name
}
}
}
Таким образом, GraphQL – это архитектура проектирования API, при которой все рассматривается как связанный граф. Это также означает, что можно настроить свой запрос так, чтобы с конечной точки запрашивать что угодно и получать лишь то, что было запрошено. Это позволяет объединять разные сущности в один запрос, сокращая объем передаваемого трафика. Дополнительным плюсом является быстрота разработки на клиенте. Например, при изменении требований к данным, нужно просто изменить запрос, не меняя целиком весь продукт. Благодаря этому и клиентская, и серверная команды могут работать слажено и независимо дуг от друга, если они знают новую структуру данных. Обратной стороной этих достоинств являются следующие ограничения GQL [1]:
- сложность настройки типов и запросов для простых приложений;
- одна конечная точка вместо спецификации HTTP для кэширования, которое на сетевом уровне может уменьшить объем трафика на сервер.
Разобравшись с основами GQL, рассмотрим, как использовать эту технологию в области Big Data при создании приложений Apache Kafka для потоковой обработки событий.
Apache Kafka для инженеров данных
Код курса
DEVKI
Ближайшая дата курса
20 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
GraphQL и потоковая обработка событий в Big Data с Apache Kafka
Сегодня парадигма потоковой обработки событий (event streaming processing), в основном, реализуется, через модель «издатель-подписчик». В GQL подписка — это тип первого порядка, основная сущность, которую публикует API. Запрос — это тоже тип, как и мутация. При создании подписки генерируется тип корневого уровня, Subscription, а затем подчиненный атрибут, который представляет собой конкретную подписку.
Подписки GraphQL кардинально меняют способ взаимодействия разработчиков с API, предоставляя доступность из единого интерфейса синхронного HTTP-запрос/ответа и асинхронные взаимодействия, управляемые событиями. Подписки обеспечивает асинхронную связь с GQL API. Можно рассматривать подписки как механизм потоковой передачи, встроенный в GQL, который позволяет асинхронно посылать сообщения из API для логики выполнения запросов или мутаций. Например, API GQL представляет службу бронирования мест в самолете. При типичном взаимодействии с HTTP API резервирование места может занять некоторое время из-за задержки сети и синхронного характера парадигмы «запрос-ответ». Поэтому в пользовательском веб-GUI нельзя пометить место как зарезервированное до завершения HTTP-запроса и получения ответа. Это может привести к конфликту, когда одно и тоже место будет зарезервировано одновременно разными пользователями. В GraphQL API разработчик может реализовать подписку, которая асинхронно отправляет сообщение до того, как действие по резервированию места будет выполнено внутри API. Потребитель GQL API немедленно получает сообщение от сервера подписки, доступного по тому же доменному имени или IP-адресу, что и сервер API, и может пометить место как зарезервированное. Так снижается риск одновременного бронирования мест.
Подписки могут быть связаны с настраиваемым типом, который описывает атрибуты отправляемого сообщения. При регистрации на получение сообщений из конкретной подписки, можно определить нужные атрибуты: все или некоторые из них.
Физическая реализация подписки GraphQL требует использования брокера сообщений: Apache Kafka, Redis или RabbitMQ. Чем RabbitMQ отличается от Apache Kafka, мы рассказывали здесь.
Примечательно, что при разработке подписок GraphQL можно использовать практически любую технологию обмена сообщениями. Например, одна из наиболее популярных реализаций GQL, Apollo GraphQL Server, использует протокол WebSocket и поставляется с брокером сообщений, установленным по умолчанию. Однако, вариант по умолчанию предназначен только для разработчиков и не рекомендуется для производственной эксплуатации (production). Кроме того, вместо WebSocket можно использовать другой протокол асинхронной связи, например, XMPP или AMQP [4], который распространен в решениях интернета вещей (Internet of Things), о чем мы упоминали здесь.
В области Big Data в качестве наиболее популярного брокера сообщений и платформы потоковой обработки событий выступает Apache Kafka, которая также поддерживает технологию GraphQL, например, с помощью GraphKL. Этот простой и мощный фреймворк реализует потоковую передачу в интуитивно понятную среду GQL для готовых приложений Apache Kafka. GraphKL расширяет GraphQL и Kafka, обеспечивая простое решение для чтения, записи и обработки потоковых данных в реальном времени в любом масштабе, используя мощную семантику с динамическими запросами, мутациями, подписками и фрагментированными запросами. GraphKL позволяет описать преобразования потоковой обработки вместо разработки Java- или Python-приложения, предоставляя возможности объединения, агрегирование, оконные операций и многое другое. Этот фреймворк распространяется бесплатно под лицензией Apache 2.0 и доступен для скачивания в Github [5].
Практические проекты применения GraphQL c Apache Kafka с примерами кода приведены в источниках [6, 7]. Завтра мы продолжим изучать Apache Kafka и рассмотрим кейс немецкой железнодорожной компании Deutsche Bahn.
Администрирование кластера Kafka
Код курса
KAFKA
Ближайшая дата курса
9 декабря, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
А изучить все особенности администрирования кластера Apache Kafka и разработки приложений потоковой аналитики больших данных вы сможете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
- https://medium.com/javascript-in-plain-english/stop-using-rest-for-apis-d697727ae6dd
- https://www.programmableweb.com/api-university/guide-to-graphql-understanding-building-and-using-graphql-apis
- https://habr.com/ru/company/ruvds/blog/445268/
- https://www.programmableweb.com/news/how-to-build-streaming-api-using-graphql-subscriptions/how-to/2019/12/09
- https://github.com/scigility/kafka-graphql
- https://github.com/openweb-nl/kafka-graphql-examples
- https://jivimberg.io/blog/2018/10/23/reactive-graphql-subscriptions-from-kafka/
