GraphQL: все, что вам нужно знать

внешний интерфейс сервер API GraphQL

Исходная ссылка: https://medium.com/@weblab_tech/graphql-everything-you-need-to-know-58756ff253d8

Автор оригинала: Weblab Technology

Переводчик: Ян Тао

Вы, вероятно, некоторое время создавали и использовали REST API и недавно услышали о GraphQL — новом типе технологии API. Кто-то говорит, что это хорошо, кто-то не согласен. Что ж, я уверен, вам интересно, что удивительного в GraphQL и чем он отличается от традиционных подходов.

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

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

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

При настройке сервера GraphQL для получения и изменения данных достаточно простого URL-адреса. Таким образом, пользователь может запросить набор данных с сервера, передав строку запроса и объявив, что ему нужно.

Здесь вы можете найти нашу личную практику, прежде чем мы продолжим.graphlql-example

GraphQL VS REST

Говоря о сходстве, REST и GraphQL используются для создания API. Кроме того, ими можно управлять через HTTP. Что касается различий, REST — это, прежде всего, структурированная концепция, ориентированная на программное обеспечение, без спецификации и явного набора инструментов. Это больше связано со стабильностью API, чем с производительностью. С другой стороны, GraphQL — это язык запросов, предназначенный для управления конечными точками через HTTP, повышающий производительность и удобство использования. Я бы даже сказал, что может показаться странным сравнивать языки запросов с архитектурным стилем совместной разработки веба :). Некоторые другие заметные отличия включают в себя:

сбор информации

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

query {
  books {
    id
    title
    author
    isbn
    price
  } 
}

Помимо сбора данных

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

query {
 books {
   title
   price
 } 
}


Request: query { books { error_field } }
Response:
Request Method:POST
Status Code: 200 OK
{“errors”:[{“message”:”Cannot query field \”error_field\” on type \”Book\”.”,”category”:”graphql”,”locations”:[{“line”:3,”column”:3}]}]}

тайник

Версия

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

Устаревание легко

При использовании GraphQL вы можете легко объявить поле устаревшим. Пользователи GraphQL обязательно объявят нужные им поля.

‘author_name’ => [
  ‘type’ => Type::string(),
  ‘deprecationReason’ => ‘Deprecated. Use author field’,
 ],

API отдыха действуют по-разному. Хотя конечная точка API Basic Rest может получить, но не все конечные точки могут вернуть редкое поле. [Примечание переводчика: a. может содержать дополнительные поля] Напротив, GraphQL очень легко отслеживать использование определенных полей. Пользователи API могут развернуть, чтобы получить поля в конкретном клиенте.

оптимизация производительности

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

Недостатки GraphQL

Кэширование GraphQL — это непросто

так какофициальная документацияОн объяснил,

Проблема аутентификации

N + 1 для обнаружения и решения проблем

Что такое проблема n+1?

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

Если вы не оптимизируете свои запросы GraphQL, вы можете выполнять несколько запросов в одном запросе. Без надлежащей системы кэширования и пакетной обработки сервер будет отвечать на запрос каждый раз, когда определяется поле. DataLoader, несомненно, является лучшим решением и может значительно повысить производительность серверной части, особенно на сервере GraphQL. Опишите задачу n+1 на простом примере.

query {
 users {
    name
    education {
      degree
      year
    }
    age
    address {
      country
      city
      street
    }
  }
}

С помощью REST API легко оценивать, выявлять и решать n+1 проблему. Это отличается для GraphQL. К счастью, Facebook работает над решением этой проблемы с помощью DataLoader.

Что такое DataLoader

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

Как это работает?

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

GraphQL в запросах, мутациях и подписках

Queries

正如它的名字，Queries是客户端从服务端获取数据。和从多个端点返回详细信息的REST不一样，GraphQL只提供了一个端点，让客户端从预定义的框架决定它需要的数据。 Например:

{
 Users {
   name
 }
}


{
  “Users”: [
  {“name”: “Damira”},
  {“name”: “Michael”}
  {“name”: “Salman”}
  {“name”: “Sara”}
  {“name”: “Maria”}
]
}


{
  Users (last: 3) {
    name
    username
}}

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

Mutations

Мутации используются для создания, обновления или удаления данных. Его структура почти такая же, как у запросов, за исключением того, что в начале необходимо добавить поле «мутация». Например,

mutation {
  createUser (name : “John”, username: ”jo123”){
    name
    username
  }
}

Subscriptions

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

Лучший из двух миров

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

существуетСтек в АоллоНекоторые решения можно найти.

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

Суммировать

Напоминает о теплом приеме и отличной репутации протокола в конце 1990-х как надежного компьютерного сетевого приложения для взаимодействия со структурированными данными.SOAP. Но его нагрузка значительно выше, а предыдущие приложения, как правило, увеличивают вероятность потери данных и блокировки. REST был введен для более эффективного использования веб-серверов и повышения адаптивности. Концепция очень проста и полностью не имеет состояния, поэтому некоторые несущественные факторы можно отбросить. Кроме того, этот подход может легко работать как с JSON, так и с XML. Однако унификация данных является самым большим препятствием. Также расхождение номеров версий является еще одной проблемой. Чтобы решить эту проблему, Facebook предлагает разработчикам лучшее из обоих миров — GraphQL. GraphQL — это не решение без конкретной практической основы. RESTful зарекомендовал себя в течение многих лет с точки зрения эффективности и производительности. GraphQL может заполнить пробелы REST, а REST может заполнить пробелы GraphQL. Стоит отметить, что ситуация с GraphQL и REST очень похожа на отношения между реляционными и нереляционными базами данных. При использовании GraphQL HTTP является лучшим выбором для протокола связи между сервером и клиентом, в основном из-за его повсеместного распространения. Однако при использовании HTTP2 по-прежнему возникают проблемы с производительностью. Хотя GraphQL решает некоторые проблемы, выбрать любую спецификацию API сложно, поэтому вы можете рассмотреть возможность использования обеих. Выбор стиля API может повлиять на весь процесс API, от дизайна до общей функциональности приложения. Поэтому выбор следует делать на основе видения, а не только базовых убеждений. Этот пост полностью основан на нашем личном опыте использования обоих методов. Мы будем рады узнать ваше мнение о API GraphQL и RESTful.

немного полезной информации

https://github.com/weblab-technology/graphql-example

Implementing GraphQL as a Query Language for Deductive Databases in SWI-Prolog Using DCGs, Quasi Quotations, and Dicts

REST и веб-сервисы — Теоретически и на практике — Springer

by Oleksandr Knyga, Software Engineer Maksim Kolesnikov, DevOps Sergei Guliaev, Back-End Developer Viacheslav Eremin, Front-End Developer Sharmeen Hayat, author & Data Specialist Dima Dmytriienko, editor & Brand Specialist

Примечание переводчика

Некоторые проблемы с GraphQL, упомянутые в исходном тексте, вApollo GraphQLЭтот проект был решен в определенной степени, более чем плюс кеш.

Категории