Criar aplicativos cliente-servidor com gRPC

O gRPC é um framework de RPC moderno, de código aberto e de alto desempenho que pode ser executado em qualquer ambiente. Ele pode conectar serviços de maneira eficiente em data centers com suporte conectável para balanceamento de carga, rastreamento, verificação de integridade e autenticação. Ele também pode ser usado na última milha da computação distribuída para conectar dispositivos, aplicativos móveis e navegadores a serviços de back-end. É possível encontrar a documentação no site oficial do gRPC e receber suporte de comunidades de código aberto. Este guia mostra soluções para a criação de apps Android usando o gRPC.

gRPC.io é o site oficial do projeto gRPC. Para saber mais sobre como o gRPC funciona, consulte O que é gRPC? e Conceitos do gRPC (ambos em inglês). Para saber como usar o gRPC em um app Android, consulte o exemplo Hello World no Guia de início rápido do gRPC para Android em Java (em inglês). Também é possível encontrar vários outros exemplos do gRPC para Android no GitHub (em inglês).

Recursos

A chamada de procedimento simplifica o processo
Por ser RPC, o modelo de programação é chamado de procedimento: o aspecto de rede da tecnologia é abstraído do código do aplicativo, fazendo com que pareça quase como se fosse uma chamada de função normal no processo. Sua interação cliente-servidor não será restrita pela semântica dos métodos de recurso HTTP (como GET, PUT, POST e DELETE). Em comparação com as APIs REST, sua implementação parece mais natural, sem a necessidade de processar metadados do protocolo HTTP.
Transmissão eficiente de rede com HTTP/2
A transmissão de dados de dispositivos móveis para um servidor de back-end pode ser um processo que consome muitos recursos. Ao usar o protocolo HTTP/1.1 padrão, conexões frequentes de um dispositivo móvel com um serviço em nuvem podem descarregar a bateria, aumentar a latência e bloquear a conexão de outros apps. Por padrão, o gRPC é executado com base no HTTP/2, o que introduz streaming bidirecional, controle de fluxo, compactação de cabeçalho e a capacidade de multiplexar solicitações em uma única conexão TCP/IP. O resultado é que o gRPC pode reduzir o uso de recursos, resultando em tempos de resposta menores entre o app e os serviços em execução na nuvem, redução no uso de rede e maior duração da bateria para clientes que usam dispositivos móveis.
Compatibilidade integrada com troca de dados de streaming
O gRPC foi projetado pensando na compatibilidade do HTTP/2 com streaming bidirecional full-duplex desde o início. Com o streaming, a solicitação e a resposta podem ter um tamanho arbitrariamente grande, como operações que exigem upload ou download de uma grande quantidade de informações. Com o streaming, o cliente e o servidor podem ler e gravar mensagens simultaneamente e se inscreverem uns nos outros sem rastrear os IDs de recursos. Isso torna a implementação do seu app mais flexível.
Integração perfeita com o buffer de protocolo
O gRPC usa buffers de protocolo (Protobuf) como método de serialização/desserialização com o plug-in codegen otimizado para Android (Protobuf Java Lite). Em comparação com o formato baseado em texto (como JSON), o Protobuf oferece uma troca de dados mais eficiente em termos de velocidade de marshaling e tamanho de código, o que o torna mais adequado para uso em ambientes móveis. Além disso, a sintaxe concisa de definição de mensagem/serviço do Protobuf facilita muito a definição do modelo de dados e dos protocolos de aplicativo para seu app.

Visão geral do uso

Seguindo o tutorial Noções básicas do gRPC - Java para Android (link em inglês), o uso do gRPC para apps Android envolve quatro etapas:

  • Definir serviços RPC com buffers de protocolo e gerar as interfaces de cliente do gRPC.
  • Criar um canal que sirva como meio para chamadas RPC entre cliente e servidor.
  • Criar um stub de cliente como ponto de entrada para iniciar chamadas RPC do lado do cliente.
  • Faça chamadas RPC para o servidor remoto, como você faria ao realizar chamadas de procedimento local.

Para fins de demonstração, os bytes são transmitidos em texto simples no exemplo fornecido. No entanto, o app precisa sempre criptografar dados de rede na produção. O gRPC é compatível com criptografia SSL/TLS e permite a troca de tokens OAuth (OAuth2 com os serviços do Google) para autenticação. Para saber mais, consulte TLS no Android e Como usar o OAuth2.

Transporte

O gRPC oferece duas opções de implementações de transporte para clientes Android: OkHttp e Cronet.

Escolher um transporte (avançado)

  • OkHttp
    O OkHttp é uma pilha de rede leve projetada para uso em dispositivos móveis. É o transporte padrão do gRPC para execução no ambiente Android. Para usar o OkHttp como transporte gRPC para seu app, construa o canal com AndroidChannelBuilder, que une OkHttpChannelBuilder e registrará um monitor de rede com o SO Android para responder rapidamente a mudanças na rede. Um exemplo de uso pode ser encontrado em gRPC-Java AndroidChannelBuilder.
  • Cronet (experimental)
    Cronet é a pilha de redes do Chromium empacotada como biblioteca para dispositivos móveis. Ele oferece suporte de rede robusto com protocolo QUIC de última geração, que pode ser especialmente eficaz em ambientes de rede não confiáveis. Para saber mais detalhes sobre a Cronet, consulte Executar operações de rede usando a Cronet. Para usar a Cronet como o transporte do gRPC para seu app, crie o canal com CronetChannelBuilder. Um exemplo de uso é mostrado em Transporte da Cronet gRPC-Java (em inglês).

De um modo geral, recomendamos que os apps direcionados a versões recentes do SDK usem a Cronet, porque ela oferece uma pilha de rede mais eficiente. A desvantagem de usar a Cronet é o aumento do tamanho do APK, já que a adição da dependência binária da Cronet vai adicionar mais de 1 MB ao tamanho do app em comparação a aproximadamente 100 KB para o OkHttp. A partir do GMSCore v.10, uma cópia atualizada da Cronet pode ser carregada no Google Play Services. O tamanho do APK pode não ser mais um problema, embora dispositivos sem o GMSCore mais recente instalado ainda prefiram usar o OkHttp.