Что такое GraphQL?

Давай разберемся с этой GraphQL-штукой, а то народ путается, как хуй с винтом. Представь, что ты в ресторане, а официант — это твой старый добрый REST.

Ты говоришь: «Принеси мне бургер». Он приносит бургер, картошку, салат, соусник, три салфетки и счёт, потому что на кухне так заведено. Это over-fetching — тебе навязали кучу ненужного дерьма.

Или наоборот: «Принеси мне бургер». Он приносит булочку с котлетой. «А где сыр, помидор, лук?» — «А вы не просили, это отдельный запрос». Это under-fetching — нихуя не додали, приходится бегать десять раз.

А теперь GraphQL — это как если бы ты сел и написал на бумажке: «Дайте мне бургер, но только котлету, два куска сыра чеддер, один солёный огурчик и соус барбекю. Всё остальное — нахуй не надо». И тебе приносят ИМЕННО ЭТО. Красота, да? Вот в чём вся соль, ёпта.

Так, а из чего эта хрень состоит?

• Схема (Schema): Это, блядь, священное писание твоего API. Конституция. В ней прописано ВСЁ: какие есть объекты (Пользователь, Пост), какие у них поля (имя, почта, заголовок) и как они друг за друга цепляются. Нарушил схему — получи ошибку, идиот.
• Запросы (Queries): Это когда ты вежливо просишь данные. «Дай-ка посмотреть».
• Мутации (Mutations): А это когда ты уже лезешь что-то менять, создавать или удалять. «Эй, сервер, сделай вот это дерьмо».
• Резолверы (Resolvers): А вот это, сука, самое интересное. Это такие функции-рабы на сервере. Каждому полю в схеме соответствует свой резолвер. Когда клиент спрашивает user.name, сервер орет: «Эй, резолвер для поля name у типа User! Иди нахуй в базу, достань значение и принеси сюда!». И он идёт и приносит.

Смотри, как это выглядит вживую

Ты, как клиент, пишешь запрос. Чётко, по делу:

# Слушай, сервер, сделай вот что:
query ПолучитьЮзераСПостами {
  user(id: "1") { # Найди пользователя с айдишником "1"
    name   # Мне нужно его имя
    email  # И почту
    posts(limit: 2) { # И дай его посты, но только два последних
      title        # Мне заголовок
      publishedAt  # И дату публикации
    }
    # А всё остальное — возраст, аватарку, био — не грузи, нахуй не надо.
  }
}

И сервер, такой весь в белом, отвечает тебе ровно в той же структуре:

{
  "data": {
    "user": {
      "name": "Иван Иванов",
      "email": "ivan@example.com",
      "posts": [
        { "title": "Мой первый пост", "publishedAt": "2023-01-15" },
        { "title": "Обзор GraphQL", "publishedAt": "2023-02-20" }
      ]
    }
  }
}

Ничего лишнего! Чисто, аккуратно, ебать какие мы молодцы.

Почему это овердохуище круче старого REST?

1. Ты — царь и бог данных. Получаешь только то, что попросил. Ни байта лишнего.
2. Один запрос — куча данных. Раньше чтобы получить юзера и его посты, надо было: 1) Запросить /users/1. 2) Получить оттуда список ID постов. 3) Запросить /posts?userId=1. Три запроса, ебанашка! А тут всё в одном, как шведский стол.
3. Схема — она живая и самодокументируемая. Есть встроенная хуйня под названием introspection. Ты можешь спросить у самого API: «А что ты вообще умеешь?». И тебе вывалится вся схема, по которой можно тыкать в специальной песочнице (типа GraphiQL) и строить запросы, не заглядывая в документацию (которая, как обычно, устарела вчера).

Но и тут, конечно, без ложки дёгтя не обошлось

• Кэширование. В REST всё просто: URL — это уникальный ключ к ресурсу, кэшируй на здоровье. В GraphQL все запросы обычно летят на один эндпоинт /graphql. Как их кэшировать? Приходится выкручиваться: использовать persisted queries (где запросы заранее известны серверу и имеют ID) или умные клиенты вроде Apollo Client, которые кэшируют результаты у себя, на стороне приложения.
• Проблема N+1. Это классика, просто пиздец. Допустим, ты запрашиваешь список из 10 пользователей и для каждого — его 5 постов. Наивный резолвер сделает так: 1 запрос на список юзеров, а потом для КАЖДОГО из 10 юзеров — отдельный запрос в БД за его постами. Итого 11 запросов. Овердохуище нагрузки! Решение — DataLoader. Эта хитрая жопа собирает все ID, которые нужно загрузить, в один большой пачек (batch) и одним запросом выгребает все данные, а потом раскидывает их по резолверам. Магия, ебать!

Что использовать? Сервер — Apollo Server или Yoga. Клиент — Apollo Client. Для прототипов или когда задолбало писать бэкенд — Hasura, которая из готовой PostgreSQL-базы наколдует тебе GraphQL API за пять минут.

Вот и вся история. Не бойся её, она хоть и выглядит сложно, но на деле просто даёт тебе контроль. А контроль — это сила, чувак.