gRPC-Go или Connect: какой RPC-фреймворк выбрать

gRPC-Go — эталон производительности и стриминга по HTTP/2 с protobuf. Connect от Buf — тот же контракт, но дружелюбнее к браузерам и обычному HTTP: один хендлер обслуживает и gRPC, и JSON.

gRPC-GoкурсConnectкурс

Подбор под ваши приоритеты

Двигайте ползунки — насколько для вас важен каждый критерий (0 — не важен, 5 — критично). Счёт пересчитывается на лету: это взвешенное среднее оценок библиотек по критериям, а не бенчмарк.

Производительность

HTTP/2, мультиплексирование, буферы

Браузер и JSON

Вызовы из веба без прокси

Стриминг

Server/client/bidi-потоки

Экосистема

Меш, метрики, интероперабельность

DX и отладка

curl, ошибки, кодогенерация

Взвешенный счёт

Connectваш матч80
gRPC-Go72

Под ваши веса лидирует Connect: api с веб-клиентами и команды, которым нужен http-отлаживаемый rpc.

Когда сервисы начинают общаться чаще, чем с внешним миром, REST уступает место RPC с контрактом: .proto-файл описывает методы и сообщения, кодогенерация даёт типы, а фреймворк — транспорт. В мире Go два главных имени: канонический gRPC-Go и Connect от команды Buf, который переосмысляет тот же контракт для современного веба.

gRPC-Go — референсная реализация: HTTP/2-мультиплексирование, четыре вида стриминга, перехватчики, балансировка и канальные учётные данные (channel credentials). Это максимум скорости и самая богатая экосистема в родном для gRPC окружении — сервис-меш, метрики и трассировка из коробки. Обратная сторона — клиент должен говорить gRPC: из браузера напрямую не выйдет, нужен gRPC-Web и транс-кодирующий прокси.

Connect (Buf) берёт контракт protobuf, но исполняет его поверх обычных HTTP-семантик: тот же сервис работает как нативный gRPC, как gRPC-Web и как простая POST-библиотека с JSON. Один Connect-хендлер на сервере обслуживает все три протокола, поэтому браузер вызывает API без прокси, curl остаётся рабочим инструментом, а совместимость с существующими gRPC-клиентами сохраняется. Генерация кода через protoc-plugin или buf CLI ощущается современнее: меньше шаблонного кода, лучше ошибки.

Практическое правило: если у вас уже стоит сервис-меш и все вызовы — между Go-сервисами, gRPC-Go даст привычный максимум. Если API заканчивается в браузере или вы хотите curl-отлаживаемые эндпоинты без двойного стека — Connect закрывает вопрос одной библиотекой. Оба подхода разобраны в наших курсах gRPC-Go и Connect по 25 уроков.

Одна и та же задача в каждой библиотеке

Задача-эталон для этого сравнения: посмотрите на разницу в церемониях, типах и обработке ошибок — так выбор ощущается, а не только описывается словами.

Референсная реализация gRPC: HTTP/2, стриминг, interceptors

// protoc: service TaskService { rpc List ... }
package main

import (
  "context"
  pb "example.com/tasks/gen"
)

type server struct {
  pb.UnimplementedTaskServiceServer
}

func (s *server) List(ctx context.Context,
  req *pb.ListRequest,
) (*pb.ListResponse, error) {
  return &pb.ListResponse{
    Items: []*pb.Task{{Title: "Выучить gRPC"}},
  }, nil
}

// grpc.NewServer + pb.RegisterTaskServiceServer
// Транспорт: HTTP/2 + protobuf, стриминг из коробки

Protobuf-контракт поверх дружелюбного HTTP: gRPC, gRPC-Web и JSON в одном хендлере

package main

import (
  "context"
  "net/http"

  "connectrpc.com/connect"
  pb "example.com/tasks/gen"
  pbconnect "example.com/tasks/gen/connectrpc"
)

type handler struct{}

func (*handler) List(ctx context.Context,
  req *connect.Request[pb.ListRequest],
) (*connect.Response[pb.ListResponse], error) {
  res := connect.NewResponse(&pb.ListResponse{
    Items: []*pb.Task{{Title: "Выучить Connect"}},
  })
  return res, nil
}

// Один хендлер: gRPC, gRPC-Web и POST+JSON
// http.StripPrefix + pbconnect.NewTaskServiceHandler

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

gRPC-Go

Референсная реализация gRPC: HTTP/2, стриминг, interceptors

Канонический транспорт: HTTP/2, четыре вида стриминга
Богатая экосистема: interceptors, балансировка, health-checks
Максимальная производительность на родном протоколе
Браузеру нужен gRPC-Web и прокси-транскодер
Отладка вне Go-клиентов неудобна: нужен grpcurl и знание буферов

Берите, если: внутренние кластеры сервисов на go с сервис-мешем и плотным стримингом.

Connect

Protobuf-контракт поверх дружелюбного HTTP: gRPC, gRPC-Web и JSON в одном хендлере

Три протокола одним хендлером: gRPC, gRPC-Web, plain HTTP+JSON
Браузер вызывает API напрямую — без gRPC-Web прокси
Отладка curl'ом и человеческие ошибки вместо status-codes gRPC
Младшая экосистема: меньше готовых interceptors
Бидир-стриминг ограничен (поддерживается через упрощённую модель)

Берите, если: api с веб-клиентами и команды, которым нужен http-отлаживаемый rpc.

Оценки по критериям

Шкала 1-5: экспертная оценка команды проекта по практике, а не синтетика.

Сравнение gRPC-Go, Connect по критериям
Критерий	gRPC-Go	Connect
ПроизводительностьHTTP/2, мультиплексирование, буферы
Браузер и JSONВызовы из веба без прокси
СтримингServer/client/bidi-потоки
ЭкосистемаМеш, метрики, интероперабельность
DX и отладкаcurl, ошибки, кодогенерация

Вердикт: когда что выбирать

Оба фреймворка говорят на protobuf-контракте, поэтому миграция между ними не переписывание: меняется транспорт и генерация. gRPC-Go — выбор «максимально родного» gRPC в кластере, Connect — выбор «API, до которого дотягивается браузер и curl без костылей».

Межсервисное общение в Go-кластере с мешемgRPC-GoРодной HTTP/2, полный стриминг, зрелые interceptors

Публичное или веб-приложение поверх RPCConnectJSON и браузер без прокси, отладка curl'ом

Постепенная миграция старого REST в protobufConnectОдин хендлер обслуживает и старые JSON-клиенты, и gRPC

А что выбрали вы?

Кликните по своему выбору — голос сохранится только в вашем браузере (персональные данные никуда не отправляются).

Частые вопросы

Connect совместим с gRPC-клиентами?

Да. Connect-сервер обрабатывает нативные gRPC-запросы, gRPC-Web и собственный простой протокол поверх HTTP. Существующие gRPC-клиенты продолжают работать без изменений — это часть спецификации Connect.

Нужен ли Buf, чтобы использовать Connect?

Нет, достаточно protoc и официальных плагинов connect-go. Buf CLI упрощает жизнь: линтер protobuf-схемы, управляемая генерация и dependency-менеджмент модулей, но он не обязателен.

Поддерживает ли Connect бидирекционный стриминг?

Полноценный bidi-стриминг в Connect ограничен: библиотека делает акцент на unary и server/client-streaming сценариях. Если кластеру критичен бидирекциональный поток, gRPC-Go остаётся каноническим выбором.

Что быстрее на практике?

На чистых Go-сервисах разница невелика: оба идут по HTTP/2 и protobuf. gRPC-Go чуть выигрывает на горячих unary-вызовах и стриминге; Connect может опережать в сценариях с JSON-клиентами за счёт отсутствия прокси-хопа.