GraphQL и gRPC — когда какой

REST — самый частый, но не единственный способ говорить с сервером. Есть две заметные альтернативы, про которые джуну стоит знать в общих чертах. В резюме потом можно будет уверенно сказать «знаком».

GraphQL

Главная альтернатива REST в мире веб-API. Создан в Facebook (Meta) в 2012-м, открыт в 2015-м.

Что меняется по сравнению с REST

В REST у каждого ресурса свой URL. Хочется получить пользователя — /users/42. Хочется его посты — /users/42/posts. Хочется комментарии к каждому посту — ещё запросы. Чтобы отрисовать сложный экран, нужно сделать несколько запросов и собрать данные на клиенте.

В GraphQL — один endpoint, обычно /graphql, на который клиент POST-ит запрос (query) с описанием, что именно ему нужно:

POST /graphql
Content-Type: application/json

{
  "query": "
    {
      user(id: 42) {
        name
        posts {
          title
          comments {
            text
            author { name }
          }
        }
      }
    }
  "
}

Сервер возвращает ровно те поля, что попросили, в той структуре, в которой попросили:

{
  "data": {
    "user": {
      "name": "Anna",
      "posts": [
        { "title": "Привет", "comments": [{ "text": "+1", "author": { "name": "Bob" } }] }
      ]
    }
  }
}

Сильные стороны

• Один запрос — полный экран. Меньше round-trip-ов, меньше overfetching (получить 30 полей, использовать 3).
• Типизированная схема. Сервер описывает все типы и связи, инструменты сами генерят клиентский код, документация всегда актуальна.
• Один endpoint — меньше путаницы. Не нужно помнить десятки путей.

Слабые стороны

• Сложнее кэшировать. REST использует HTTP-кэширование «из коробки»; в GraphQL все запросы POST на один URL — стандартный браузерный кэш не работает.
• Сложнее по инфраструктуре. Сервер сложнее (резолверы, защита от тяжёлых запросов, ограничение глубины), клиент часто использует Apollo, Relay, urql — ещё одна зависимость.
• Файлы и стримы — не родные. Грузить аватарку через GraphQL можно, но это всегда хак.

Когда стоит использовать

GraphQL хорошо ложится на сложные сервисы с большим количеством сущностей и связей между ними (соцсети, маркетплейсы, CMS). Плохо — на простые CRUD-сервисы, где REST короче и понятнее.

gRPC

Совсем другой зверь. Создан в Google, опубликован в 2016-м. Используется в основном между серверами, а не для веб-клиентов — но знать про него тоже полезно.

Что отличает

• Бинарный протокол. Данные не в JSON, а в Protocol Buffers — компактном бинарном формате. Парсится быстрее, по сети летит меньше.
• Контракт в .proto-файле. Описываете сервисы и методы в специальном файле, инструменты генерят клиентский и серверный код на любом языке.
• HTTP/2 под капотом. Из коробки multiplexing, streaming в обе стороны, header compression.
• Стримы. Поддерживает unary (запрос → ответ), server streaming, client streaming, bidirectional.

Где живёт

В мире микросервисов — внутри инфраструктуры компании. Сервис заказов общается с сервисом инвентаря через gRPC: быстро, типизированно, без лишних килобайт JSON. Для веб-клиентов чистый gRPC не работает (нет поддержки в браузерах), есть обёртка gRPC-Web — но это всё ещё нишево.

Большинству фронтендеров gRPC напрямую не касается. Но если попадёте в команду, которая делает SDK или общается с микросервисной кухней через прокси — знать про существование стоит.

Кратко в одной таблице