gRPC, GraphQL и WebSocket: урок к собеседованию

REST по-прежнему основной стиль API, но в вакансиях всё чаще встречаются gRPC между сервисами и GraphQL для фронтенда. На собесе ждут не глубины, а понимания, чем они отличаются и что в них тестировать.

gRPC

RPC-фреймворк: клиент вызывает метод удалённого сервиса как обычную функцию.

syntax = "proto3";

service Orders {
  rpc GetOrder (GetOrderRequest) returns (Order);
  rpc WatchOrder (GetOrderRequest) returns (stream OrderEvent);
}

message GetOrderRequest { int64 id = 1; }
message Order {
  int64 id = 1;
  string status = 2;
  optional int32 discount = 3;
}

Контракт в .proto, из него генерируют код клиента и сервера.
Транспорт HTTP/2, данные в бинарном Protobuf: глазами трафик не прочитать.
Четыре вида вызовов: унарный, серверный поток, клиентский поток, двунаправленный поток.
Свои коды статуса: OK 0, INVALID_ARGUMENT 3, DEADLINE_EXCEEDED 4, NOT_FOUND 5, PERMISSION_DENIED 7, UNAVAILABLE 14, UNAUTHENTICATED 16. HTTP-статус транспорта при этом обычно 200.
Дедлайны: клиент задаёт крайний срок, по истечении вызов завершается DEADLINE_EXCEEDED.
Метаданные: аналог заголовков, в них передают токен.

Инструменты: grpcurl, Postman, Insomnia. Методы берут из .proto или через server reflection.

Ловушки для тестов:

В proto3 скаляр без optional не передаёт 0, пустую строку и false: «скидка 0» и «скидку не прислали» неотличимы.
Номера полей нельзя менять и переиспользовать, иначе старый клиент прочитает чужое поле. Совместимость проверяют прогоном старого клиента против нового сервера.

GraphQL

Один эндпоинт (обычно POST /graphql), клиент сам описывает, какие поля нужны.

query {
  order(id: 501) {
    id
    status
    items { sku qty }
  }
}

query читает, mutation меняет, subscription подписывает на события (обычно по WebSocket).
Схема строго типизирована, её можно получить интроспекцией (__schema).
Ошибки часто приходят при HTTP 200 в массиве errors, рядом может быть частичный data. Тест обязан проверять errors, а не только код.

Что тестировать:

Авторизацию на уровне полей: закрытый прямой запрос к заказу может открыться через вложенное поле user { orders { ... } }.
Глубокие и широкие запросы: friends { friends { friends ... } } экспоненциально нагружают сервер. Нужны лимиты глубины и сложности.
Батчинг: сотни операций в одном запросе для обхода rate limit.
Интроспекция в проде без авторизации раскрывает внутренние мутации.
N+1: список из ста заказов порождает сто запросов в базу за пользователем.

WebSocket

Постоянное двустороннее соединение. Начинается с HTTP-запроса GET с Upgrade: websocket, сервер отвечает 101 Switching Protocols, дальше по тому же соединению идут кадры в обе стороны.

Проверки: авторизация при рукопожатии и что после выхода соединение закрывается; обрыв и переподключение без потери сообщений; порядок; много одновременных соединений. Инструменты: Postman, DevTools (сообщения во вкладке Network), wscat.

SOAP

Ещё жив в банках, страховании и госсистемах РФ: XML-конверт, описание сервиса в WSDL, обычно POST. Тестируют в SoapUI или Postman.

Сравнение

	REST	gRPC	GraphQL
Контракт	OpenAPI (необязателен)	`.proto` (обязателен)	схема GraphQL
Формат	JSON	Protobuf	JSON
Ошибки	коды HTTP	коды gRPC	`errors` в теле
Где чаще	публичные API	между сервисами	фронтенд и мобильные

Что спросят на собесе

Чем gRPC отличается от REST?
Как вызвать gRPC-метод вручную?
Почему в GraphQL ошибка может прийти с кодом 200?
Какие риски безопасности есть у GraphQL?
Как тестировать WebSocket?

gRPC, GraphQL и WebSocket за 6 минут