Разработка gRPC API для мобильных приложений под ключ

При разработке мобильных приложений с высокой частотой запросов или real-time обновлениями REST/JSON часто оказывается узким местом. Мы интегрируем gRPC API как альтернативу — с бинарным протоколом, строгой типизацией и встроенным стримингом. Наша команда имеет 5+ лет опыта в мобильной разработке и гарантирует корректную работу gRPC на любых сетевых условиях.

Почему gRPC эффективнее REST/JSON для мобильных?

gRPC выигрывает у REST в трёх сценариях: высокочастотные запросы с предсказуемой схемой (трекинг, телеметрия), real-time streaming (чаты, обновления) и микросервисная архитектура, где mobile gateway уже на gRPC. JSON-over-REST проще в отладке и не требует HTTP/2, но проигрывает в размере передаваемых данных — бинарный Protobuf в 3-4 раза компактнее JSON. Кроме того, gRPC обеспечивает типобезопасность контракта, что исключает ошибки сериализации на стороне клиента. Повышение производительности особенно заметно при большом объёме данных: типичный REST-ответ 8-10 КБ сжимается до 1-2 КБ в gRPC.

Как проектируется .proto контракт?

Контракт — единственный источник правды. Изменение .proto файла приводит к перегенерации клиентов на всех платформах:

syntax = "proto3";

package mobile.api.v1;

service ProductService {
  rpc GetProduct (GetProductRequest) returns (Product);
  rpc ListProducts (ListProductsRequest) returns (stream Product);
  rpc WatchInventory (WatchInventoryRequest) returns (stream InventoryUpdate);
}

message Product {
  string id = 1;
  string name = 2;
  int64 price_cents = 3;
  repeated string image_urls = 4;
}

message GetProductRequest {
  string id = 1;
}

stream Product в ListProducts — server-side streaming: сервер отправляет продукты по одному по мере готовности, не ждёт всех. WatchInventory — серверный стрим для real-time обновлений. Для двунаправленного стриминга используйте rpc BiDirectionalStream(stream Request) returns (stream Response).

Как gRPC решает проблему сериализации на мобильных?

Бинарный формат Protobuf не только компактен, но и строго типизирован. Клиентская кодогенерация создаёт из .proto файла классы с методами get/set, что исключает ошибки в именах полей. На Android это Kotlin-датаклассы с fromProto/toProto, на iOS — структуры Swift с Codable. Кодогенерация встраивается в CI: Gradle задача generateProto и Swift Package Manager плагин swift-protobuf. Это гарантирует, что версии .proto на клиенте и сервере синхронизированы.

Android: gRPC-Kotlin с Coroutines и Interceptor

На Android используем OkHttp-транспорт — он легче Netty (APK прирост ~1.5 МБ против 3 МБ) и быстрее инициализируется.

// build.gradle
implementation 'io.grpc:grpc-android:1.x.x'
implementation 'io.grpc:grpc-okhttp:1.x.x'

val channel = ManagedChannelBuilder
    .forAddress("api.example.com", 443)
    .useTransportSecurity()
    .intercept(AuthInterceptor(tokenProvider))
    .build()

val stub = ProductServiceGrpcKt.ProductServiceCoroutineStub(channel)

// Unary вызов
val product = stub.getProduct(getProductRequest { id = productId })

// Server streaming
stub.listProducts(listProductsRequest { categoryId = "electronics" })
    .collect { product -> /* обрабатываем по мере поступления */ }

AuthInterceptor реализует ClientInterceptor и добавляет Authorization метаданные к каждому вызову. Deadline и keepalive настраиваются через ManagedChannelBuilder:

.keepAliveTime(30, TimeUnit.SECONDS) .keepAliveTimeout(10, TimeUnit.SECONDS) .keepAliveWithoutCalls(false) 

Каждый вызов должен иметь deadline — иначе зависший запрос висит вечно:

stub.withDeadlineAfter(10, TimeUnit.SECONDS).getProduct(request) 

iOS: gRPC-Swift с async/await

На iOS используем пакет grpc-swift с TLS и Swift Concurrency:

let group = PlatformSupport.makeEventLoopGroup(loopCount: 1)
let channel = try GRPCChannelPool.with(
    target: .host("api.example.com", port: 443),
    transportSecurity: .tls(.makeClientDefault(compatibleWith: group)),
    eventLoopGroup: group
)
let client = ProductService_ProductServiceNIOClient(channel: channel)
let request = ProductService_GetProductRequest.with {
    $0.id = productId
}
let response = try await client.getProduct(request).response.get()
// Server streaming через AsyncStream
let call = client.listProducts(listRequest)
for try await product in call.responses {
}

Как отлаживать gRPC трафик на мобильных?

JSON-трафик легко читается в Charles/Proxyman, а Protobuf — бинарный. Для отладки используем grpcurl (command-line), grpc-ui (web UI), Wireshark с gRPC dissector. В dev-сборке подключаем LoggingClientInterceptor из grpc-java для логирования метаданных. Также можно включить reflection API на сервере и выполнять запросы через grpc-cli.

Как обеспечить обратную совместимость .proto схемы?

Обратная совместимость — ключевое преимущество Protobuf. Правила:

• Новые поля добавляем с новым номером, никогда не переиспользуем удалённые номера.
• required не используем (Protobuf 3 убрал его не случайно).
• Для переименования: добавляем новое поле, старое помечаем reserved.

Нарушение этих правил — binary incompatibility: старые версии приложения будут падать при получении новой схемы.

Как настроить retry и deadline для мобильного gRPC?

На стороне клиента конфигурируем RetryPolicy в ServiceConfig. Пример для Kotlin:

val serviceConfig = """ { "methodConfig": [{ "name": [{}], "retryPolicy": { "maxAttempts": 4, "initialBackoff": "1s", "maxBackoff": "10s", "backoffMultiplier": 2, "retryableStatusCodes": ["UNAVAILABLE"] } }] } """.trimIndent()
val channel = ManagedChannelBuilder.forAddress("api.example.com", 443)
    .defaultServiceConfig(JsonParser.parseString(serviceConfig).getAsJsonObject())
    .enableRetry()
    .build()

Deadline обязателен для каждого вызова — мы устанавливаем 10 секунд на unary и 30 секунд на streaming. При слабом соединении используем withExecutor для пула потоков и настраиваем keepalive.

Что входит в работу и сроки

Процесс: аналитика → проектирование .proto схемы → настройка кодогенерации в CI → реализация gRPC клиента на Android/iOS с TLS, auth interceptor, deadline и retry → тестирование на разных сетевых условиях → деплой.

Сроки: 2–4 недели (зависит от сложности). Мы гарантируем стабильную работу на всех мобильных сетях и обеспечиваем полную документацию по схеме. Свяжитесь с нами для оценки вашего проекта — рассчитаем интеграцию gRPC под ваши задачи. Получите консультацию по внедрению gRPC в ваше мобильное приложение, пишите нам.