Web over gRPC:
какую технологию
выбрать

Эдгар Сипки // Sipki Tech

Я не

Просто человек, который много и больно щупал gRPC в проде.

О чём поговорим

1. 01Преимущества gRPC
2. 02Проблемы в WEB
3. 03Все попытки завоевать WEB
4. 04K6 и прямой батл между фреймворками
5. 05Выводы

DOC FIRST
FOREVER

Контракт — единственный источник правды. Сначала .proto, потом всё остальное.

Stream данных из коробки

service Storage {
  rpc Get   (GetRequest)   returns (stream Chunk);
  rpc Store (stream Chunk) returns (StoreResponse);
  rpc Sync  (stream Event) returns (stream Event);
}

• Server-stream, client-stream, bidi — одной строкой в контракте
• HTTP/2 multiplexing бесплатно

Компактность данных

{
  "id":  42,
  "user":"edgar",
  "ok":  true
}

08 2A
12 05 65 64 67 61 72
18 01

~34% меньше на ровном месте, без gzip.

Валидация в контракте

message CreateUserRequest {
  string email = 1 [(buf.validate.field).string.email = true];
  string name  = 2 [(buf.validate.field).string.min_len = 2];
  int32  age   = 3 [(buf.validate.field).int32 = { gte: 18, lte: 120 }];
}

Один контракт → один набор правил → ноль расхождений между сервисами.

Почему «почти»

version: v2
deps:
  - buf.build/grpc-ecosystem/grpc-gateway
  - buf.build/bufbuild/protovalidate
plugins:
  - name: go
  - name: go-grpc
  - name: validate-go

Экосистема собирается руками. EasyP закрывает этот зазор.

О чём поговорим

• Преимущества gRPC
• Проблемы в WEB
• Все попытки завоевать WEB
• K6 и прямой батл между фреймворками
• Выводы

Покорил, но не WEB

А что в WEB

• REST развивался десятки лет
• HTTP/2 в браузере есть, но fetch «руками» писать нельзя
• Trailers, framing, flow-control — недоступны клиентскому коду
• Монополия OpenAPI

OpenAPI
доминирует

Для каждого языка, каждого редактора и каждой CI — есть готовый плагин.

Экосистема OpenAPI

О чём поговорим

• Преимущества gRPC
• Проблемы в WEB
• Все попытки завоевать WEB
• K6 и прямой батл между фреймворками
• Выводы

Сдались без боя?

Обманка REST

Снаружи — обычный JSON-over-HTTP/1.1.
Внутри — всё тот же gRPC-сервер.

Магия аннотаций

service Users {
  rpc GetUser(GetUserRequest) returns (User) {
    option (google.api.http) = {
      get: "/v1/users/{id}"
    };
  }
}

Один proto — три файла

Один код — два интерфейса

• Бизнес-логика пишется один раз
• Доступна и по gRPC, и по HTTP/JSON
• Frontend счастлив, backend не дублирует код

Interceptors живут

Auth, logging, tracing — всё работает как в обычном gRPC.

Серверы можно разделять

Стримы через WebSockets

mux := runtime.NewServeMux()
proxy := wsproxy.WebsocketProxy(mux)
http.ListenAndServe(":8080", proxy)

Server-streaming → WebSocket. Костыль, но работает.

Файлы — больно

func handleBinaryFileUpload(w http.ResponseWriter, r *http.Request) {
  // 1. парсим multipart руками
  // 2. собираем proto-сообщение
  // 3. бьём на чанки
  // 4. дёргаем gRPC client напрямую
  // ...прощай, кодоген
}

Multipart живёт мимо кодогенерации.

Итог: gRPC‑Gateway

Прокси посередине

Без прокси не запустится: HTTP/2 framing в браузере недоступен.

Client-streaming — нет

• Unary — ok
• Server-streaming — ok
• Client-streaming — не поддержан
• Bidi-streaming — не поддержан

Full-duplex обещают через WebTransport

QUIC + HTTP/3 в браузере → полноценные стримы.
Но это в будущем, и не для всех браузеров.

В итоге придётся переезжать

Итог: gRPC‑Web

• Reverse proxy обязателен
• Файлы — не из коробки
• Полноценных streams нет
• Frontend не любит лишний прокси

Два транспорта — одна схема

Content-Type: application/protobuf

<binary>

Content-Type: application/json

{ "id": "42" }

Один сервис — HTTP/1.1 + gRPC

Без прокси, без gateway. Один бинарь.

Контроль HTTP-методов

func (s *Server) GetUser(ctx context.Context, r *GetUserRequest) (*User, error) {
  twirp.SetHTTPResponseHeader(ctx, "Cache-Control", "max-age=60")
  return s.repo.Find(ctx, r.Id)
}

Streams отрезали сразу

// linter rules
RPC_NO_CLIENT_STREAMING
RPC_NO_SERVER_STREAMING

@spenczar — «we don't support streaming, by design.»

Свой Interceptor

type Interceptor func(next Method) Method
type Method func(ctx context.Context, req any) (any, error)

Совместимости с gRPC-интерсепторами нет.

Нет swagger.

Документация генерируется только через сторонние плагины. Frontend остаётся без типов из коробки.

Но плюсы же будут?

Итог: Twirp

• Это не gRPC
• Файлы — не из коробки
• Streams — запрещены
• Frontend остался без OpenAPI
• Нет интерсепторов от gRPC
• Twitch проиграл битву за внимание

Большие надежды

grpcurl -plaintext \
  -d '{"id":42}' \
  localhost:8080 users.Users/Get

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{"id":42}' \
  http://localhost:8080/users.Users/Get

«Будет как gRPC, но без прокси» — знакомо звучит.

Один Go-сервер — три протокола

• Connect (свой JSON/proto over HTTP)
• gRPC
• gRPC-Web

В одном бинаре, на одном порту.

Контроль HTTP

func (s *Server) GetAvatar(ctx context.Context, req *connect.Request[GetAvatarRequest]) (*connect.Response[Avatar], error) {
  res := connect.NewResponse(&Avatar{...})
  res.Header().Set("Cache-Control", "max-age=604800")
  return res, nil
}

Снова свой интерсептор

type UnaryFunc func(ctx context.Context, req AnyRequest) (AnyResponse, error)
type Interceptor interface {
  WrapUnary(UnaryFunc) UnaryFunc
}

Наработки gRPC интерсепторов — на свалку.

Эволюция или деградация

Итог: ConnectRPC

• Самый универсальный по протоколам
• Bidi-stream в браузере всё равно нет
• Свой собственный API для интерсепторов
• Жёсткая привязка к Buf

Все четыре в одной таблице

Один человек — одна экосистема

Битва не проиграна

• gRPC‑Gateway — лидер, если нужен REST-фасад
• gRPC‑Web — ставка на будущее (WebTransport)
• Twirp — жив, но без массы
• ConnectRPC — для тех, кто уже на Buf

K6 как инструмент

Стенд

Больше лучше — отдача

На малом payload Twirp чуть впереди, на крупном — Twirp / ConnectRPC.

Больше лучше — отдача (потюнили)

После тюнинга — разница в пределах погрешности.

О чём поговорили

• Преимущества gRPC
• Проблемы в WEB
• Все попытки завоевать WEB
• K6 и прямой батл между фреймворками
• Выводы

Что выбрать

Производительность — не критерий. Все четверо в одной весовой категории.

Спасибо.
Вопросы?