Введение

Две основные формы проектирования и взаимодействия, которые мы используем в современной разработке API, — это REST и GraphQL.

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

PS: Если вы хотите углубиться в детали REST, прочтите эту статью.

Хотя GraphQL был впервые использован в продакшне компанией Facebook в 2012 году (под названием SuperGraph), с открытым исходным кодом он стал доступен только в 2016 году.

GraphQL в настоящее время является наиболее популярным подходом к разработке API и взаимодействию с REST.

Почему был создан GraphQL?

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

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

Ниже приведен пример REST-ответа, который "слишком велик" для требований мобильной версии, а нам нужна только часть информации.

{
	"user": {
		"id": 5,
		"name": "Yakumo",
		"surname": "Mutsu",
		"rank": 56,
		"email": "mutsuenmei@gmail.com",
		"profilephoto": "....................."

	}
}

Однако, когда пользовательские данные загружаются первый раз, в мобильной версии нам нужна только их часть. Тем не менее, распределение этих данных на основе ресурсов (REST) кажется идеальным выбором для проектирования. Поскольку в десктопной версии почти нет проблем с интернетом, не возникает сложностей с получением данных из разных ресурсов и отображением их в качестве единого объема информации. Во-первых, после загрузки данных пользователя, на основе его id подгружаем другие данные. То есть мы проводим своего рода синхронную операцию.

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

Что такое GraphQL?

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

GraphQL сейчас широко используется и при проектировании микросервисов.

REST в сравнении с GraphQL

1. Используемая нами форма дизайна REST API обычно предназначена для десктопных устройств. В большинстве случаев для мобильных устройств требуется облегченная, менее ресурсоемкая версия того же самого эндпоинта. Таким образом, используя GraphQL, мы можем получить лишь необходимые данные в соответствии с требованиями мобильного устройства. (уменьшение избыточной и недостаточной выборки)

2. REST обычно имеет ресурсно-ориентированный дизайн. Когда возникает необходимость в прогнозировании ресурса, сначала должен быть получен родительский ресурс, а затем вызываются другие дочерние ресурсы. Это своего рода синхронный и отложенный вызов, поскольку вы не можете получить информацию о зависимом ресурсе, пока не будет загружен один главный ресурс (несколько эндпоинтов, несколько запросов).

3. REST обычно возвращает одни статические данные для каждого эндпоинта. Однако, даже если мы обращаемся только к одному эндпоинту с помощью GrahpQL, то можем получить различные структуры данных. (Гибкий поиск данных)

4. Чтобы получить информацию из нескольких ресурсов в REST, необходимо запрашивать их по отдельности. Это часто приводит к несвоевременному получению данных, если дополнительно не использовать какие-либо методы. GrahpQL позволяет получить данные из нескольких ресурсов с помощью одного запроса и представить ее пользователю в виде единой информации. (Уменьшение количества запросов)

5. Изменения в дизайне REST сопряжены с версионированием. GraphQL преодолевает проблему версионирования и позволяет вносить дополнения более удобным образом, не добавляя изменений на другой стороне.

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

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

8. В микросервисной архитектуре каждый сервис отвечает за свои ресурсы, и GrahpQL является хорошим выбором при получении информации от нескольких сервисов и отображении их как единого ресурса.

9. При разработке одностраничных или нативных мобильных приложений принцип GrahpQL "давать только ту информацию, которая нужна пользователю" и "есть ресурс, а не ресурсы" позволяет разрабатывать приложения с "тяжелым" фронтендом.

10. Быстрая итерация - фронтенд работает над своей собственной историей пользователя, не завися от бэкенда. Он не ждет, пока бэкенд подготовит REST эндерпоинт.

Глагольные операции, такие как PUT, DELETE, POST и PATCH в REST дизайне, на языке GrahpQL называются просто Mutation (мутация).

GET в REST API в GraphQL называется Query.

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

Завтра вечером пройдет бесплатный урок, посвященный написанию библиотеки для работы с базами данных на C#. На этом занятии рассмотрим стандартные механизмы работы с базами данных на основе ADO.NET и механизмы рефлексии. В качестве примера практической реализации разработаем собственную micro-ORM систему для быстрого и удобного доступа к данным в PostgreSQL.

Урок будет полезен для разработчиков, желающих детальнее погрузиться в основы платформы .NET и научиться решать сложные задачи более лаконично за счет встроенных особенностей языка C#.

• Зарегистрироваться на открытый урок