GraphQL

GraphQL — язык запросов и рантайм для API от Facebook (2012, open source 2015). Клиент указывает КАКИЕ поля ему нужны, сервер возвращает ровно их. Решает over/under-fetching REST.

Три операции

• Query — чтение (аналог GET)
• Mutation — изменение (аналог POST/PUT/DELETE)
• Subscription — стрим через WebSocket или SSE

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

query {
  user(id: 42) {
    name
    email
    posts(limit: 5) {
      title
      comments {
        author { name }
        text
      }
    }
  }
}

Ответ

{
  "data": {
    "user": {
      "name": "Vasya",
      "email": "v@example.com",
      "posts": [
        {"title": "Hi", "comments": [...]}
      ]
    }
  }
}

Schema (SDL)

type Query {
  user(id: ID!): User
  users(limit: Int = 10): [User!]!
}

type User {
  id: ID!
  name: String!
  email: String
  posts: [Post!]!
}

type Post {
  id: ID!
  title: String!
  author: User!
}

type Mutation {
  createUser(input: UserInput!): User!
}

Транспорт

Обычно POST /graphql с телом {"query": "...", "variables": {...}}. Тело всегда одинаковый эндпоинт → HTTP-кеширование ломается.

Плюсы

• Клиент запрашивает только нужное
• Одна request — вложенные ресурсы
• Строгая типизация
• Интроспекция схемы (автогенерация клиентов)
• Subscriptions real-time

Минусы

• Кеширование сложно (все запросы POST на один URL)
• N+1 проблема без DataLoader
• Легко сделать дорогой запрос (depth limit, complexity limit нужны)
• File upload не в спеке (есть extension graphql-multipart)

Persisted queries

Клиент шлёт хеш запроса, сервер знает по хешу что за query. Экономит трафик, защищает от arbitrary queries.

Federation / Composition

Apollo Federation, GraphQL Fusion — объединение нескольких GraphQL-сервисов в единую схему для клиента.

Кто использует

• Facebook (родоначальник)
• GitHub API v4
• Shopify, Twitter (deprecated их REST), Airbnb, Netflix
• Yandex, Ozon (частично)

См. также

• REST, API, JSON-RPC