8. Resultados e Discussões

Serviços RESTful, usualmente operam sobre protocolos de transporte baseado em texto, como o HTTP/1.x, e trazem a reboque formatos textuais legíveis a humanos, como o JSON ou XML. Entretanto, a comunicação é um tanto quanto ineficiente, pois converte-se uma estrutura computacional naturalmente binária em texto, para então transmitir texto pela rede, e depois retornar a uma estrutura binária, todavia, máquinas não precisam usar formatos textuais. Já o gRPC usa o protocolo binário protobuf para comunicar serviços gRPC a clientes. Cabeçalhos e payloads em textos são maiores do que em binários e aumentam a carga sobre a rede. O gRPC implementa o protocol buffer sobre o HTTP/2.0, que faz uma comunicação entre processos muito mais rápida e eficiente.

gRPC encoraja uma abordagem de primeiro estabelecermos o contrato. Primeiramente, definimos a interface do serviço e só então trabalhamos nos detalhes da implementação. Diferentemente do OpenAPI/Swagger para a definição de serviços RESTful e do WSDL para os web services SOAP, gRPC oferece a IDL, uma linguagem de definição de interface simples, consistente, confiável e escalável para o desenvolvimento de aplicações.

RESTful carece de interfaces fortemente tipadas bem definidas. Quando desenvolvemos serviços RESTful não há uma exigência estrita de definição de serviço e de tipos de informação que seja compartilhada entre aplicações. A aplicação RESTful espera por um formato de texto vindo pela rede, o que em tecnologias poliglotas desiguais, pode acarretar erros em tempo de execução e problemas na interoperabilidade. Alguns tipos inteiros em C++ são dependentes de arquitetura de máquina, por exemplo, e peculiaridades dessa ordem podem ocasionar incompatibilidades. Em contraste, gRPC é fortemente tipada. No contrato do serviço definimos claramente os tipos que serão usados na comunicação. Isso ajuda a tornar mais estáveis as aplicações concebidas para operar na nuvem, uma vez que a tipagem estática evita a maioria de erros em tempo de execução e de interoperabilidade. Além disso, gRPC é naturalmente poliglota, porque foi projeta para trabalhar com múltiplas linguagens de programação.

O estilo arquitetural REST possui um conjunto de “boas práticas”, as constraints, que devemos seguir para fazer do serviço verdadeiramente RESTful. No entanto, as constraints não estão impostas enquanto parte da implementação de protocolos, como o HTTP. Na prática, a maioria dos serviços chamados RESTful não seguem a rigor os princípios REST, são apenas serviços HTTP expostos na web. Demandaria muito tempo de uma equipe de desenvolvimento manter a consistência e fidelidade aos preceitos de um serviço RESTful.

gRPC oferece suporte nativo a streaming, tanto do lado cliente quanto do lado servidor, ou a ambos simultaneamente, mantendo o canal aberto e performando uma comunicação bidirecional. Em oposição, o REST praticado sobre o HTTP/1.x suporta apenas comunicação unidirecional, precisando abrir e fechar conexão a cada requisição.

O gRPC faz parte da Cloud Native Computing Foundation – CNCF e está integrado às tecnologias desse ecossistema. Podemos dizer que gRPC está maduro, pois tem passado por pesados testes na Google e sua adoção por outras empresas de alta tecnologia como Netflix, Docker, Kubernetes, Cisco entre outras, ratifica sua maturidade. No entanto, pode não ser a melhor escolha em alguns cenários.

O ecossistema gRPC ainda é relativamente pequeno, se comparado ao dueto protocolo HTTP/1.1 e REST. Outro ponto relevante é que o suporte a gRPC em navegadores ainda está nos estágios iniciais. Em relação a aplicações mobile, o gRPC está bem integrado no Firebase e no Flutter, mas não em todas as tecnologias de desenvolvimento mobile, sendo ainda preferível o REST em cenários mais voltados ao front-end.

gRPC é fortemente utilizado no back-end, para comunicação inter-processos das aplicações internas das empresas. Caso a intenção seja expor aplicações ou serviço para serem consumidos por clientes externos através da internet, acreditamos que o REST/HTTP seja o mais indicado, além do fato do REST ser mais familiar à comunidade de desenvolvedores e o gRPC ainda pouco conhecido. E nos casos em que houver uma modificação drástica da definição do serviço, normalmente será necessário recriarmos os códigos gerados pelo framework gRPC, tanto do lado do cliente quanto do lado do servidor, e isto pode se tornar uma complicação dentro do processo de desenvolvimento.