O Google Remote Procedure Call (gRPC) é uma estrutura de código aberto e de alto desempenho para implementação de APIs via HTTP/2. Ele foi projetado para facilitar aos desenvolvedores a criação de aplicativos distribuídos, especialmente quando o código pode estar sendo executado em máquinas diferentes.
O gRPC foi desenvolvido inicialmente pelo Google como tecnologia para implementar Chamadas de Procedimento Remoto (RPCs). Hoje, o gRPC é um projeto incubado da Cloud Native Computing Foundation , o que significa que ele é usado em produção e é apoiado por um grupo saudável de colaboradores.
Para entender por que o Google desenvolveu o gRPC, vamos analisar brevemente o cronograma do design da API .
A RPC é uma das formas mais antigas de projetar e construir uma API. As RPCs permitem que você escreva código como se ele fosse executado em um computador local, mesmo que, na realidade, você esteja chamando um serviço que está sendo executado em outra máquina (geralmente na sua rede local).
Na prática, isso permite que os desenvolvedores usem ações diretas (como SendUserMessages, addEntry, etc.) sem precisar levar em conta os detalhes da rede. As mensagens RPC são leves e eficientes, mas também são fortemente acopladas ao sistema subjacente. Isso os torna difíceis de integrar, alterar e mais propensos a vazar detalhes sobre o sistema.
Quando a arquitetura da API REST foi introduzida, ela resolveu alguns desses desafios fornecendo uma maneira uniforme de acessar dados e recursos usando métodos HTTP genéricos como GET, POST, PUT e DELETE. Embora o REST simplifique o acesso aos dados, a API geralmente retorna mais metadados do que o necessário. As APIs REST também exigem mais informações sobre a rede (como para onde enviar uma solicitação), por isso não são tão leves e eficientes quanto as RPCs.
Ao adotar tecnologias mais novas, o gRPC atualiza o método RPC mais antigo para torná-lo interoperável e mais eficiente. Hoje, essa é uma escolha atraente ao desenvolver APIs para arquiteturas de microsserviços .
Algumas das vantagens do gRPC incluem:
No geral, o gRPC oferece uma estrutura flexível e de alto desempenho, ideal para comunicações entre serviços em arquiteturas de microsserviços altamente distribuídas.
As vantagens e benefícios do gRPC decorrem em grande parte da adoção de duas tecnologias:
O gRPC usa Protocol Buffers (ou Protobufs ) para definir serviços e mensagens em vez de XML ou JSON. É um mecanismo neutro em termos de linguagem para serializar mensagens estruturadas que os serviços enviarão uns aos outros.
Semelhante ao conceito da Especificação OpenAPI para APIs REST, o contrato de API no gRPC é implementado em um arquivo de texto .proto, onde um desenvolvedor define como deseja que os dados sejam estruturados. Em seguida, um compilador protoc compila automaticamente o arquivo de texto .proto em qualquer linguagem suportada. Em tempo de execução, as mensagens são compactadas e enviadas em formato binário.
Isso proporciona duas vantagens principais:
Tradicionalmente, as APIs REST usavam HTTP/1.1 como camada de transporte. Embora as APIs REST também possam ser entregues por HTTP/2, o uso exclusivo de HTTP/2 pelo gRPC apresenta algumas vantagens importantes. Uma dessas vantagens é a capacidade de enviar comunicação usando binário. Além disso, o HTTP/2 suporta a capacidade de processar várias solicitações paralelas em vez de manipular uma solicitação por vez. A comunicação também é bidirecional, o que significa que uma única conexão pode enviar solicitações e respostas ao mesmo tempo.
No geral, isso melhora o desempenho e reduz a utilização da rede, o que pode ser especialmente valioso em uma arquitetura de microsserviços movimentada. No entanto, há algumas limitações. O HTTP/2 geralmente não é suportado por navegadores modernos, então talvez você precise usar um proxy reverso como o NGINX para entregar o aplicativo.
Hoje, REST é o estilo de design de API mais dominante, então ele fornece um ponto de referência útil para comparar com gRPC. Tanto REST quanto gRPC são abordagens válidas para construir APIs para aplicativos web e microsserviços, e um não é necessariamente melhor que o outro. Dito isso, é útil entender suas principais diferenças para escolher a melhor ferramenta para o trabalho.
Algumas das principais diferenças entre gRPC e REST se enquadram nestas categorias:
Embora as APIs REST possam aproveitar o HTTP/2, os serviços RESTful tradicionalmente usam HTTP/1.1 baseado em texto como camada de transporte. O gRPC usa exclusivamente HTTP/2, um protocolo binário que é mais eficiente e permite recursos como compactação de cabeçalho e multiplexação em uma única conexão TCP.
As APIs REST normalmente usam JSON como formato de dados para enviar e receber dados. JSON é baseado em texto, fácil de ler e escrever e amplamente suportado. As APIs gRPC usam Protobufs, que estão em um formato binário que fornece uma carga útil menor e interação mais rápida. Entretanto, os Protobufs não podem ser lidos facilmente por si só.
As APIs REST oferecem suporte a um modelo de solicitação-resposta com suporte limitado para streaming. Em contraste, as APIs gRPC são entregues via HTTP/2 e oferecem suporte a vários padrões de comunicação, incluindo Unary (solicitação-resposta), streaming de servidor, streaming de cliente e streaming bidirecional.
REST é um modelo centrado em recursos que suporta métodos HTTP padrão como GET, POST, PUT e DELETE. Cada solicitação deve conter todas as informações necessárias para processá-la. Além disso, o contrato da API normalmente é escrito usando a especificação OpenAPI, com a codificação do cliente e do servidor sendo tratada como uma etapa separada. Em contraste, o gRPC é um modelo centrado em serviços, onde mensagens e serviços são definidos no arquivo .proto. O arquivo pode ser usado para gerar código para o cliente e o servidor da API.
O REST pode ser mais lento devido à transmissão de dados baseada em texto via HTTP/1.1. Cada solicitação requer um handshake TCP, o que pode introduzir alguma latência. O gRPC suporta múltiplos fluxos via HTTP/2 para que vários clientes possam enviar múltiplas solicitações ao mesmo tempo sem estabelecer uma nova conexão TCP. Ele também aproveita os recursos do HTTP/2, como a compactação de cabeçalhos.
REST usa códigos de status HTTP padrão para tratamento de erros. Em contraste, o gRPC oferece muito mais granularidade para definir códigos de status de erro e garantir que eles sejam consistentes. Por padrão, o modelo gRPC é bastante limitado, mas é mais comumente estendido usando um modelo de erro mais rico desenvolvido pelo Google .
REST é amplamente suportado por praticamente todas as linguagens, mas não fornece recursos integrados de geração de código. A implementação fica inteiramente a cargo do desenvolvedor. Com seu compilador protoc, o gRPC fornece geração de código nativo para diversas linguagens de programação.
Em resumo, a escolha entre gRPC e REST depende do que você precisa realizar. O gRPC fornece um método eficiente e de alto desempenho para serviços se comunicarem em um aplicativo distribuído. Dito isso, ele não pode ser lido diretamente por navegadores da web e outros clientes e requer um gateway de API ou proxy reverso como o NGINX para interagir com clientes front-end. É uma excelente opção para APIs internas que fazem parte de uma arquitetura de microsserviços orientada a eventos.
REST, por outro lado, é amplamente adotado e suportado em praticamente qualquer linguagem. É legível por humanos e máquinas, pois os dados são trocados usando JSON ou XML. Além disso, ele tem uma curva de aprendizado muito menor para começar e é suportado por muitos navegadores da web, o que o torna ideal para APIs expostas publicamente.
gRPC é uma das melhores opções para comunicação em uma arquitetura de microsserviços. Isso se deve em parte ao desempenho, mas também à flexibilidade no suporte a idiomas. Os desenvolvedores podem facilmente criar e gerar clientes e servidores gRPC que rodam em sua linguagem preferida. Como o gRPC descreve o contrato da API em um formato binário, os microsserviços podem se comunicar independentemente das linguagens usadas para criá-los.
Uma das arquiteturas de microsserviços baseadas em gRPC mais comuns é colocar um gateway de API à frente dos microsserviços e lidar com todas as comunicações internas via gRPC. O gateway de API gerencia as solicitações recebidas em HTTP/1.1 e as encaminha para os microsserviços como solicitações gRPC sobre HTTP/2.
À medida que a adoção do gRPC continua a crescer, os desenvolvedores e as equipes de operações de segurança precisam garantir que soluções de segurança eficazes estejam em vigor. Como as mensagens gRPC estão em formato binário, podem surgir problemas para dispositivos e ferramentas que esperam ver comunicações baseadas em ASCII.
As APIs gRPC também são vulneráveis a muitas das ameaças de segurança de API mais comuns . Práticas de segurança de API padrão, como controle de acesso, criptografia e proteção de tempo de execução, são igualmente importantes em arquiteturas baseadas em gRPC.
Aplicativos e APIs gRPC exigem uma abordagem holística à segurança. Algumas das melhores práticas para proteger gRPCs incluem:
Por fim, você deve verificar se seu gateway de API , firewall de aplicativo web (WAF) e outras ferramentas de gerenciamento e segurança de API estão à altura da tarefa de proteger seus aplicativos gRPC e APIs em produção. Eles devem ser capazes de importar o arquivo .proto para cada serviço e usá-lo para aplicar proteções de segurança para o aplicativo gRPC e APIs.
O gRPC está ganhando muita força como uma alternativa popular para desenvolvedores e grandes empresas como Netflix e Lyft usarem em arquiteturas de microsserviços. Dito isso, o gRPC não é um substituto para APIs REST nem é uma maneira inerentemente melhor de criar APIs. O gRPC é simplesmente uma alternativa a ser considerada se você estiver criando APIs principalmente para um ambiente interno de microsserviços e precisar de comunicação eficiente em tempo real.
Olhando para o futuro, o gRPC provavelmente continuará ganhando força para aplicativos nativos da nuvem devido aos seus benefícios de desempenho e facilidade de desenvolvimento. Enquanto isso, os desenvolvedores que precisam expor APIs publicamente continuarão a usar REST em seus aplicativos. O REST também continuará existindo em ambientes nativos da nuvem devido à sua compatibilidade com versões anteriores e integração profunda com a infraestrutura e as operações de API existentes.
O NGINX oferece uma variedade de recursos gratuitos para atender você em qualquer ponto da sua jornada do gRPC.