Как подготовить монолит к разделению на сервисы
Инженерный материал о границах доменов, зависимостях и поэтапном разделении монолита.
← все статьи
gRPC vs REST vs GraphQL: выбор под конкретную задачу
Нет универсально правильного ответа. Есть контекст: тип клиента, требования к latency, количество потребителей, зрелость команды. Разберём без холиваров.
REST: умолчание с хорошей причиной
REST – стандарт де-факто, понятный всем, с огромной экосистемой инструментов. OpenAPI/Swagger, моки, тестирование, документация – всё из коробки. Выбирайте REST если:
- Публичный API – разработчики ожидают REST
- Команда незнакома с proto и gRPC
- Клиент – браузер или мобильное приложение
- Нет экстремальных требований к производительности
gRPC: когда важна производительность
Protocol Buffers + HTTP/2 + streaming – gRPC значительно быстрее REST для межсервисного взаимодействия. Типизированные контракты через .proto файлы – и клиент, и сервер генерируют код из одного источника.
// подходит когда
- Микросервисы общаются между собой (не с браузером)
- Важен streaming: server-side, client-side, bidirectional
- Нужна строгая типизация контракта
- Latency критична: gRPC даёт ~7x выигрыш над REST по payload
// не подходит когда
- Клиент – браузер (grpc-web работает, но с ограничениями)
- Команда не знакома с proto – кривая обучения есть
- Нужен простой CRUD без streaming
GraphQL: гибкость с ценой
GraphQL решает over-fetching и under-fetching – клиент запрашивает ровно то, что нужно. Идеален для продуктового API с разными клиентами (web, mobile, partner) с разными потребностями.
GraphQL переносит сложность с сервера на клиент. Это не всегда хорошо.
N+1 проблема, кэширование, авторизация на уровне полей – всё это решаемо, но требует дополнительной работы. DataLoader, persisted queries, field-level auth middleware – стандартный набор для GraphQL в продакшне.
Матрица выбора
Клиент – браузер/мобайл: Один тип клиента → REST Несколько типов клиентов → GraphQL Межсервисное взаимодействие: Streaming / performance → gRPC Простой CRUD → REST или gRPC (по ситуации) Публичный API → REST (ожидание рынка)В реальных проектах часто используем комбинацию: gRPC между сервисами, REST или GraphQL для внешних клиентов. BFF (Backend for Frontend) pattern как точка агрегации.