GraphQL: Более эффективный, мощный и гибкий способ предоставления данных

Автор оригинала: David Wong.

В отчете StateOfJS: Отчет о тенденциях JavaScript Ecosphere 2018 мы увидели, что динамика развития GraphQL на уровне данных в 2018 году очень высока, и большинство пользователей хорошо ее использовали. Однако, согласно приведенным выше данным, число пользователей в Китае все еще очень мало, и большинство людей об этом не слышали. Сегодня мы представим вам GraphQL.

1. Почему появляется GraphQL?

Когда мы упоминаем дизайн API, мы обычно думаем о SOAP, RESTful и других методах проектирования. С тех пор как в 2000 году была выдвинута теория RESTful, она вызвала большой резонанс в отрасли. Поскольку эта концепция дизайна проще в использовании для пользователей, она скоро будет принята всеми. Мы знаем, что REST – популярный способ предоставления данных с серверов.

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

Так что ОТДЫХ очень подходит для многих применений. Однако среда API резко изменилась, поскольку бизнес становится более сложным, а клиенты предъявляют более высокие требования к масштабируемости системы. Особенно из следующих трех аспектов, чтобы бросить вызов способу проектирования API:

1. Взрывной рост числа мобильных пользователей требует более эффективной загрузки данных

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

2. Различные интерфейсные платформы и платформы

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

3. В различных интерфейсных фреймворках и платформах становится все труднее и труднее ускорить быструю разработку продуктов.

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

Официальное определение GraphQL: Язык запросов для API

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

Запросите необходимые вам данные: ни больше, ни меньше

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

Получение нескольких ресурсов: только один запрос

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

Опишите все возможности: системы типов

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

Разница между GraphQL и RESTful

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

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

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

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

Как REST и GraphQL решают эту ситуацию?

При использовании REST API для реальности мы обычно можем собирать данные, обращаясь к нескольким запросам.

Например, в этом примере мы можем сделать это в следующие три шага:

принять /пользователь/<идентификатор> Получение исходных Пользовательских данных
принять /пользователь/<идентификатор>/сообщения Вернуть все сообщения пользователей
запрос /пользователь/<идентификатор>/подписчики Возвращает список подписчиков для каждого пользователя

Связь вызова показана на следующем рисунке:

Если мы используем GraphQL, нам нужен только один запрос для выполнения вышеуказанных требований.

В мире GraphQL нам не нужно получать больше данных или беспокоиться о меньшем количестве данных. Нам просто нужно получить его по требованию.

Одна из наиболее распространенных проблем с REST заключается в том, что API возвращает слишком много или слишком мало данных. Это связано с тем, что единственный способ для клиентов загружать данные-возвращать конечные точки фиксированных структур данных путем доступа к ним. Это очень затруднит нам разработку API, поскольку он должен обеспечивать точные требования к данным для клиентов и удовлетворять потребности разных абонентов, что само по себе противоречиво. 。 Ли Байрон, изобретатель GraphQL, выдвинул важную концепцию: “Думайте о графике, а не о конечной точке.”

С помощью интуитивно понятного дисплея выше мы можем нарисовать несколько точек:

1. Получите много избыточных данных

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

2. Получите меньше данных, чем нужно клиенту

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

3. Быстрая итерация продукта на переднем конце создает большие проблемы для API

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

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

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

Благодаря гибкости Graphql изменения могут быть внесены на стороне клиента без дополнительной работы на сервере. Поскольку клиент может указать точные требования к данным, при изменении текущего дизайна и требований к данным не требуется никаких изменений в интерфейсе API для соответствия изменениям на уровне представления.

4. Преимущества систем схем и типов

GraphQL использует мощную систему типов для определения функций API. Все типы, представленные в API, записываются в схемах с использованием языка определения схем GraphQL (SDL).

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

Интерфейсные команды могут легко тестировать свои приложения с помощью структур данных, требуемых mocks. Как только внутренний API реализован, клиентское приложение может быть переключено на вызов фактического API для получения данных, что также позволяет нам добиться лучшего разделения между клиентом и сервером.

Грамматика GraphQL

Базовая грамматика

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

Во-первых, GraphQL-это строго типизированный язык, поэтому, когда мы определяем таблицу в базе данных, нам нужно определить тип каждого атрибута. Как показано на следующем рисунке:

Вот простое определение типа. Сначала мы определяем перечисление, затем определяем тип. В типе есть четыре атрибута: идентификатор, имя, друзья, отображается В, где идентификатор и имя являются скалярными типами, а друзья-типами людей. Это вложенный тип. Подумайте хорошенько, в этом не должно быть ничего плохого. В конце концов, ваши друзья-такие же люди, как и вы, и появляются в. ArsIn-это тип перечисления, который выглядит знакомым.

enum Episode {
  NEWHOPE
  EMPIRE
  JEDI
}
type Person{
     id: ID! 
     name: String!
     friends: [Person]
     appearsIn: [Episode]! 
}

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

Для спокойного API, в дополнение к знанию URL-адреса интерфейса, нам также необходимо знать определение параметров интерфейса. На самом деле, то же самое верно и для GraphQL. Хотя существует только один URL-адрес, разные интерфейсы различаются по типу, но что касается Restful API, параметры отражают взаимодействие между клиентом и сервером.

Например, целью запроса является пользователь, который хочет получить свое имя пользователя:

Query{
    user(id: 2) {
        id
        userName
    }
}

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

Определение интерфейса

  user: {
    type: UserType,
    args: {
      id: { type: GraphQLID }
    },
    resolve: (root, args, context, info) => {
      const { id } = args;
      return getUser(id);
    }
  }

Определение запроса

Приведенный выше код определяет только идентификатор входного атрибута, но не определяет, необходимо ли его заполнять, поэтому при запросе, если идентификатор запроса не настроен, запрос не сообщит об ошибках, а только получит результат с пустым значением null. Но чтобы быть разумными, мы надеемся, что это необходимый элемент, поэтому нам нужно изменить код сервера, будет id: { тип: GraphQLID } Заменить на id: {тип: новый GraphQLNonNull(GraphQLID)} Значение этого кода заключается в том, что ID является обязательной записью типа ID. Если мы снова выполним наш запрос, мы можем получить следующее сообщение об ошибке, которое указывает, что идентификатор является обязательным типом идентификатора, а пустой результат запроса не получен с правой стороны.

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

Корень представляет значение разрешения родительского узла этого типа (поскольку GraphQL поддерживает вложенные запросы). Как упоминалось выше, args-это промежуточная переменная, передаваемая таблицей контекста в цепочке синтаксического анализа решателя, которая аналогична контексту react. Понятие информации – это ПОСЛЕДНИЙ объект текущего запроса. Это абстрактно, но вы можете получить скомпилированный объект этого ЗАПРОСА, просмотрев информацию. Этот подход также является важной частью написания серверных служб, где мы часто можем ссылаться на существующие API Restful.

Основная концепция

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

Как и Restful API, мы определяем URL-адрес интерфейса, который запрашивает всех следующим образом: /api/v1/user/getUsers

URL-адрес интерфейса для конкретной информации пользователя запроса: /api/v1/user/getUserById

URL-адрес интерфейса для нового пользователя определяется как: /api/v1/пользователь/создать пользователя

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

Но graphql-это совершенно другой способ его использования, и URL-адрес, отображаемый на переднем конце, точно такой же /api/graphql И так далее. Как можно различить так много интерфейсов? Давайте посмотрим:

Загадка заключается в том, что на рисунке выше графический интерфейс имеет определение схемы.

Он определяет три режима работы: запрос, мутация и подписка.

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

Благодаря этому API Restful использует несколько URL-адресов для выполнения различных операций.

Вывод:

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

Часть источника контента: https://segmentfault.com/a/11…