gRPC em Swift: quando e por que isso é realmente necessário

gRPC em Swift: quando não é apenas moda, mas necessário

Imagine: você está escrevendo um aplicativo iOS para controlar uma casa inteligente. Comandos são enviados a cada segundo, um atraso de 100 ms já é uma catástrofe. Ou você está fazendo um serviço de streaming, onde vídeo, áudio e telemetria voam simultaneamente. REST aqui vai começar a "travar" e ficar de lado. Conheça — gRPC em Swift.

Mas sejamos honestos: gRPC não é uma bala de prata. Às vezes, um simples JSON em HTTP/1.1 funciona melhor. Neste artigo, vamos analisar quando o gRPC no iOS é justificado, quando é melhor manter o REST e como isso se parece no código real em Swift.

Não vou enrolar. Apenas prática, exemplos e cenários específicos. Vamos lá.

O que é gRPC (muito resumidamente, para quem perdeu)

gRPC é um framework RPC do Google que usa Protocol Buffers (protobuf) para serialização de dados e HTTP/2 para transporte. Ele suporta:

\n
• Chamadas unárias (como REST comum)
\n
• Streaming do servidor
\n
• Streaming do cliente
\n
• Streaming bidirecional
\n

Em Swift, existe a biblioteca oficial grpc-swift (Swift Package Manager), que permite que tanto o cliente quanto o servidor funcionem em Swift. Sim, você pode escrever um servidor em Swift com gRPC — não é brincadeira.

Quando o gRPC em Swift é seu melhor amigo

1. Alta carga e baixa latência

Se seu aplicativo envia centenas de requisições por segundo (por exemplo, trading, jogos, IoT), o gRPC ganha devido a:

\n
• HTTP/2 — multiplexação, compressão de cabeçalhos
\n
• Protocolo binário — protobuf é analisado mais rápido que JSON
\n
• Conexões keep-alive — não precisa abrir um handshake TCP toda vez
\n

Exemplo real: aplicativo para monitoramento de servidores. A cada segundo, chegam 1000 métricas. No REST — 1000 conexões TCP, no gRPC — uma conexão de longa duração. A diferença no consumo de bateria é enorme.

2. Streaming de dados

REST com seu "requisição-resposta" não sabe fazer streaming. Mas o gRPC sabe. Se você precisa:

\n
• Receber atualizações de taxa de câmbio em tempo real
\n
• Transmitir áudio/vídeo
\n
• Receber logs do servidor à medida que aparecem
\n

Então o gRPC é sua escolha. Veja como fica o streaming do servidor em Swift:

// Definição em .proto\nservice StreamService {\n    rpc SubscribeToUpdates(Empty) returns (stream Update) {}\n}\n\n// Cliente em Swift\nlet client = StreamServiceAsyncClient(channel: channel)\nlet updates = client.subscribeToUpdates(Empty())\n\nfor try await update in updates {\n    print("Atualização recebida: \\(update.message)")\n}

Observe: for try await — é Swift Concurrency. O gRPC-Swift funciona muito bem com isso.

3. Microsserviços em Swift (sim, isso existe)

Você pode escrever todo o backend em Swift (Vapor, Hummingbird) e usar gRPC para comunicação interna entre microsserviços. Vantagens:

\n
• Código de modelos compartilhado (protobuf gera estruturas Swift)
\n
• Tipagem forte
\n
• Suporte embutido para timeouts, retentativas, balanceamento de carga
\n

// Servidor em Swift\nfinal class GreeterProvider: GreeterAsyncProvider {\n    func sayHello(request: HelloRequest, context: GRPCAsyncServerCallContext) async throws -> HelloReply {\n        return HelloReply.with { $0.message = "Olá, \\(request.name)!" }\n    }\n}

Este código é um servidor gRPC completo que roda em qualquer servidor Linux/macOS.

4. Quando você tem um sistema de contrato rigoroso

Arquivos Protobuf são a fonte única da verdade. Você descreveu a API em .proto, gerou código para Swift, Go, Python — e todos falam a mesma língua. Sem "ah, mas aqui o campo é opcional, ali não".

Para equipes grandes, isso é uma salvação