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

REST — набор уникальных идентификаторов (URL), которые приложения используют для запроса и отправки данных.

GraphQL — язык запросов, который позволяет клиентским приложениям точно задавать данные, которые им нужны, из одного эндпоинта.

Это связанные технологии, они используются в основном для одних и тех же вещей (а могут и сосуществовать), но при этом они весьма разные.

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

Вы на коктейльной вечеринке

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

Их именные наклейки следующие:

Ричи Рест (Richy REST)
Друг Ричи Реста (Friend of Richy REST)
Работодатель Ричи Реста (Employer of Richy REST)
Джорджия ГрафКьюЭль (Georgia GraphQL)

Будучи активным и общительным тусовщиком, вы подходите прямо к Ричи Ресту и говорите: «Привет, я Адам Эпликэйшн, а ты кто?» Ответ Ричи Реста таков:

{
  name: "Richy REST",
  age: 33,
  married: false,
  hometown: "Circuits-ville",
  employed: true
  // ... 20 other things about Richy REST
}

Про себя вы подумали «Ого, слишком много информации сразу». Пытаясь избежать неловкого молчания, вы вспоминаете, что Ричи Рест упоминал, что он работает, и спрашиваете: «Где ты работаешь?»

Удивительно, но Ричи Рест понятия не имеет, где он работает. Может быть, Работодатель Ричи Реста в курсе?

Вы задаете тот же вопрос Работодателю Ричи Реста, который с удовольствием отвечает на ваш вопрос:

{
  company: "Mega Corp",
  employee_count: 11230,
  head_quarters: "1 Main Avenue, Big City, 10001, PL"
  year_founded: 2005,
  revenue: 100000000,
  // ... 20 other things about Richy REST Employer
}

К этому моменту вы уже измотаны. Вы уже даже не хотите знакомиться с другом Ричи Реста! Это может занять вечность, растратить всю вашу энергию, и у вас к тому же у вас уже нет времени.

Тем не менее, Джорджия ГрафКьюЭль стоит совсем рядом, и вы решаете поболтать с ней.

«Привет, как тебя зовут?»

{   
  name: "Georgia GraphQL"
}

«Откуда ты и сколько тебе лет?»

{
  hometown: "Pleasant-Ville",
  age: 28
}

«Сколько у тебя хобби и друзей и как зовут твоих друзей?»

{
  hobbies_count: 12,
  friends_count: 50,
  friends: [
    { name: "Steve" },
    { name: "Anjalla" },
    // ...etc
  ]
}

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

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

Закончим с метафорами. Перейдем к делу

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

1. Несколько обращений при получении связанных ресурсов

Управление данными мобильных и веб-приложений часто требует связанных ресурсов и наборов данных. Таким образом, получение данных с использованием REST API может повлечь за собой многочисленные запросы к многочисленным эндпоинтам. Например, запрос Post и связанного с ней Author может быть совершен двумя запросами к разным эндпоинтам:

someServer.com/authors/:id
someServer.com/posts/:id

Многократные обращения к API влияют на производительность приложения. Это еще более важно для устройств с низкой пропускной способностью (например, смарт-часы, IoT, старые мобильные устройства и т.д.).

2. Over-fetching и under-fetching

Избыточное (Over-fetching) / недостаточное (under-fetching) извлечение данных неизбежно при использовании RESTful API. Используя приведенный выше пример, эндпоинт domainName.com/posts/:id извлекает данные для определенной записи. Каждая запись состоит из атрибутов, таких как id, body, title, publishingDate, authorId, и другие. В REST ответ предварительно определен и всегда возвращается один и тот же объект данных.

В ситуациях, когда требуются только заголовок и текст записи, происходит чрезмерное извлечение данных (over-fetching), поскольку по сети отправляется больше данных, чем фактически используется.

Когда требуется вся публикация вместе со связанными данными об ее авторе, происходит недостаточная выборка (under-fetching) — поскольку по сети отправляется меньше данных, чем фактически используется. Недостаточное извлечение(under-fetching) данных приводит к увеличению количества API-запросов и, как следствие чрезмерному использованию интернет-ресурсов.

Клиентские запросы с GraphQL

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

«Результаты возвращаются в той же форме, что и запросы»

/* Query */
{
  myFriends(first: 2) {
    items {
      name
      age
    }
  }
}

/* Response */
{
  "data": {
    "items": [
      { "name": "Steve", "age": 27 },
      { "name": "Kelly", "age": 31 }
    ]
  }
}

Проверка в реальных условиях

Теперь вы, вероятно, думаете, что работать с GraphQL так же легко, как нарезать теплое масло самурайским мечом. Это может быть верно для фронтенд разработчиков. Однако когда дело доходит до настройки серверной части, кто-то должен сделать самую сложную работу. Наша подруга Джорджия ГрафКьюЭль приложила немало усилий, чтобы стать классным профессионалом.

Создание GraphQL API на стороне сервера требует времени, усилий и опыта. Тем не менее те, кто готов к испытаниям, в состоянии с этим справиться. Есть много разных способов сделать это, например:

Самостоятельно: если вы действительно хотите сделать все самостоятельно, попробуйте построить API GraphQL с помощью пакетов. Используете Rails? Попробуйте graphql-ruby. Любите Node.js? Попробуйте express-graphql.

С помощью: если гибкая настройка хостинга является для вас приоритетной, то что-то вроде Graph.cool может помочь вам приступить к проекту GraphQL.

Мгновенно: Устали писать шаблон CRUD и хотите быстро начать работу? 8base предоставляет мгновенный API GraphQL и серверный бэкенд, который можно расширять.

В завершение

Для веб-сервисов REST стал значительным шагом вперед, позволив легко создавать API для доступа к необходимым ресурсам. Тем не менее, его дизайн не учитывал текущего распространения мобильных устройств, с различными ограничениями на объем загрузки данных и требованиями. Это упущение привело к росту популярности GraphQL, которое Facebook сделал open source в 2015 году, прежде всего за счет гибкости, которую он дает фронтенд разработчикам. Работа с GraphQL — это фантастический опыт как для отдельных разработчиков, так и для команд.