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

Введение: Инструмент для внутренней кухни

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

gRPC создавался для внутренних микросервисных коммуникаций внутри Google. Он решает проблемы, которые возникают, когда у вас сотни сервисов, миллионы запросов в секунду и десятки языков программирования. Для этой задачи он подходит идеально. Для маленького блога на WordPress — избыточен.

gRPC не заменяет REST. Он дополняет его. В этой теме мы разберём конкретные сценарии, когда gRPC даёт огромные преимущества, а когда REST всё ещё лучше.

Когда gRPC — отличный выбор

1. Внутренние микросервисы (Backend-to-Backend)

Пример: Netflix, Uber, Google, Lyft используют gRPC для внутренних микросервисов.

    graph TD
    A[API Gateway] -->|gRPC| B[Сервис пользователей]
    A -->|gRPC| C[Сервис заказов]
    B -->|gRPC| D[Сервис уведомлений]
    C -->|gRPC| D
  

2. Потоковая передача данных (Streaming)

Пример: Система мониторинга, где агенты отправляют метрики, а сервер возвращает команды.

service Monitoring {
    rpc StreamMetrics (stream Metric) returns (stream Command);
}

3. Мультиязычные системы (Polyglot)

Пример: У вас сервисы на Go, Python, Java и C++.

# Один .proto файл для всех языков
protoc --go_out=. user.proto      # Go
protoc --python_out=. user.proto  # Python
protoc --java_out=. user.proto    # Java
protoc --cpp_out=. user.proto     # C++

4. Высокая производительность и низкая задержка

Пример: Платёжный шлюз, биржевой движок, рекламный аукцион (миллионы запросов в секунду).

5. Долго работающие соединения

Пример: Сервис нотификаций, который держит соединение с клиентом и отправляет уведомления по мере поступления.

6. Системы с жёсткими требованиями к latency

7. Мобильные приложения (с осторожностью)

Пример: Приложение доставки еды (gRPC между приложением и сервером). Но нужно тестировать на слабых сетях.

Когда gRPC НЕ подходит

1. Публичные API для внешних разработчиков

Лучше: REST + OpenAPI.

2. Браузерные приложения

Лучше: REST или GraphQL.

3. Кеширование критично

Лучше: REST с GET и кеширующими заголовками.

4. Маленькие проекты

Лучше: REST.

5. Простые CRUD API

Лучше: REST.

6. Загрузка больших файлов (как основной сценарий)

Лучше: REST для загрузки файлов. gRPC для метаданных.

Примеры реального выбора

Пример 1: Netflix

• Внутренние сервисы: gRPC (микросервисы, высокая нагрузка)
• Публичное API: REST (внешние разработчики)

Пример 2: Uber

• Внутренние сервисы: gRPC (миллионы поездок, много языков)
• Мобильное приложение: gRPC (экономия трафика, но сложно)

Пример 3: Интернет-магазин (небольшой)

• Всё на REST: публичное API, админка, внешние интеграции.
• gRPC не нужен: нагрузка низкая, стриминг не нужен.

Пример 4: Система мониторинга (Prometheus + Thanos)

• Агенты → Сервер: gRPC (стриминг метрик)
• Публичный API: REST (запросы метрик)

Пример 5: Чат-приложение

• Чат (реальное время): gRPC bidirectional streaming
• Профили, истории: REST (кеширование)

Гибридный подход

Лучшая архитектура часто гибридная.

    graph TD
    A[Мобильное приложение] -->|REST| B[API Gateway]
    C[Веб-приложение] -->|REST| B
    B -->|gRPC| D[Сервис пользователей]
    B -->|gRPC| E[Сервис заказов]
    D -->|gRPC| F[Сервис уведомлений]
    E -->|gRPC| G[Сервис платежей]
    H[Внешний партнёр] -->|REST| I[Партнёрский API]
    I -->|gRPC| D
  

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

Миграция с REST на gRPC

Стратегия 1: Новые сервисы на gRPC

• Старые сервисы остаются на REST
• Новые пишутся на gRPC
• API Gateway конвертирует REST → gRPC

Стратегия 2: Постепенная замена

• Выделите “горячие” эндпоинты (высокая нагрузка)
• Переведите их на gRPC
• Остальное оставьте на REST

Стратегия 3: Гибрид

• REST для внешних (публичное API)
• gRPC для внутренних (микросервисы)

Распространённые ошибки

Ошибка 1: gRPC для публичного API

Сделали публичное API на gRPC. Внешние разработчики не могут его использовать.

Исправление: REST для публичных API.

Ошибка 2: gRPC для кешируемых данных

Используете gRPC для каталога товаров, который обновляется раз в час. Нет кеширования, каждый запрос идёт в БД.

Исправление: REST + CDN.

Ошибка 3: gRPC для маленького проекта

Три микросервиса, 10 запросов в секунду. gRPC добавляет сложность без выгоды.

Исправление: REST.

Ошибка 4: Игнорирование gRPC-Web

Мобильное приложение использует gRPC, но gRPC-Web не настроен. В браузере не работает.

Исправление: REST для браузера, gRPC для нативных приложений.

Ошибка 5: gRPC для больших файлов

Передаёте 100 МБ видео через gRPC. Protobuf не оптимизирован для таких размеров.

Исправление: REST для файлов, gRPC для метаданных.

Резюме для системного аналитика

1. gRPC создавался для внутренних микросервисов. Это его родная среда. Высокая нагрузка, много языков, стриминг — вот где gRPC сияет.

2. gRPC не для публичных API. Внешние разработчики не знают gRPC, инструменты не работают, браузеры не поддерживают.

3. Используйте gRPC для: внутренних микросервисов, потоковой передачи (логи, метрики, чаты), мультиязычных систем, высоких нагрузок, долго живущих соединений.

4. Не используйте gRPC для: публичных API, браузерных приложений (без gRPC-Web), кешируемых данных, маленьких проектов, простых CRUD API.

5. Гибридный подход — лучшее решение. REST для внешних, gRPC для внутренних. API Gateway как мост.

6. gRPC-Web позволяет использовать gRPC из браузера, но с ограничениями (нет клиентского и bidirectional стриминга).