O que é gRPC?

O Google Remote Procedure Call (gRPC) é um framework de código aberto e alto desempenho para implementar APIs via HTTP/2. Ele foi projetado para facilitar o desenvolvimento de aplicações distribuídas, especialmente quando o código pode estar sendo executado em máquinas diferentes.

O Google Remote Procedure Call (gRPC) é um framework de código aberto e alto desempenho para implementar APIs via HTTP/2. Ele foi desenvolvido para facilitar a criação de aplicações distribuídas, especialmente quando o código pode estar sendo executado em máquinas diferentes.

gRPC foi inicialmente desenvolvido pelo Google como uma tecnologia para implementar chamadas de procedimento remoto (RPCs). Atualmente, o gRPC é um projeto incubado pela Cloud Native Computing Foundation, o que significa que é usado em produção e conta com o apoio de uma comunidade ativa de colaboradores.

Por que o gRPC foi criado?

Para entender por que o Google desenvolveu o gRPC, vamos analisar brevemente a evolução do design de APIs .

RPC é uma das formas mais antigas de projetar e criar uma API. As RPCs permitem escrever código como se ele fosse executado em um computador local, embora, na verdade, você possa estar chamando um serviço 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 dificulta sua integração e alteração, além de aumentar a probabilidade de exporem detalhes sobre o sistema.

Quando a arquitetura de API REST foi introduzida, ela resolveu alguns desses desafios ao fornecer 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 (por exemplo, para onde enviar uma solicitação), portanto, não são tão leves e eficientes quanto as RPCs.

Quais são as vantagens do gRPC?

Ao adotar tecnologias mais recentes, o gRPC moderniza o antigo método RPC, tornando-o interoperável e mais eficiente. Atualmente, ele é uma opção atraente para o desenvolvimento de APIs para arquiteturas de microsserviços .

Algumas das vantagens do gRPC incluem:

• Desempenho – o gRPC usa HTTP/2 como protocolo de transporte e, por padrão, Protocol Buffers, o que pode proporcionar um desempenho superior ao da comunicação via REST e JSON.
• Streaming – o gRPC oferece suporte ao streaming de dados para arquiteturas orientadas a eventos, como streaming do lado do servidor, streaming do lado do cliente e streaming bidirecional para enviar solicitações do cliente e respostas do servidor simultaneamente.
• Interoperabilidade – o gRPC oferece suporte a uma ampla variedade de linguagens de programação com geração de código integrada, incluindo C++, Java, Python, PHP, Go, Ruby, C#, Node.js e muito mais.
• Segurança – o gRPC oferece autenticação configurável, rastreamento, balanceamento de carga, além de verificações de integridade para aumentar a segurança e a resiliência.
• Nativo da nuvem – o gRPC funciona bem com implantações baseadas em contêineres e é compatível com tecnologias modernas de nuvem, como Kubernetes e Docker.

De modo geral, o gRPC oferece uma estrutura flexível e de alto desempenho, ideal para a comunicação entre serviços em arquiteturas de microsserviços altamente distribuídas.

Entendendo o gRPC: conceitos básicos

As vantagens e os benefícios do gRPC decorrem, em grande parte, da adoção de duas tecnologias:

• Protocol Buffers para estruturar mensagens
• HTTP/2 como camada de transporte

Protocol Buffers para estruturar mensagens

O gRPC usa Protocol Buffers (ou Protobufs) para definir serviços e mensagens em vez de XML ou JSON. É um mecanismo independente de linguagem para serializar mensagens estruturadas que os serviços enviarão uns aos outros.

De forma semelhante ao conceito da Especificação OpenAPI para APIs REST, o contrato da API no gRPC é implementado em um arquivo de texto .proto, no qual o desenvolvedor define como deseja que os dados sejam estruturados. Em seguida, um compilador protoc compila automaticamente o arquivo de texto .proto para qualquer linguagem compatível. Durante a execução, as mensagens são compactadas e enviadas em formato binário.

Isso oferece duas vantagens principais:

• O gRPC exige menos da CPU porque os dados são representados em formato binário, reduzindo o tamanho das mensagens.
• O esquema é claramente definido para garantir que as mensagens sejam trocadas sem problemas entre o cliente e o servidor, reduzindo os erros.

HTTP/2 como camada de transporte

Tradicionalmente, as APIs REST usavam o HTTP/1.1 como camada de transporte. Embora as APIs REST também possam ser disponibilizadas por HTTP/2, o uso exclusivo do HTTP/2 pelo gRPC oferece algumas vantagens importantes. Uma delas é a possibilidade de transmitir dados em formato binário. Além disso, o HTTP/2 permite processar várias solicitações em paralelo, em vez de lidar com 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 simultaneamente.

De modo geral, isso melhora o desempenho e reduz a utilização da rede, o que pode ser especialmente valioso em uma arquitetura de microsserviços com alta demanda. No entanto, há algumas limitações. Em geral, os navegadores modernos não oferecem suporte a HTTP/2, portanto, talvez seja necessário usar um proxy reverso como o NGINX para disponibilizar a aplicação.

gRPC vs. REST: uma comparação

Atualmente, REST é o estilo de design de APIs predominante, sendo, portanto, um ponto de referência útil para comparação com o gRPC. Tanto REST quanto gRPC são abordagens válidas para a criação de APIs para aplicações web e microsserviços, e nenhuma delas é necessariamente melhor que a outra. Ainda assim, é importante entender suas principais diferenças para escolher a ferramenta mais adequada para cada caso.

Algumas das principais diferenças entre gRPC e REST se enquadram nestas categorias:

• Protocolo
• Formato dos dados
• Transmissão
• Design de APIs
• Desempenho
• Tratamento de erros
• Suporte a idiomas

Protocolo

Embora as APIs REST possam aproveitar os recursos do HTTP/2, os serviços RESTful tradicionalmente usam o HTTP/1.1 baseado em texto como camada de transporte. O gRPC usa exclusivamente o HTTP/2, um protocolo binário mais eficiente que oferece recursos como compactação de cabeçalhos e multiplexação em uma única conexão TCP.

Formato de dados

As APIs REST normalmente usam JSON como formato de dados para enviar e receber informações. O JSON é baseado em texto, fácil de ler e escrever e amplamente compatível. As APIs gRPC usam Protobufs, que têm um formato binário capaz de reduzir o volume de dados e agilizar a comunicação. No entanto, os Protobufs não podem ser lidos facilmente por si só.

Streaming

As APIs REST oferecem suporte a um modelo de solicitação-resposta, com suporte limitado a streaming. Por outro lado, as APIs gRPC são disponibilizadas por HTTP/2 e oferecem suporte a vários padrões de comunicação, incluindo comunicação unária (solicitação-resposta), streaming do servidor, streaming do cliente e streaming bidirecional.

Design de APIs

REST é um modelo centrado em recursos que oferece suporte a métodos HTTP padrão, como GET, POST, PUT e DELETE. Cada solicitação deve conter todas as informações necessárias para ser processada. Além disso, o contrato da API geralmente é escrito usando a Especificação OpenAPI, enquanto a implementação do cliente e do servidor é tratada como uma etapa separada. Em contrapartida, o gRPC é um modelo centrado em serviços, no qual mensagens e serviços são definidos no arquivo .proto. Esse arquivo pode ser usado para gerar código tanto para o cliente quanto para o servidor da API.

Desempenho

O REST pode ser mais lento devido à transmissão de dados em formato de texto pelo HTTP/1.1. Cada solicitação exige um handshake TCP, o que pode introduzir alguma latência. O gRPC oferece suporte a múltiplos fluxos pelo HTTP/2, permitindo que vários clientes enviem diversas solicitações simultaneamente sem estabelecer uma nova conexão TCP. Ele também aproveita recursos do HTTP/2, como a compactação de cabeçalhos.

Tratamento de erros

O REST usa códigos de status HTTP padrão para o tratamento de erros. Em contrapartida, o gRPC oferece muito mais granularidade para definir códigos de status de erro e garantir que sejam consistentes. Por padrão, o modelo do gRPC é bastante limitado, mas geralmente é ampliado com um modelo de erros desenvolvido pelo Google.

Suporte a linguagens

REST é amplamente compatível com praticamente todas as linguagens, mas não oferece recursos integrados de geração de código. A implementação fica inteiramente a cargo do desenvolvedor. Com seu compilador protoc, o gRPC oferece geração de código nativo para várias linguagens de programação.

Você deve usar gRPC em vez de REST?

Em resumo, a escolha entre gRPC e REST depende do que você precisa realizar. O gRPC oferece um método eficiente e de alto desempenho para a comunicação entre serviços em uma aplicação distribuída. No entanto, ele não pode ser interpretado diretamente por navegadores da Web e outros clientes e requer um gateway de API ou um proxy reverso, como o NGINX, para interagir com clientes de front-end. É uma excelente opção para APIs internas que fazem parte de uma arquitetura de microsserviços orientada a eventos.

O REST, por outro lado, é amplamente adotado e compatível com praticamente qualquer linguagem. Ele pode ser lido tanto por humanos quanto por máquinas, pois os dados são trocados usando JSON ou XML. Além disso, sua curva de aprendizado inicial é muito menor e ele é compatível com muitos navegadores, o que o torna ideal para APIs expostas publicamente.

Arquitetura de microsserviços com gRPC

O gRPC é uma das melhores opções para a comunicação em uma arquitetura de microsserviços. Isso se deve, em parte, ao desempenho, mas também à flexibilidade no suporte a diferentes linguagens. Os desenvolvedores podem criar e gerar facilmente clientes e servidores gRPC que sejam executados na linguagem de sua preferência. Como o gRPC descreve o contrato da API em um formato binário, os microsserviços podem se comunicar independentemente das linguagens usadas para desenvolvê-los.

Uma das arquiteturas de microsserviços baseadas em gRPC mais comuns consiste em colocar um gateway de API à frente dos microsserviços e, em seguida, processar todas as comunicações internas por meio de gRPC. O gateway de API processa as solicitações recebidas via HTTP/1.1 e as encaminha aos microsserviços como solicitações gRPC via HTTP/2.

Preocupações de segurança do gRPC

À medida que a adoção do gRPC continua crescendo, as equipes de desenvolvimento e de operações de segurança precisam garantir que soluções de segurança eficazes estejam implementadas. Como as mensagens do gRPC estão em formato binário, podem surgir problemas em dispositivos e ferramentas que esperam comunicações baseadas em ASCII.

As APIs gRPC também são vulneráveis a muitas das ameaças mais comuns à segurança de APIs. Práticas padrão de segurança de APIs, como controle de acesso, criptografia e proteção em tempo de execução, são igualmente importantes em arquiteturas baseadas em gRPC.

Recomendações de segurança para gRPC

Aplicações e APIs gRPC exigem uma abordagem holística de segurança. Algumas das práticas recomendadas para proteger serviços gRPC incluem:

• Validação de esquema – Bloqueie explorações maliciosas verificando se cada campo da mensagem gRPC tem o tipo correto e o conteúdo esperado.
• Mascaramento de dados – Mascare ou impeça que dados confidenciais, como números de cartão de crédito e números de CPF, saiam do sistema.
• Limites de taxa – Aplique limites rigorosos ao tamanho e ao número de solicitações para evitar ataques de DoS por esgotamento de recursos.
• Controle de acesso – Exija autenticação e autorização antes de conceder ao cliente acesso ao serviço.
• Criptografia – Proteja as mensagens em trânsito usando o protocolo Transport Layer Security (TLS).

Por fim, você deve verificar se o seu gateway de API, firewall de aplicações web (WAF) e as demais ferramentas de gerenciamento e segurança de APIs são capazes de proteger suas aplicações e APIs gRPC em produção. Elas devem ser capazes de importar o arquivo .proto de cada serviço e usá-lo para aplicar proteções de segurança à aplicação e às APIs gRPC.

Resumo

O gRPC vem ganhando muita força como uma alternativa popular para desenvolvedores e grandes empresas como a Netflix e a Lyft utilizarem em arquiteturas de microsserviços. Dito isso, o gRPC não substitui as APIs REST, nem é uma forma inerentemente melhor de criar APIs. O gRPC é simplesmente uma alternativa a ser considerada se você desenvolve principalmente APIs para um ambiente interno de microsserviços e precisa de comunicação eficiente e em tempo real.

Olhando para o futuro, o gRPC provavelmente continuará ganhando espaço em aplicações nativas da nuvem devido aos seus benefícios de desempenho e à facilidade de desenvolvimento. Enquanto isso, os desenvolvedores que precisam disponibilizar APIs publicamente continuarão usando REST em suas aplicações. O REST também continuará presente em ambientes nativos da nuvem devido à sua compatibilidade com versões anteriores e à profunda integração com a infraestrutura e as operações de API existentes.