GraphQL: является ли он “убийцей” REST API?

После внедрения поддержки GraphQL в Parse ко мне обратилось множество людей с вопросами, некоторые из которых беспокоились о будущем REST API.
Не собирается ли GraphQL “убить” его?
Что будет с моими методами REST API? Нужно ли мне переписывать свой код?

В этой статье я расскажу об этих вопросах, но короткий ответ таков: нет, вам не стоит беспокоиться, потому что GraphQL не собирается “убивать” REST API, и вам также не нужно беспокоиться о переписывании ваших уже работающих методов REST API.

Так в чем же тогда дело с GraphQL?

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

GraphQL не собирается заменять бэкенд. Как и фронтенд.

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

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

Вам не нужно беспокоиться об уже существующих и работающих методах REST API. Они продолжат работать так же, как и сейчас, даже если вы перейдете на GraphQL. Единственное, что следует отметить, это то, что GraphQL работает только на Parse 3.5.0 и более поздних версиях, поэтому, если вы переходите с Parse 2.x или более ранних версий, это также подразумевает изменение структуры кода Parse.

Так что если вы используете Parse 3.0 и выше, можете не беспокоиться. Просто выберите версию выше 3.5.0, и все будет в порядке.
Если вы используете Parse 2.X, вам придется немного переделать код.

Зачем нужен GraphQL, если мой REST API уже работает?

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

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

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

Вы сказали “ценность”?

Да.

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

Давайте пройдемся по пунктам:

• Упрощение разработки кода

  В самом начале, когда вы только начинаете работать с GraphQL, вам, возможно, придется создавать немного больше кода. Пусть это вас не пугает.
  GraphQL упростит написание запросов, особенно если вы будете использовать нашу GraphQL-консоль. Использование схем, которые Parse создает автоматически, и публикация общих и специфических методов для запросов и мутаций для всех ваших классов сэкономит вам много времени. И я действительно имею в виду много.
  Документация? Нет проблем. Мы позаботились и об этом. И она также генерируется автоматически.
  Кроме того, с GraphQL ваши разработчики смогут полагаться на те схемы, которые генерирует Parse, поэтому они будут заранее знать, какие методы им доступны, какие параметры для каждого метода, а также какие возвраты (выходы) они могут получить. Больше не нужно гадать или спрашивать у других, что делает этот метод, какие параметры требуются или что он возвращает. Все уже готово для вас.

• Упрощенное обслуживание

  Обслуживание с помощью GraphQL очень простое. Поскольку вызовы API по сути одинаковы, изменить только передаваемый запрос или мутацию, добавить или удалить возвращаемые значения или параметры так же просто, как изменить запрос или мутацию для их получения или передачи.
  Вам не придется менять множество вызовов, блоков или обещаний. Измените запрос или мутацию: ГОТОВО!

• Экономия на передаче данных

  После некоторого времени работы в Back4app мне довольно часто приходится помогать клиентам оптимизировать их код для получения более быстрых ответов. И из всех проблем, которые я нахожу в коде клиентов, подавляющее большинство связано с получением данных, которые приложению в данный момент не нужны.
  Очень распространенной ошибкой при работе с REST API или даже с фреймворками Parse является получение полной информации об объекте, а затем использование только части этой информации. Например:
  У вас есть класс Person с несколькими свойствами: имя, телефон, адрес, номер социального страхования, электронная почта, а также некоторые другие.
  Обычно люди, использующие REST API или Parse Frameworks, пытаются запросить полный объект Person, получая все его свойства, а затем используя только одно или два из них.
  С GraphQL, поскольку вы должны указать именно ту информацию, которую вам нужно получить, у разработчика нет возможности получить ненужную информацию, что приводит к гораздо меньшей полезной нагрузке, а это означает более быстрый ответ, меньшее потребление планов данных и меньший исходящий трафик в целом. Как это здорово!

Попробуйте

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

• Попробуйте создать GraphQL-запрос и не указать, что именно вы хотите получить.

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

Не хватает того, что я получаю

Вот так!

• Попытайтесь изменить объект с помощью запроса.

  Неа. Вы хотите что-то изменить? Используйте правильный метод: Мутация.
  Если вы или ваши разработчики используют неправильный метод, GraphQL не позволит им продолжить.

Запрос на изменение данных? Нет, нет, нет!

Мутация позаботится о вас!

• Несколько объектов. Несколько запросов? Нет! Один запрос!

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

Версионирование? Зачем?

Версионирование кода – это так похоже на 2018 год.
Добавьте новые поля в запрос. Старые вызовы по-прежнему будут работать:

Это работает

Это тоже работает. Вызовы старого типа будут продолжать работать.

Вы сказали, устаревшие поля? Тоже легко:

Заключение

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

Он поможет вам не сбиться с пути, когда вы оступитесь. Он подскажет вам, что можно делать, а что нельзя.

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

Если вы никогда не пробовали, то обязательно попробуйте. Все крутые ребята так делают.

Если вы хотите узнать больше о GraphQL vs REST, прочитайте наш пост на Medium.