Что такое GraphQL?

А, GraphQL, говоришь? Ну это такая штука, которая пришла, чтобы всем REST-архитекторам мозг вынести. Представь, обычно ты к серверу пристаёшь: «Дай пользователей» — тебе пачку юзеров вываливают, но без постов. «Дай посты» — тебе гору постов, но без имён авторов. И ходишь ты, как дурак, десять раз туда-сюда, а трафик жрёт дохуя.

А GraphQL приходит и такой: «Мужик, расслабься. Скажи мне разок, ЧТО ТОЧНО тебе надо, и я тебе принесу. Не надо прыгать по эндпоинтам, как угорелый». И это, блядь, гениально.

В чём соль, если по-простому:

• Одна дверь. Не надо бегать по разным комнатам (/users, /posts). Есть одна парадная — /graphql. Ты в неё заходишь и кричишь, что тебе принести из всего дома.
• Ты — шеф. Ты сам составляешь меню. Хочешь пользователя, но только его имя и две последние статьи — пожалуйста. Не хочешь его почту или дату рождения — не проси, и тебе её не принесут. Никакого лишнего барахла. Это называется — решает проблемы избыточности и недостаточности данных. В рот меня чих-пых, звучит-то как!
• Схема — это закон. На сервере есть строгий устав, схема. Там прописано, что можно спросить (Query), что можно изменить (Mutation) и какие данные вообще водятся. Это как инструкция к этому грёбаному API. Без неё — нихуя не работает.

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

Ты пишешь запрос, как будто пишешь, какого хуя ты хочешь:

query ПолучитьЮзераСПостами {
  user(id: 1) {
    name
    email
    posts(limit: 2) {
      title
      publishedAt
    }
  }
}

И сервер, такой предобрый, тебе в ответ выдает ровно такую же структуру, без лишних телодвижений:

{
  "data": {
    "user": {
      "name": "Иван Иванов",
      "email": "ivan@example.com",
      "posts": [
        { "title": "Первая статья", "publishedAt": "2023-01-01" },
        { "title": "Вторая статья", "publishedAt": "2023-02-01" }
      ]
    }
  }
}

Красота, да? Один запрос — и всё, что нужно, у тебя в кармане. Эффективность, блядь, зашкаливает.

А на сервере (например, на C# с HotChocolate) это выглядит так:

// Описываем тип "Юзер"
public class UserType : ObjectType<User>
{
    protected override void Configure(IObjectTypeDescriptor<User> descriptor)
    {
        descriptor.Field(u => u.Id).Type<NonNullType<IdType>>(); // ID — обязательное
        descriptor.Field(u => u.Name).Type<StringType>(); // Имя — строка
        // А посты — это отдельная история, нужен резолвер
        descriptor.Field(u => u.Posts).ResolveWith<Resolvers>(r => r.GetPosts(default!, default!));
    }
}

// Резолвер — это мужик, который бегает на склад за данными
public class Resolvers
{
    public IEnumerable<Post> GetPosts([Parent] User user, [Service] IPostRepository repo)
    {
        // Вот тут он идёт в базу и тащит посты для конкретного юзера
        return repo.GetPostsByUserId(user.Id);
    }
}

Но не всё так гладко, ёпта!

• Кэширование — пиздец. В REST закэшировал эндпоинт /users/1 — и все довольны. А тут у тебя один эндпоинт, но запросы все разные. Приходится выёбываться, кэшировать отдельные поля или результаты целиком. Головняк.
• Проблема N+1 — классика. Если не настроить специальные штуки типа DataLoader, то когда ты запросишь 100 юзеров с их постами, сервер сделает 1 запрос за юзерами и потом по 1 запросу в базу за постами КАЖДОГО из них. Итого 101 запрос. Сервер просто ляжет и захлебнётся. Надо оптимизировать, блядь.
• Запросы-монстры. Дурной клиент может прислать запрос вроде «дай юзера, его посты, комментарии к постам, авторов комментариев, их кошек и родословную кошек». И это всё одним запросом! Сервер сдохнет, пытаясь это всё собрать. Поэтому нужны лимиты на глубину запроса, на сложность и вообще rate limiting, чтобы не разориться на железе.
• Мониторинг — жесть. В REST смотришь логи: на /api/orders — столько-то запросов, на /api/products — столько-то. Всё понятно. А тут все запросы валятся в одну точку /graphql. Чтобы понять, что именно грузит систему, надо каждый запрос парсить и анализировать. Ёперный театр!

Короче, GraphQL — это мощный инструмент, но не серебряная пуля. Как говорится, доверия — ебать ноль. Подходит, когда у тебя куча клиентов (мобилка, веб, умный холодильник) и каждому нужно своё, а делать десяток REST-методок под каждого — уже сил нет. А если у тебя простенькое API на три кнопки, то, может, и не надо тут выёживаться.