Лекция 281: Введение в GraphQL

REST нередко оказывается избыточным в предоставлении данных (over-fetching) или недостаточным (under-fetching), заставляя нас писать множество вспомогательных эндпоинтов. GraphQL пришёл, чтобы решить эти проблемы. Сегодня мы разберём, зачем он нужен, какие проблемы он решает, а уже в следующих лекциях перейдём к его интеграции с Spring Boot.

Что такое GraphQL?

Представьте себе ресторан. Вы открываете меню и заказываете конкретные блюда, точно зная, что вы получите. GraphQL — это как ресторанное меню для вашего API. Вы описываете, какие данные вам нужны, и сервер возвращает ровно это (и ничего лишнего). Этот язык запросов был разработан Facebook в 2012 году для решения проблем, которые они испытывали с REST API во время работы над своими мобильными приложениями. Позже, в 2015 году, Facebook сделал GraphQL открытым, и сейчас он используется множеством компаний, таких как GitHub, Shopify и Twitter.

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

Вот несколько ключевых характеристик GraphQL:

• Гибкость запросов. Вы сами решаете, сколько данных и каких именно вам нужно.
• Строгая типизация. Схема определяет чёткую структуру данных, что делает API предсказуемым.
• Единая точка доступа. Все запросы и мутации идут через один URL.
• Поддержка реального времени через подписки (Subscriptions).

Проблемы, решаемые GraphQL

1. Over-Fetching и Under-Fetching

Представьте, что вы работаете с REST API для получения данных о пользователях. Вам нужен только их email, но REST API возвращает полную информацию о пользователе (имя, возраст, адрес и т.д.). Это проблема избыточности данных — Over-Fetching.

Теперь представьте, что вам нужна информация о пользователях, включая их последние заказы. Разработчики REST API не добавили такой эндпоинт, и вам приходится делать два запроса: один к /users, другой к /orders. Это проблема недостаточности данных — Under-Fetching.

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

Пример запроса в GraphQL:

query {
  user(id: 1) {
    name
    email
    orders {
      id
      total
    }
  }
}

Этот запрос вернёт только необходимые поля:

{
  "data": {
    "user": {
      "name": "Иван Иванов",
      "email": "ivan@example.com",
      "orders": [
        {"id": 101, "total": 300},
        {"id": 102, "total": 150}
      ]
    }
  }
}

2. Унификация и стандартизация API

В REST API мы часто имеем кучу разрозненных эндпоинтов, таких как /users, /orders, /products. У каждого из них свои правила, параметры и ответы. GraphQL предлагает единый эндпоинт (/graphql), через который мы делаем все запросы. Это делает API более предсказуемым и удобным.

3. Масштабируемость

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

Основные концепции GraphQL

1. Строгая типизация

GraphQL использует строгую типизацию для описания данных. Это делается через схему (Schema), которая определяет все возможные типы данных и операции, доступные в API. Схема становится контрактом между клиентом и сервером.

Пример схемы:

query {
  user(id: 1) {
    name
    email
    orders {
      id
      total
    }
  }
}

Типы данных в GraphQL:

• Scalar: простые типы вроде Int, Float, String, Boolean и ID.
• Object: типы с вложенными полями (например, User, Order).
• Enum: перечисления, например, Status { ACTIVE, INACTIVE }.
• Input: типы для передачи данных в мутации.

2. Запросы (Queries)

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

Пример запроса:

query {
  user(id: 1) {
    name
    email
  }
}

3. Мутации (Mutations)

Мутации используются для изменения данных на сервере — аналог POST/PUT/PATCH в REST API. Вы можете создавать, обновлять или удалять данные.

Пример мутации:

mutation {
  createUser(name: "Иван Иванов", email: "ivan@example.com") {
    id
    name
    email
  }
}

Ответ:

{
  "data": {
    "createUser": {
      "id": "1",
      "name": "Иван Иванов",
      "email": "ivan@example.com"
    }
  }
}

4. Подписки (Subscriptions)

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

Пример подписки:

subscription {
  orderUpdated {
    id
    status
  }
}

Клиент получает обновления, как только появляются новые данные.

Преимущества GraphQL по сравнению с REST

История создания GraphQL

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

Интересный факт: GraphQL изначально разрабатывался для внутреннего использования в Facebook, но затем стал драйвером изменения подхода к API в индустрии.

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