Какие плюсы и минусы gRPC?

gRPC: Плюсы и минусы

gRPC — это современный RPC фреймворк от Google, основанный на Protocol Buffers и HTTP/2. Это критически важный инструмент в микросервисной архитектуре.

Плюсы gRPC

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

• Binary protocol вместо текста (JSON, XML) — компактнее в ~3-5 раз
• HTTP/2 с multiplexing — одно соединение, много параллельных потоков
• Streaming нативно поддерживает bi-directional communication

// Пример клиент-сервер потока в одном соединении
service Chat {
    rpc SendMessages(stream Message) returns (stream Response);
}

2. Типобезопасность и контракт

• Protocol Buffers — строгая схема данных
• Автоматическая генерация кода на основе .proto
• Нет неожиданных полей, как в JSON

// Строгая схема
message User {
    int32 id = 1;
    string name = 2;
    string email = 3;
}

3. Streaming

• Client streaming: rpc Upload(stream Data) returns (Response)
• Server streaming: rpc Download(Request) returns (stream Data)
• Bi-directional: rpc Chat(stream Message) returns (stream Message)
• Идеально для real-time приложений

4. Простота реализации

• Минимум кода — большинство генерируется
• Встроенная балансировка нагрузки
• Встроенная поддержка различных типов аутентификации

// Минимальный gRPC сервер
type Server struct {
    pb.UnimplementedUserServiceServer
}

func (s *Server) GetUser(ctx context.Context, req *pb.UserId) (*pb.User, error) {
    return &pb.User{Id: req.Id, Name: "John"}, nil
}

// Запуск
listener, _ := net.Listen("tcp", ":50051")
grpcServer := grpc.NewServer()
pb.RegisterUserServiceServer(grpcServer, &Server{})
grpcServer.Serve(listener)

5. Микросервисы

• Идеально для service-to-service communication
• Меньше сетевых задержек
• Лучше всего для внутренних API

Минусы gRPC

1. Сложность отладки

• Binary protocol — нельзя просто прочитать в curl/Postman
• Нужны специальные инструменты (grpcurl, Postman с поддержкой gRPC)
• Тестировать сложнее, чем REST

# Пример: curl не работает с gRPC
curl -X POST http://localhost:50051/user.UserService/GetUser
# Ошибка: gRPC требует специальных инструментов

# Правильно: grpcurl
grpcurl -plaintext -d "{\"id\": 1}" localhost:50051 user.UserService/GetUser

2. Поддержка браузерами

• Нативно gRPC не работает в браузере (требует HTTP/2)
• Нужна gRPC-Web для frontend
• Дополнительный слой complexity для web-приложений

3. Кривая обучения

• Protocol Buffers требует обучения
• .proto синтаксис нужно учить
• Понимание HTTP/2 и multiplexing

4. Размер бинарника

• Protocol Buffers генерируют больше кода, чем простой JSON
• Зависимости занимают место
• Для микрослужб это может быть проблемой

5. Использование памяти

• HTTP/2 multiplexing требует больше памяти (connection pooling)
• Может быть проблемой при работе с десятками тысяч соединений

// Проблема: слишком много соединений
for i := 0; i < 10000; i++ {
    conn, _ := grpc.Dial("localhost:50051")
    // Каждое соединение занимает память
}

6. Экосистема

• Меньше инструментов и библиотек, чем для REST
• Документация может быть хуже
• Интеграция с legacy-системами сложнее

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

gRPC vs REST

// REST: 1 HTTP запрос = 1 соединение
GET /users/1

// gRPC: Multiplexing на одном HTTP/2 соединении
rpc GetUser(UserId) returns (User);
// Множество параллельных запросов на одном соединении