Принятие GraphQL: смена парадигмы в разработке API

Вы слышали о GraphQL? Этот язык запросов API, изначально разработанный Facebook (ныне Meta), превратился в процветающую экосистему. Изучите эту статью, чтобы понять, почему важно принять эту новую парадигму API.

Сложная программная инженерия ставит новые задачи

Схема API

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

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

Протоколы API

Хотя модель запрос-ответ HTTP хорошо работает для запросов или отправки данных в традиционных REST API, работа с часто изменяющимися данными требует таких подходов, как long polling или WebSocket. Хотя эти методы жизнеспособны, в настоящее время нет готового механизма, который бы бесшовно балансировал между эффективностью и контролем затрат в этих двух режимах.

Проблемы в сложных сценариях

Раньше разработчикам нужно было предоставить только веб-страницу на основе API, чтобы пользователи могли получать доступ к данным напрямую через HTML в браузерах. С наступлением мобильной эры разработчики теперь должны предоставлять нативные приложения для платформ Android и iOS. Эти приложения ориентированы на разные группы пользователей и их привычки, каждая из которых имеет различную плотность информации. Поддержка всех платформ через один API становится сложной задачей, так как уникальные требования к данным и взаимодействию для каждой платформы требуют специфических API. На стороне сервера разработчики также сталкиваются с расширяющимися источниками данных, такими как реляционные базы данных или кэши Redis. Правильное управление сохранением данных и кэшированием при предоставлении запросов для клиентов — это значительная проблема.

GraphQL: Упрощение разработки API

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

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

Заключение

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

В отличие от REST API, GraphQL позволяет разработчикам постепенно улучшать свои API без ведома пользователей, будь то добавление новых API или полей. Нет необходимости в версионировании, что нарушает работу пользователей, зависящих от старых версий API. Многие платформы теперь предоставляют GraphQL API, включая GraphQL API Meta, используемый в их мобильном приложении, а также GitHub и Shopify, которые предоставляют GraphQL API напрямую для использования разработчиками.