Comparar serviços gRPC com APIs HTTP

Por James Newton-King

Este artigo explica como os serviços gRPC se comparam às APIs HTTP com JSON (incluindo ASP.NET APIs da Web principais). A tecnologia usada para fornecer uma API para seu aplicativo é uma escolha importante, e o gRPC oferece benefícios exclusivos em comparação com APIs HTTP. Este artigo discute os pontos fortes e fracos do gRPC e recomenda cenários para o uso do gRPC em relação a outras tecnologias.

Comparação de alto nível

A tabela a seguir oferece uma comparação de alto nível de recursos entre APIs gRPC e HTTP com JSON.

Pontos fortes do gRPC

Performance

As mensagens gRPC são serializadas usando Protobuf, um formato de mensagem binária eficiente. Protobuf serializa muito rapidamente no servidor e cliente. A serialização Protobuf resulta em pequenas cargas de mensagens, é importante em situações de largura de banda limitada, como apps móveis.

O gRPC foi projetado para HTTP/2, uma revisão importante do HTTP que oferece benefícios significativos de desempenho em relação ao HTTP 1.x:

• Enquadramento binário e compressão. O protocolo HTTP/2 é compacto e eficiente tanto no envio como no recebimento.
• Multiplexação de várias chamadas HTTP/2 através de uma única ligação TCP. A multiplexação elimina o bloqueio da cabeça de linha.

HTTP/2 não é exclusivo do gRPC. Muitos tipos de solicitação, incluindo APIs HTTP com JSON, podem usar HTTP/2 e se beneficiar de suas melhorias de desempenho.

Geração de código

Todas as estruturas gRPC fornecem suporte de primeira classe para geração de código. Um arquivo principal para o desenvolvimento gRPC é o .proto arquivo, que define o contrato de serviços e mensagens gRPC. A partir desse arquivo, as estruturas gRPC geram uma classe base de serviço, mensagens e um cliente completo.

Ao compartilhar o .proto arquivo entre o servidor e o cliente, mensagens e código do cliente podem ser gerados de ponta a ponta. A geração de código do cliente elimina a duplicação de mensagens no cliente e no servidor e cria um cliente tipado de forma rigorosa para si. Não ter que escrever um cliente economiza tempo de desenvolvimento significativo em aplicativos com muitos serviços.

Especificação estrita

Não existe uma especificação formal para API HTTP com JSON. Os desenvolvedores debatem o melhor formato de URLs, verbos HTTP e códigos de resposta.

A especificação gRPC é prescritiva sobre o formato que um serviço gRPC deve seguir. O gRPC elimina o debate e economiza tempo do desenvolvedor porque o gRPC é consistente entre plataformas e implementações.

Streaming

HTTP/2 fornece uma base para fluxos de comunicação de longa duração e em tempo real. gRPC fornece suporte de primeira classe para streaming através de HTTP/2.

Um serviço gRPC suporta todas as combinações de streaming:

• Unário (sem streaming)
• Streaming de servidor para cliente
• Streaming de cliente para servidor
• Transmissão bidirecional

Prazos, tempo limite e cancelamento

O gRPC permite que os clientes especifiquem quanto tempo estão dispostos a esperar pela conclusão de um RPC. O prazo é enviado para o servidor, e o servidor pode decidir qual ação tomar se exceder o prazo. Por exemplo, o servidor pode cancelar solicitações gRPC/HTTP/database em andamento no tempo limite.

Propagar o prazo e o cancelamento por meio de chamadas gRPC filho ajuda a impor limites de uso de recursos.

Cenários recomendados do gRPC

O gRPC é adequado para os seguintes cenários:

• Microsserviços: o gRPC foi projetado para comunicação de baixa latência e alta taxa de transferência. O gRPC é ótimo para microsserviços leves onde a eficiência é crítica.
• Comunicação ponto-a-ponto em tempo real: o gRPC tem um excelente suporte para streaming bidirecional. Os serviços gRPC podem enviar mensagens em tempo real sem necessidade de interrogatório.
• Ambientes poliglotas: as ferramentas gRPC suportam todas as linguagens de desenvolvimento populares, tornando o gRPC uma boa escolha para ambientes multilíngües.
• Ambientes restritos de rede: as mensagens gRPC são serializadas com o Protobuf, um formato de mensagem leve. Uma mensagem gRPC é sempre menor do que uma mensagem JSON equivalente.
• Comunicação entre processos (IPC): Transportes IPC, como soquetes de domínio Unix e pipes nomeados, podem ser usados com gRPC para se comunicar entre aplicativos na mesma máquina. Para obter mais informações, consulte Comunicação entre processos com gRPC.

Fraquezas do gRPC

Suporte limitado ao navegador

Hoje em dia, é impossível chamar diretamente um serviço gRPC a partir de um navegador. O gRPC usa fortemente recursos HTTP/2 e nenhum navegador fornece o nível de controle necessário sobre solicitações da Web para suportar um cliente gRPC. Por exemplo, os navegadores não permitem que um chamador exija que HTTP/2 seja usado ou forneça acesso a quadros HTTP/2 subjacentes.

O gRPC no ASP.NET Core oferece duas soluções compatíveis com navegadores:

• O gRPC-Web permite que os aplicativos do navegador chamem serviços gRPC com o cliente gRPC-Web e o Protobuf. gRPC-Web requer o aplicativo do navegador para gerar um cliente gRPC. O gRPC-Web permite que os aplicativos de navegador se beneficiem do alto desempenho e do baixo uso de rede do gRPC.

  O .NET tem suporte interno para gRPC-Web. Para obter mais informações, consulte gRPC-Web em aplicações gRPC em ASP.NET Core.

• A transcodificação JSON gRPC permite que os aplicativos do navegador chamem serviços gRPC como se fossem APIs RESTful com JSON. O aplicativo do navegador não precisa gerar um cliente gRPC ou saber nada sobre gRPC. As APIs RESTful podem ser criadas automaticamente a partir de serviços gRPC anotando o .proto arquivo com metadados HTTP. A transcodificação permite que um aplicativo ofereça suporte a APIs da Web gRPC e JSON sem duplicar o esforço de criar serviços separados para ambos.

  O .NET oferece suporte nativo para criar APIs web JSON a partir de serviços gRPC. Para obter mais informações, consulte Transcodificação JSON gRPC em aplicativos gRPC ASP.NET Core.

Não legível por humanos

As solicitações de API HTTP são enviadas como texto e podem ser lidas e criadas por humanos.

As mensagens gRPC são codificadas com Protobuf por padrão. Embora o Protobuf seja eficiente para enviar e receber, seu formato binário não é legível por humanos. Protobuf requer a descrição da interface da mensagem especificada no arquivo .proto para desserializar adequadamente. Ferramentas adicionais são necessárias para analisar as cargas úteis do Protobuf no fio e para compor solicitações manualmente.

Recursos como reflexão do servidor e a ferramenta de linha de comando gRPC existem para ajudar com mensagens binárias Protobuf. Além disso, as mensagens Protobuf suportam a conversão de e para JSON. A conversão JSON integrada fornece uma maneira eficiente de converter mensagens Protobuf de e para o formato legível por humanos durante a depuração.

Cenários de quadro alternativos

Outras estruturas são recomendadas sobre gRPC nos seguintes cenários:

• APIs acessíveis pelo navegador: o gRPC não é totalmente suportado no navegador. gRPC-Web pode oferecer suporte a navegadores, mas tem limitações e introduz um proxy de servidor.
• Transmissão de comunicação em tempo real: o gRPC suporta comunicação em tempo real via streaming, mas o conceito de transmitir uma mensagem para conexões registradas não existe. Por exemplo, em um cenário de sala de chat em que novas mensagens de chat devem ser enviadas a todos os clientes na sala de chat, cada chamada gRPC é necessária para transmitir individualmente novas mensagens de chat para o cliente. SignalR é uma estrutura útil para este cenário. SignalR tem o conceito de conexões persistentes e suporte embutido para transmissão de mensagens.

Recursos adicionais

• Criar um cliente e um servidor gRPC .NET no ASP.NET Core
• Visão geral do gRPC no .NET
• serviços gRPC com C#
• Migrar gRPC de C-core para gRPC para .NET