Criar aplicativos cliente-servidor com gRPC

O gRPC é um framework de RPC moderno, de código aberto e alto desempenho que pode ser executado em qualquer ambiente. Ele pode conectar serviços de forma eficiente em data centers e com compatibilidade conectável para balanceamento de carga, rastreamento, verificação de integridade e autenticação. Ele também pode ser usado na última etapa 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 ajuda de comunidades de código aberto. Este guia mostra soluções para a criação de apps Android usando o gRPC.

grpc.io (em inglês) é 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 para Android, consulte o exemplo Hello World no Guia de início rápido do gRPC em Java para Android (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 é a chamada de procedimento: o aspecto de rede da tecnologia é abstraído do código do aplicativo, fazendo-o parecer quase uma chamada normal de função em andamento. Sua interação cliente-servidor não será restringida pela semântica dos métodos de recurso HTTP (como GET, PUT, POST e DELETE). Comparada às APIs REST, sua implementação parece mais natural, sem a necessidade de processar metadados de 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. Usando o protocolo HTTP/1.1 padrão, conexões frequentes de um dispositivo móvel para um serviço de nuvem podem esgotar a bateria, aumentar a latência e bloquear a conexão de outros apps. Por padrão, o gRPC é executado sobre o HTTP/2, o que introduz streaming bidirecional, controle de fluxo, compactação de cabeçalho e 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 mais curtos entre seu app e serviços executados na nuvem, redução do uso de rede e maior duração da bateria para clientes em dispositivos móveis.
Compatibilidade integrada com troca de dados de streaming
Desde o início, o gRPC foi projetado considerando a compatibilidade do HTTP/2’s com streaming bidirecional duplex completo. O streaming permite que uma solicitação e uma resposta tenham um tamanho arbitrariamente grande, como operações que exigem o 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 registrar 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, ou Protobuf Java Lite (em inglês). 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 ambientes móveis. Além disso, a sintaxe concisa de definição de serviço/mensagem 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 (em inglês), o uso de gRPC em apps para Android envolve quatro etapas:

  • Definir os serviços RPC com buffers de protocolo e gerar as interfaces do cliente gRPC.
  • Criar um canal que sirva como o meio para chamadas RPC entre cliente e servidor.
  • Criar um stub de cliente como ponto de entrada para iniciar chamadas RPC no cliente.
  • Fazer chamadas RPC para o servidor remoto, como ao realizar chamadas locais de procedimento.

Para fins de demonstração, os bytes são transmitidos em texto simples no exemplo dado. No entanto, seu app deve sempre criptografar dados de rede na produção. O gRPC oferece compatibilidade com criptografia SSL/TLS, bem como troca de token OAuth (OAuth2 com os serviços do Google) para autenticação. Para ver mais detalhes, consulte TLS no Android e Como usar o OAuth2 (links em inglês).

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. Ele é o transporte padrão do gRPC para execução no ambiente Android. Para usar o OkHttp como transporte do gRPC para seu app, crie o canal com AndroidChannelBuilder, que une OkHttpChannelBuilder e registrará um monitor de rede com o SO Android para responder rapidamente às mudanças da rede. Um exemplo de uso pode ser encontrado em gRPC-Java AndroidChannelBuilder (links em inglês).
  • Cronet (experimental)
    Cronet é a pilha de redes do Chromium empacotada como biblioteca para dispositivos móveis. Ela oferece uma forte compatibilidade de rede com o protocolo QUIC de última geração, que pode ser eficaz especialmente em ambientes de rede não confiáveis. Para saber mais detalhes sobre a Cronet, consulte Realizar operações de rede usando a Cronet. Para usar a Cronet como o transporte do gRPC para seu app. crie o canal com CronetChannelBuilder (em inglês). Um exemplo de uso é apresentado em Transporte da Cronet gRPC-Java (em inglês).

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