Отличия GraphQL от REST API на практике (второе приближение)

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

Если мы что-то меняем через GraphQL, этот запрос называется мутацией. Подарим через мутации пару звёздочек почти наугад выбранному в предыдущей статье разработчику с Github. Для этого добавим в запрос получения репозиториев из предыдущей статьи их id:

query { 
  user(login: "mihdan") {
    repositories(first: 3) {
      nodes {
        id
        name
        description
        url
      }
    }
  }
}

Копируем любой id из ответа и вводим его в мутацию добавления звездочки на Github:

mutation {
  addStar(input: {starrableId: "MDEwOlJlcG9zaXRvcnk1OTk5Mzk5"}) {
    starrable {
      stargazerCount
      stargazers(first: 10) {
        nodes {
          name
        }
      }
      viewerHasStarred
    }
  }
}

Задав необходимые данные ответа(количество клиентов GitHub подаривших звёздочку mihdan, их имена и также проверим, учтён ли наш голос) мы именно их и получим на выходе:

{
  "data": {
    "addStar": {
      "starrable": {
        "stargazerCount": 2,
        "stargazers": {
          "nodes": [
            {
              "name": "Mikhail Kobzarev"
            },
            {
              "name": "Zorca Orcinus"
            }
          ]
        },
        "viewerHasStarred": true
      }
    }
  }
}

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

mutation {
  addStar(input: {starrableId: "MDEwOlJlcG9zaXRvcnk1OTk5Mzk5"}) {
    starrable {
      stargazerCount
      stargazers(first: 10) {
        nodes {
          name
          repositories(first: 3) {
            nodes {
              name
              description
              url
            }
          }
        }
      }
      viewerHasStarred
    }
  }
}

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

Мнения игроков рынка веб-разработки

Послушаем различных игроков рынка веб-разработки и узнаем, что они думают о GraphQL. Условно назовём этих персонажей: фронтендер Максим, бекендер Константин и владелец веб-студии Леопольд.

Дадим слово фронтендеру Максиму: «Ранее на проектах с REST API я тратил достаточно много времени на изучение всех эндпойнтов, структур ответов бекенда и часто возникали ошибки из-за недопонимания с бекендерами и не вовремя обновленной документации по API. Вместе с GraphQL я получил удобный инструмент отладки запросов прям на локальной машине без использования клиентов наподобие Postman, а свежая документация по API приходит ко мне с бекенда мгновенно, достаточно обновить схему с основного сервера», — сказал он, не долго думая.

Бекендер Константин был более краток: «GraphQL интересная технология, но требует серьезного изучения, многие концепции не имеют аналогий в REST API, что еще больше затрудняет понимание. Пока воздержусь от перехода полностью на GraphQL на всех проектах, если только это не будет жестко прописано в ТЗ».

Ну а у владельца веб-студии Леопольда видимо накипело: «Со своей колокольни я не вижу никаких отличий. Мне все равно, на чем будет реализован новый проект. Моя задача сделать его себестоимость ниже без потери качества. Я уже устал искать специалистов на GraphQL, так как его пока плохо кто понимает. Тем не менее свежий проект у нас реализовался гораздо быстрее, как раз с использованием GraphQL. А денег ушло меньше. Совпадение? Не думаю».

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

Когда применять GraphQL вместо REST API?

Рассмотрим две ситуации: у нас новый свежий проект и старый зрелый проект, требующий большой аккуратности и содержащий массу легаси-кода.

Зрелый проект

Бекендер: «НЕТ (однозначно нет, так как для перехода на GraphQL придётся переписать весь роутинг как минимум)». Фронтендер: «ДА (этим ребятам легче всего в этой истории)». Владелец бизнеса: «НЕТ (дорого переписывать кодовую базу и переучивать сотрудников)».

Новый проект

Бекендер: «50/50 (скала уже не так прочна, но сомнения есть)». Фронтендер: «ДА (а что любители Node.js теряют?)». Владелец бизнеса: «ДА (применение GraphQL может существенно снизить издержки на ведение документации и разработку)».

Ну что ж, GraphQL пока не смог положить соперника на обе лопатки, но всё еще впереди! :-)