O que é gRPC - Seus componentes RPC e HTTP2 | Parte 1
Tags: grpc, rpc, http2, expertostech
Published: 2022-03-26 18:20:27

**Autor:** Rodrigo G. Tavares
**Veja a Parte 2:** [O que é gRPC - Como usar os Protocol Buffers](https://dev.to/expertostech/o-que-e-grpc-como-usar-os-protocol-buffers-parte-2-mk3)

{% youtube DyOnW95KO5Y %}

Nem tudo são APIs Rest quando falamos de comunicação entre aplicações.

## Introdução

Pensando em reduzir a latência e otimizar a comunicação nas aplicações atuais, o Google criou o sistema gRPC, que é uma implementação do modelo RPC.
No gRPC são usados proto buffers para definição das funcionalidades e a comunicação é feita usando o protocolo HTTP/2.

Nessa série de artigos veremos todos os detalhes do sistema gRPC: Seus principais componentes, funcionamento, pra que serve, onde e como usar.
 
Lembrando que essa aqui é só a primeira parte! 
Nessa série além de vermos os detalhes do sistema gRPC, ao fim faremos uma implementação passo a passo, usando gRPC com Java e Spring Boot.

## Componentes do gRPC

Antes de falarmos de gRPC, precisamos entender dois dos seus principais componentes.

### Modelo RPC

![Funcionamento do RPC](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7stv55m7hd14oe1s5iyg.png)

O RPC, Remote Process Call, como o próprio nome diz, é uma padronização para execução de funcionalidades remotas simulando uma função local, ou seja, isso simplifica muito as integrações entre sistemas.

Também podemos dizer que na maioria dos casos, o RPC está relacionado à interoperabilidade, isso quer dizer que utilizando uma IDL, Interface Definition Language, podemos especificar uma ou mais funcionalidades detalhando seus tipos, parâmetros e retornos. Isso permite a interpretação dessas instruções por qualquer linguagem de programação.

Em resumo, o intuito da interoperabilidade é justamente garantir que programas escritos em linguagens de programação distintas possam se comunicar. 

#### Padrão CORBA

Uma das mais antigas implementações de RPC é o CORBA, Common Object Request Broker Architecture, que simplificando, consiste na implementação de um módulo chamado ORB, responsável pela comunicação entre clientes e o servidores.

#### Java RMI

Em Java a implementação mais famosa do RPC é o RMI, sigla em inglês para Remote Method Invocation.

O RMI é a base do famoso Enterprise Java Beans, também conhecido como EJB. 

Sua implementação requer a criação de stubs, que são um conjunto de interfaces que definem as assinaturas dos métodos, parâmetros e retornos.

Depois de criarmos os stubs, eles são implementados do lado do servidor e distribuídos em uma biblioteca para todos os clientes que invocarão os métodos remotos.
 
Uma informação interessante, é que no caso do RMI não há uma IDL para criação dos stubs, eles são escritos na própria linguagem, então isso quer dizer que o foco não é a interoperabilidade e sim a integração entre sistemas distribuídos feitos em Java mesmo.

#### SOAP

Por último e provavelmente a implementação RPC mais conhecida de todas, amplamente utilizada pelas mais diversas linguagens, vamos falar do modelo SOAP, Simple Object Access Protocol.

_Exemplo de contrato WSDL da Nota Fiscal Eletrônica_
![Exemplo de contrato WSDL da Nota Fiscal Eletrônica](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v5zq2td9tr8gh4xvddi1.png)

Nesse modelo usamos o padrão WSDL, Web Services Description Language, que usando instruções por meio de tags e atributos XML, define o contrato do serviço.
Esse contrato é composto pelos tipos de dados, funcionalidades, parâmetros e retornos.

Para fazer a comunicação com os clientes, é usado protocolo http ou https, e pra acessar os métodos remotos no padrão SOAP, as linguagens fazem a interpretação do contrato WSDL, gerando as interfaces stubs com seus parâmetros para entrada e retorno.

Uma vez gerados, os stubs são distribuídos para os clientes que queiram invocar as funcionalidades SOAP remotas.

Agora que entendemos o que é RPC e vimos alguns exemplos, percebam que todas as implementações citadas acima precisam distribuir algum tipo de biblioteca para os clientes.
Guarda essa informação pois vamos precisar dela adiante.

## Protocolo de comunicação

O gRPC utiliza o protocolo HTTP2 para comunicação, mas para entendermos melhor o motivo pelo qual precisamos dele, veremos os déficits do protocolo HTTP/1.x.

### O que falta no HTTP/1.x

A definição do protocolo HTTP/1.x é muito simples e essa simplicidade tem um preço, que é redução do desempenho das aplicações.

A perda de desempenho acontece devido ao protocolo HTTP/1.x não ter compactação de dados e da impossibilidade de priorizar os recursos.

Normalmente são necessárias várias conexões simultâneas para completar uma requisição que atenda o negócio.

![Crescimento médio das páginas Web em tamanho e número de objetos Jan 1995 – Jul 2014 ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/okc0u9i7tjkys64dw6r3.png)

Lá no começo isso não fazia diferença nenhuma e o protocolo HTTP/1.x atendia muito bem os seus propósitos, só que hoje, a complexidade das aplicações modernas, precisando de cada vez mais recursos, contornar os problemas de latência é um grande desafio para os desenvolvedores.

### O Protocolo HTTP2

O protocolo HTTP2 foi criado pelo Google e aprovado no início de 2015 pelo IESG, Grupo de Gestão de Engenharia para Internet, e ele é uma evolução de um protocolo experimental chamado SPDY, também criado pelo Google.

A primeira grande melhoria do protocolo HTTP2, é o formato dos dados transmitidos. 

![Diferenças entre os protocolos](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4467lgpaaiae3z3ojdui.png)

Enquanto o HTTP/1.x usa o formato de texto simples para comunicação, o protocolo HTTP2 usa um formato binário compactado e isso reduz drasticamente o tamanho da requisição e resposta.

### Comunicação com HTTP2 

A comunicação do protocolo HTTP2 é dividida em três partes: 
- Stream;
- Mensagem;
- Frame.

### O Stream

Em uma mesma conexão TCP/IP podemos trafegar diversos streams e eles são bidirecionais, ou seja, por eles podemos tanto enviar mensagens como receber sem que seja necessário desconectar. Muito diferente do protocolo HTTP/1.x que só aceita uma requisição e uma resposta por conexão.

### A Mensagem

É sequência completa de uma requisição e ela transita dentro do stream.

Como eu já mencionado anteriormente, o protocolo HTTP2 permite a troca de diversas mensagens dentro de um stream e essas mensagens são divididas em frames.

### Os Frames

Por fim temos os frames, eles são a menor parte e compõem a mensagem. Nos frames temos informações dos cabeçalhos e os dados de requisição e resposta.

### Recapitulando 

![Como transitam os dados no HTTP2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/14spza89f5htwdjqsa41.png)

- Uma mesma conexão pode transferir vários streams;
- Dentro de cada stream podemos ter várias mensagens; 
- Essas mensagens são divididas em frames;
- Os frames transitam os dados efetivos da requisição.

Vimos até aqui, quais são os componentes de comunicação do protocolo HTTP2, agora veremos algumas vantagens de desempenho importantes que ele tem.

### Múltiplas requisições

No protocolo HTTP/1.x, se quisermos fazer solicitações paralelas para minimizar a latência, é necessário efetuar várias conexões simultâneas.

![Camada de frame binário do HTTP/2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1e5k9vnqr5544rgzfe1b.png)

Quando usamos os frames binários do protocolo HTTP2, temos o que chamamos de _multiplexação completa de requisição e respostas_, que basicamente é a capacidade do protocolo fazer requisições simultâneas, síncronas e assíncronas usando a mesma conexão.

Além disso também é possível alternar entre as requisições sem bloqueá-las. 
Essa requisição elimina o custo de efetuar novas conexões e tudo isso permite a redução da latência geral, otimizando a utilização da rede.

### Priorização de Stream

Outro avanço importante do protocolo HTTP2 é a possibilidade de alterar a prioridade dos streams.
Esse processo e feito atribuindo um número inteiro entre 1 e 256 a cada stream.

No protocolo HTTP2, você também pode atribuir uma dependência entre os Streams, ou seja, você poderia por exemplo dizer explicitamente que em uma requisição, a imagem B só será baixada depois da imagem A e isso sem a necessidade de efetuar uma nova conexão.

## O que vem a seguir?

Pronto, agora que já entendemos os componentes base do sistema gRPC, podemos seguir para o próximo artigo onde veremos o funcionamento do Protocol Buffer, que é a linguagem usada pelo gRPC como IDL pra definição de funcionalidades, parâmetros e retornos.

**Veja a Parte 2:** [O que é gRPC - Como usar os Protocol Buffers](https://dev.to/expertostech/o-que-e-grpc-como-usar-os-protocol-buffers-parte-2-mk3)

E se você chegou até aqui, deixe o seu gostei no artigo e já aproveita pra seguir o canal ExpertosTech em todas redes sociais:
[https://linktr.ee/expertostech](https://linktr.ee/expertostech)

---
**Referencias:**

- Wikipedia
  - [Chamada de procedimentos remotos](https://pt.wikipedia.org/wiki/Chamada_de_procedimento_remoto)
  - [CORBA](https://pt.wikipedia.org/wiki/CORBA)
- Google Developers
  - [Introdução a HTTP/2](https://developers.google.com/web/fundamentals/performance/http2)
- Receita Federal
  - [Portal da nota fiscal eletrônica](https://www.nfe.fazenda.gov.br/portal/webServices.aspx?tipoConteudo=OUC/YVNWZfo=&AspxAutoDetectCookieSupport=1)