Если ты пишешь бекенд, настраиваешь микросервисы или просто хочешь понять, почему многие компании отказываются от REST и переходят на gRPC, — эта статья для тебя.
Подписывайтесь на мой канал в Телеграмм, чтобы ничего не пропустить.
Ну или на канал в VK, если хотите видеть новые статьи у себя в ленте.
📌 Что такое gRPC
gRPC (читается как "джи-ар-пи-си") — это способ общения между приложениями. Чаще всего используется, чтобы один сервис «вызвал» метод другого — так, как будто он локальный, хотя в реальности он может находиться где угодно (на другом сервере, в другом микросервисе и даже в другой стране).
Главные фишки:
- Работает поверх HTTP/2 (быстро!)
- Использует Protobuf (компактно!)
- Автоматически генерирует клиент и сервер (удобно!)
🆚 gRPC vs REST: в чём разница
REST знаком многим: это когда вы отправляете HTTP-запрос (например, GET или POST) и получаете ответ в формате JSON. Всё красиво, читаемо, но:
- Данные в JSON могут занимать много места (это текст)
- REST работает поверх HTTP/1.1, который не самый быстрый
- Каждый новый запрос — это новое соединение
gRPC использует:
- Протокол HTTP/2 — он поддерживает одновременную передачу нескольких запросов по одному соединению, и это быстрее
- Формат передачи данных Protocol Buffers (Protobuf) — это бинарный, компактный и супербыстрый формат
- Автоматическую генерацию кода на разных языках: Python, Go, Java, C#, и многих других
🛠 Как всё работает
Ты описываешь API в специальном .proto-файле (как "чертёж" или "контракт"), и на базе него автоматически создаются классы и методы для взаимодействия.
🔁 Типы RPC и как с этим работать
gRPC поддерживает разные типы коммуникаций. Разберём на примерах:
1️⃣ Unary RPC — один запрос, один ответ
Прямой аналог обычного HTTP POST. Очень похож на REST-запрос:
📞 Клиент → Сервер → Ответ
Пример:
2️⃣ Server streaming — один запрос, много ответов
Клиент запрашивает, сервер отправляет поток данных по частям.
📞 Клиент → Сервер ⇒ Ответ1 ⇒ Ответ2 ⇒ Ответ3...
Пример:
3️⃣ Client streaming — много запросов, один ответ
Клиент отправляет поток данных на сервер, а потом получает итоговый результат.
📞 Запрос1 ⇒ Запрос2 ⇒ Запрос3 ⇒ Сервер → Ответ
Пример:
4️⃣ Bidirectional streaming — двусторонний поток
И клиент, и сервер могут отправлять данные, когда захотят.
📞 Клиент ↔ Сервер ↔ Клиент ↔ Сервер...
Пример:
🔐 Безопасность
gRPC поддерживает:
- SSL/TLS — для защищённых каналов
- Метаданные (как HTTP-заголовки)
- Перехватчики (interceptors) — для автоматической авторизации
- Status-коды и подробные ошибки
Пример обработки ошибки:
🧪 Как тестировать gRPC
gRPC хорошо тестируется, но требует своих подходов:
🧰 grpcurl — как curl, но для gRPC
Пример:
🎯 Отлично подходит для ручных проверок и отладки без кода.
🧰 Postman (теперь умеет gRPC)
- Добавляешь .proto файл
- Указываешь адрес, выбираешь нужный метод
- Вводишь параметры в JSON-стиле
- Жмёшь «Send»
Очень удобно для ручного тестирования и аналитики.
🧪 Pytest + gRPC
Пример простого юнит-теста:
🧩 Что такое Protobuf?
Protocol Buffers (Protobuf) — это бинарный формат хранения и передачи данных. Он сильно меньше JSON, быстрее сериализуется и десериализуется, и почти не расходует трафик.
Пример:
- JSON:
≈ 50 байт
- Protobuf:
≈ 10 байт
Разница — в 5 раз!
✍ Как это применяется в реальных системах
- 🎬 Netflix использует gRPC внутри всей своей рекомендательной системы
- 🚗 Uber строит маршруты на основе общения десятков сервисов через gRPC
- 🛒 OZON и Avito — используют gRPC-API между микросервисами
- 📱 Мобильные приложения? gRPC работает даже там, где нужны минимальный отклик и низкое потребление трафика
⚙️ Как сгенерировать клиент и сервер из .proto-файла
Один из главных плюсов gRPC — это генерация кода. Ты не пишешь руками методы, сериализацию и клиент — всё делается автоматически из файла описания (.proto).
Разберёмся, как это работает на примере Python.
🛠 Шаг 1. Установи нужные пакеты:
Если ты используешь Python, всё просто:
Эти пакеты содержат:
- поддержку gRPC
- компилятор protobuf (протоф-обработчик)
- генератор кода
🧱 Шаг 2. Создай proto-файл
Например, файл greeter.proto:
🧪 Шаг 3. Сгенерируй код
Запусти команду:
Расшифровка:
- -I. — путь к каталогу с .proto-файлами
- --python_out=. — генерирует обычные protobuf-модели
- --grpc_python_out=. — генерирует gRPC stub (клиент и сервер)
После этого в текущей папке появятся два файла:
- greeter_pb2.py — структуры данных (HelloRequest, HelloReply)
- greeter_pb2_grpc.py — классы для сервера и клиента (GreeterServicer, GreeterStub)
💻 Шаг 4. Создай сервер (пример)*
📞 Шаг 5. Создай клиента*
🏁 Всё! 🎉 У тебя есть:
- Протофайл с контрактом
- Генерированный код
- Сервер и клиент, которые уже обмениваются сообщениями через gRPC
Примечание:
* клиент и сервер обычно пишутся в разных приложениях, потому что они выполняют разные роли. gRPC — это, как правило, коммуникация между двумя (или более) самостоятельными системами.
Но технически ты можешь держать их в одном проекте, особенно на этапе разработки или тестирования.
❗ Основные минусы gRPC
1. ❌ Не работает «из коробки» в браузерах
gRPC работает поверх HTTP/2, а браузеры не позволяют напрямую использовать полноценный HTTP/2 API из JavaScript (например, WebSocket или fetch не поддерживают нужные «низкоуровневые каналы»).
🔧 Решения:
- Использование gRPC-Web — специального прокси-промежуточного слоя (Envoy, grpc-web-proxy и т. д.), который конвертирует gRPC-запросы в HTTP 1.1 или JSON и обратно.
- Альтернатива: REST API + gRPC для внутренних сервисов.
⛔ Без прокси gRPC не будет работать в браузере!
2. 🔧 Дополнительная сложность инфраструктуры
gRPC требует внедрения:
- .proto файлов
- генерации кода
- настройки protoc
- понимания и поддержки Protobuf-формата
Для новичков это может быть резким «порогом входа».
👨🔧 Если ты создаёшь простой CRUD-сервис, REST будет проще в обслуживании.
3. 🧰 Сложности при отладке
С gRPC нельзя просто «отправить curl-запрос» как с REST:
⛔ Нельзя «вставить ссылку в браузер» и получить ответ.
✅ Нужно использовать инструменты вроде grpcurl, Postman (новые версии), BloomRPC или писать клиент вручную.
Также формат ответа — бинарный Protobuf, а не человекочитаемый JSON.
4. 📦 Ограниченный выбор middleware и библиотек
Хотя экосистема развита, всё же:
- Больше готовых решений и middleware существует для REST (логгеры, трейсинг, кеши и т. п.)
- gRPC-интерсепторы и обёртки нужно чаще писать самому
5. 🌍 Не все языки и окружения поддерживаются одинаково хорошо
Хотя gRPC официально поддерживает Go, Java, Python, C++ и другие языки, уровень поддержки и стабильность могут отличаться. Например:
- В некоторых случаях Python gRPC уступает Go или C++ по производительности;
- На мобильных платформах приходится использовать gRPC Lite/gRPC-Web или сторонние решения.
6. 🧪 Сложности с ручным тестированием
Тестирование gRPC требует:
- знания структуры .proto
- наличия сгенерированных stubs
- дополнительных инструментов или самостоятельной генерации клиентов
👨💻 REST можно протестировать в Postman «в лоб», без подготовки. С gRPC приходится заморачиваться.
7. 🗺 Не всегда удобно документировать
В REST мы привыкли к Swagger/OpenAPI ➜ Автоматическое описание API, UI, тестирование.
➡️ У gRPC нет стандартного UI в браузере для удобной документации (gRPC-Gateway + Swagger возможен, но это «костыль»).
🔧 Хотя существуют альтернативы (Buf, grpcdoc, grpcui), всё же документация API — не такая интуитивная, как в REST.
8. 📶 Повышенные требования к сетевой инфраструктуре
- gRPC использует HTTP/2, поэтому нужен сервер, который это поддерживает
- Некоторые прокси-серверы или балансировщики (например, старые версии nginx, ELB) могут не работать с gRPC корректно
- Возможна большая «оптимизация» под производительные сети, но в слабых сетях (например, 2G/3G) можно потерять эффективность
💡 Когда gRPC — не лучший выбор?
- Если пишешь публичное API для клиентов (особенно — фронтенд в браузере)
- Если заказчик/команда не знакомы с Protobuf/gRPC
- Если MVP или тестовый сервис, где проще использовать JSON/HTTP 1.1
- Если важна совместимость с существующими REST-инструментами
🟢 Когда всё-таки стоит выбрать gRPC
Несмотря на минусы, gRPC остаётся идеальным выбором, если:
✅ У вас микросервисная архитектура
✅ Нужна высокая производительность и компактный обмен сообщениями
✅ В проекте используются разные языки (multi-language)
✅ Клиенты — это backend сервисы, а не браузеры
🏁 Заключение
gRPC — это хороший инструмент для построения современных быстрых API, особенно в системах с микросервисной архитектурой. Он обеспечивает высокую производительность, экономит трафик за счёт Protobuf и предлагает расширенные возможности — такие как стриминг и автоматическая генерация кода.
Однако стоит помнить о его ограничениях: более сложная инфраструктура, непрямая совместимость с браузерами и повышенные требования к отладке.
Если ты создаёшь масштабируемый бэкенд, где важна скорость, надёжность и эффективность — gRPC станет отличным выбором. А для простых или клиентских API REST, как и раньше, остаётся удобным и понятным решением.
Если ты ещё не пробовал gRPC — обязательно попробуй.
— Если вам было интересно — ставьте 👍 и делитесь с друзьями!
— Если возникли вопросы — пишите в комментарии!
До встречи в следующей статье 👋