Ministério da Educação

Secretaria de Educação Profissional e Tecnológica

Instituto Federal Catarinense
Câmpus Videira

ARTHUR MARCOS SCHNEIDER DE OLIVEIRA

GRPC E REST: IMPLEMENTAÇÃO E ANÁLISE COMPARATIVA

EM UM CENÁRIO DE ORQUESTRAÇÃO DE SISTEMAS

Videira
2023
 ARTHUR MARCOS SCHNEIDER DE OLIVEIRA

GRPC E REST: IMPLEMENTAÇÃO E ANÁLISE COMPARATIVA

EM UM CENÁRIO DE ORQUESTRAÇÃO DE SISTEMAS

Trabalho de Conclusão de Curso apresentado ao

Curso de graduação em Ciência da Computação
do Instituto Federal Catarinense – Câmpus Vi-
deira para obtenção do título de bacharel em Ci-
ência da Computação.
Orientador: Me. Fabio Jose Rodrigues Pinheiro

Videira
2023
 ARTHUR MARCOS SCHNEIDER DE OLIVEIRA

GRPC E REST: IMPLEMENTAÇÃO E ANÁLISE COMPARATIVA

EM UM CENÁRIO DE ORQUESTRAÇÃO DE SISTEMAS

Este Trabalho de Curso foi julgado adequado

para a obtenção do título de Bacharel em Ci-
ência da Computação e aprovado em sua forma
final pelo curso de graduação em Ciência da
Computação do Instituto Federal Catarinense –
Campus Videira.

Videira (SC), 26 de Junho de 2023

Me. Fabio Jose Rodrigues Pinheiro

Instituto Federal Catarinense – Campus Videira

BANCA EXAMINADORA

Me. Wagner Carlos Mariani

Instituto Federal Catarinense – Campus Videira

Me. Wanderson Rigo

Instituto Federal Catarinense – Campus Videira
Dedico este trabalho a minha família e amigos que
corroboraram para animar, inspirar e servirem de
amparo para mim, que estiveram ao meu lado acre-
ditando em meu potencial.
 AGRADECIMENTOS

Agradeço ao meu orientador, não só por sua orientação, mas também paciência e
apoio realizados em todo o período de trabalho, compartilhando de seu conhecimento e com-
promisso com a melhor construção possível desta dissertação.
Também venho a agradecer os outros professores, que de qualquer forma contribuí-
ram direta ou indiretamente, servindo de encorajamento.
 RESUMO

A dissertação demonstra uma análise comparativa das tecnologias gRPC e REST. Pelo último
citado ser um padrão estabelecido no mercado é considerado uma maior percepção do gRPC,
pois, tem o potencial de impulsionar transformações significativas na maneira como os sistemas
são orquestrados. O método adotado envolve um levantamento detalhado das lógicas e tecno-
logias atualmente prevalentes que ditem a escolha e o uso de uma aplicação particular baseada
na capacidade de gerar resultados comparativos significativos com o gRPC, sendo considerado
então uma aplicação de e-commerce (aplicação comum na Web atualmente). Compreendendo
a implementação do mesmo na orquestração do sistema em conjunto com uma análise dos da-
dos resultantes. Embora uma análise preliminar sugira que a escolha entre gRPC e REST pode
depender fortemente do contexto específico do sistema, o estudo busca desvendar as vantagens
latentes do gRPC, mesmo diante da atual falta de incentivo do mercado. O que se espera é
expandir o entendimento atual das potencialidades do gRPC, na esperança de contribuir para
futuras inovações em orquestração de sistemas.
Palavras-chave: API. gRPC. REST. Web. Serviços Web. Sistema. Arquitetura. Aplicações.
 ABSTRACT

The dissertation demonstrates a comparative analysis of gRPC and REST technologies. Since
the latter is an established standard in the market, it is considered a greater perception of gRPC,
as it has the potential to drive significant transformations in the way systems are orchestrated.
The method adopted involves a detailed survey of the currently prevalent logics and technolo-
gies that dictate the choice and use of a particular application based on the ability to generate
significant comparative results with gRPC, being then considered an e-commerce application
(common application on the Web at the moment). Understanding the implementation of the same
in the system orchestration together with an analysis of the resulting data. Although a prelim-
inary analysis suggests that the choice between gRPC and REST may strongly depend on the
specific context of the system, the study seeks to unravel the latent advantages of gRPC, even
in the face of the current lack of market incentive. What is expected is to expand the current
understanding of the potential of gRPC, hoping to contribute to future innovations in system
orchestration.
Keywords: API. gRPC. Rest. Web. Web Services. System. Architecture. Applications.
 LISTA DE ILUSTRAÇÕES

Figura 1 – Estilos Arquitetônicos Mais Utilizados entre os Desenvolvedores . . . . . . 12

Figura 2 – Comparação entre gRPC e APIs HTTP (englobando de forma geral APIs
REST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figura 3 – Origem da Maior Obtenção de Conhecimento Atrelado aos Estilos Arqui-
tetônicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figura 4 – Presunção de Tecnologias Futuras que Acabam Envolvendo Implementa-
ções de APIs REST, gRPC e outras inclusas . . . . . . . . . . . . . . . . . 15
Figura 5 – Orquestração de Comunicações de API: Gerenciamento e Interação entre
Aplicativos e Sistemas de Backend . . . . . . . . . . . . . . . . . . . . . . 21
Figura 6 – Funcionamento prático de uma API . . . . . . . . . . . . . . . . . . . . . . 23
Figura 7 – Funcionamento do Java RMI . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 8 – Popularidade do REST entre Desenvolvedores . . . . . . . . . . . . . . . . 39
Figura 9 – Popularidade do gRPC entre Desenvolvedores . . . . . . . . . . . . . . . . 40
Figura 10 – Componentes e Contexto da Implementação do Protocolo HTTP na Web . . 41
Figura 11 – Funcionamento RPC entre Cliente e Servidor . . . . . . . . . . . . . . . . 48
Figura 12 – Execução do RPC entre Cliente e Servidor . . . . . . . . . . . . . . . . . . 49
Figura 13 – Estrutura do gRPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
 LISTA DE ABREVIATURAS E SIGLAS

API Application programming interface (Interface de Programação de Aplica-

tivo)

ARPANET Advanced Research Projects Agency Network (Rede de Agências para Pro-
jetos de Pesquisas Avançadas)

B2B Business-to-business (de empresa para empresa)

CODASYL Conference on Data Systems Languages (Conferência sobre Linguagens de

Sistemas de Dados)

COM Component Object Model (Modelo de Objeto Componente)

CORBA Common Object Request Broker Architecture (Arquitetura de Corretor de

Solicitação de Objeto Comum)

DCOM Distributed Component Object Model (Modelo de Objeto de Componente

Distribuído)

DDE Dynamic Data Exchange (Intercâmbio Dinâmico de Dados)

DevOps Development Operations (Operações de Desenvolvimento)

EAI Enterprise Application Integration (Integração de Aplicativos Corporati-

vos)

EDI Electronic Data Interchange (Intercâmbio Eletrônico de Dados)

EDIINT Electronic Data Interchange-Internet Integration (Intercâmbio Eletrônico

de Dados - Integração com a Internet)

FTP File Transfer Protocol (Protocolo de Transferência de Arquivos)

gRPC gRPC ou Google Remote Procedure Calls (Chamada de Procedimento Re-

moto do Google)

HTTP Hypertext Transfer Protocol (Protocolo de Transferência de Hipertexto)

HTML HyperText Markup Language (Linguagem de Marcação de Hipertexto)

IDL Interactive Data Language (Linguagem de Dados Interativa)

IMS Integrated Management System (Sistema de gestão Integrado)

IoT Internet of Things (Internet das Coisas)

IP Internet Protocol (Protocolo de Internet)

JSON JavaScript Object Notation (Notação de Objeto JavaScript)

NCP Network Control Protocol (Protocolo de Controle de Rede)

OLE Object Linking and Embedding (Vinculação e Incorporação de Objetos)

OMG Object Management Group (Grupo de Gerenciamento de Objetos)

RDBMS Relational Database Management System (Sistema de Gerenciamento de

Banco de Dados Relacional)

REST Representational State Transfer (Transferência de Estado Representacio-

nal)

RMI Remote Method Invocation (Invocação do Método Remoto)

RPC Remote Procedure Calls (Chamada de Procedimento)

SGML Standard Generalized Markup Language (Linguagem de Marcação Gene-

ralizada Padrão)

SOA Service-oriented Architecture (Arquitetura Orientada a Serviços)

SOAP Simple Object Access Protocol (Protocolo de Acesso a Objetos Simples)

SQL Structured Query Language (Linguagem de Consulta Estruturada)

TCP Transmission Control Protocol (Protocolo de Controle de Transmissão)

TELNET Teletype Network (Rede de Teletype)

TI Tecnologia da Informação

TLS Transport Layer Security (Segurança da Camada de Transporte)

UDP User Datagram Protocol (Protocolo de Datagrama do Usuário)

VM Virtual Machine (Máquina Virtual)

WWW World Wide Web (Rede Mundial de Computadores)

XML Extensible Markup Language (Linguagem de Marcação Extensível)

XSL Extensible Stylesheet Language (Linguagem de Folha de Estilo Extensível)

 SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.1 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 FUNDAMENTAÇÃO TEÓRICA I: DEFINIÇÃO HISTÓRICA DE CO-
MUNICAÇÃO E INTEGRAÇÃO NA ORQUESTRAÇÃO DE SISTEMAS 18
2.1 Conceito e Histórico da Web . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Representação das Aplicações e APIs para a Web . . . . . . . . . . . . . . . 19
2.3 Evolução da Comunicação e Integração de Sistemas: Principais Tecnologias
Empregadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1 Mainframe: Primeiras Implicações na Integração de Aplicações Empre-
sariais (Enterprise Application Integration - EAI) . . . . . . . . . . . . . . 23
2.3.2 EDI: Início da Popularidade na Comunicação Eletrônica de Dados . . . 25
2.3.3 Banco de Dados e SQL: Novas Formas para Representação de Dados . . 26
2.3.4 CORBA e Java RMI: Interação Transparente entre Objetos de Software
em Sistemas Separados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.5 XML e SOAP: Troca e Armazenamento de Dados Estruturados na Web
e Interoperabilidade entre Aplicações Distintas Através de Redes . . . . 29
2.3.6 SOA: Estímulo do Design Modular e Interoperabilidade em Sistemas de
Computação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.7 Microsserviços, Serverless e Outros Atuais . . . . . . . . . . . . . . . . . 35
3 FUNDAMENTAÇÃO TEÓRICA II: APROFUNDAMENTO NO HIS-
TÓRICO, LÓGICA E FUNCIONAMENTO BASE DO gRPC e REST . 37
3.1 REST: Estilo Arquitetônico para Aplicações em Rede . . . . . . . . . . . . 38
3.1.1 Entendendo sobre o Protocolo HTTP . . . . . . . . . . . . . . . . . . . . 40
[Link] Funcionamento Aprofundado do Protocolo HTTP, Mensagens e Métodos . . 42
3.1.2 Funcionamento do REST . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.3 Definição de uma API REST empregada na Web . . . . . . . . . . . . . . 46
3.2 gRPC: framework open-source para chamadas de procedimento remoto . . . 46
3.2.1 Funcionamento aprofundado da técnica RPC . . . . . . . . . . . . . . . 47
3.2.2 Especificidades no Funcionamento do gRPC . . . . . . . . . . . . . . . . 50
3.2.3 Entendendo sobre o Protocolo HTTP/2 . . . . . . . . . . . . . . . . . . . 55
3.3 Pontos Positivos e Negativos: REST e gRPC . . . . . . . . . . . . . . . . . 56
3.4 Orquestração de Sistemas: contexto histórico, definição e importância . . . . 58
3.5 Correlatos: Migração e Propostas de Uso para gRPC . . . . . . . . . . . . . 59
3.5.1 Primeiro Artigo: Proposta do gRPC como uma Nova API Northbound
para Eficiência na Comunicação na Camada de Aplicação em SDN . . . 60
3.5.2 Segundo Artigo: Utilizando Refatoração para Migrar Aplicações REST
para gRPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4 Metodologia de Pesquisa: Análise Comparativa de REST e gRPC na Or-
questração de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1 Identificação do problema e Revisão Bibliográfica . . . . . . . . . . . . . . 62
4.2 Configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3 Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4 Coleta de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.5 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.6 Comparativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.7 Orçamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.8 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
 12

1 INTRODUÇÃO

Em um mundo cada vez mais interconectado, a comunicação entre sistemas é um

elemento fundamental para o sucesso de qualquer aplicação. Tanto o gRPC quanto o REST
foram criados para atender a necessidades diferentes e possuem características que podem torná-
los a escolha ideal dependendo de exigências específicas.
O gRPC, sendo uma estrutura de procedimento remoto de alto desempenho desen-
volvida pela Google, permite basicamente a comunicação entre sistemas de forma eficiente,
independente da linguagem de programação utilizada. Esta tecnologia, que é baseada em Pro-
tocol Buffers para definir contratos de serviço e serializar dados, oferece muitas vantagens como
baixa latência, alta velocidade e suporte a streaming, tornando-a uma opção poderosa para sis-
temas que precisam de comunicação em tempo real ou que tratam com grandes volumes de
dados (GOOGLE, 2023b). Quanto ao REST (Representational State Transfer), um estilo de ar-
quitetura de software para sistemas distribuídos, utiliza os protocolos HTTP padrão, tornando-o
universalmente compatível com praticamente todos os sistemas que podem se comunicar via
Web, sendo muito conhecido por sua simplicidade, escalabilidade e fácil integração, sendo po-
pular para o desenvolvimento de APIs Web (FIELDING, 2000).
Baseando-se em estatísticas presentes no site: Postman (ferramenta amplamente uti-
lizada entre desenvolvedores para construir, testar e modificar APIs), mais especificamente em
seu relatório sobre o estado de diferentes APIs em 2022, apresentou os seguintes resultados
(representados especificamente nas figuras 1, 3 e 4):

Figura 1 – Estilos Arquitetônicos Mais Utilizados entre os Desenvolvedores

Fonte: (POSTMAN, 2022)

 13

É possível verificar que especificamente o estilo predominante é o REST, e essa

mesma conclusão se seguia no ano passado, onde segundo a plataforma houve uma queda: 92%
em 2021 e 89% em 2022. Quanto ao gRPC assim como outros estilos, acabaram ganhando mais
espaço por conta disso, onde o gRPC apresentava 8% em 2021 e em 2022 contou com 11%. O
REST justamente torna-se relevante principalmente pelo fato de ainda ser plenamente utilizado
em diversas e diferentes aplicações. Entretanto, mesmo com essa presença predominante no
cenário atual, o gRPC apresenta suas desvantagens e principalmente suas vantagens específicas
e exclusivas em relação ao uso do REST, sendo assim o mesmo pode apresentar um papel crucial
em determinadas aplicações e intenções em um projeto (POSTMAN, 2022).
Tratando de forma superficial, já que será aprofundado em tópicos posteriores do
trabalho, o gRPC apresenta algumas vantagens importantes e contextos que se provariam mais
interessantes do que o uso do REST (VERTIGO, 2020). Muitas dessas diferenciações podem
passar a serem observadas como as apresentadas na figura 2 de forma resumida:

Figura 2 – Comparação entre gRPC e APIs HTTP (englobando de forma geral APIs REST)

Fonte: (MICROSOFT, 2023a)

Justamente por conta do gRPC apresentar características para situações determina-

das, isso corrobora para que seja visto como um estilo arquitetônico válido no que tange desen-
volvimento de software (trazendo uma nova abordagem para a mesma), expandido as opções,
ferramentas e possibilidades para as exigências dos desenvolvedores e projetos, consequente-
mente trazendo inovação na área. Por isso tende ainda a crescer e solidificar melhor seu espaço
em relação ao REST.
 14

Retornando ao relatório da plataforma Postman, outro resultado interessante cole-

tado é de onde os desenvolvedores aprenderam o uso desses estilos arquitetônicos:

Figura 3 – Origem da Maior Obtenção de Conhecimento Atrelado aos Estilos Arquitetônicos

Fonte: (POSTMAN, 2022)

Nestes resultados em específico, os três primeiros que mais acumularam em por-

centagem, demonstra um envolvimento em áreas acadêmicas e profissionais (ou indústrias),
provando que de fato apresentam não só importância na formação dos desenvolvedores como
também consequentemente de seu próprio trabalho, englobando uma ideia de importância teó-
rica e prática. Ficando 63% para "no trabalho ou com colegas", 59% para "documentação do
estilo arquitetônico"e 54% em "aulas online"(POSTMAN, 2022).
Além disso, outra informação pertinente é entender em que tecnologias esses estilos
arquitetônicos acabaram sendo utilizados, como apresenta na figura da próxima página.
Nela percebe-se que se predominam aplicações que envolvem em grande parte em
sua base ideias de escalabilidade, como por exemplo os próprios microsserviços englobando
56% dos desenvolvedores, kubernetes com 48%, arquitetura sem servidor e containers, ambos
exatamente com 41%. Mesmo com a predominância de microsserviços a pesquisa também res-
salta de que alguns participantes mencionam (um quarto dos entrevistados) se incomodar que a
multiplicação dos mesmos se prova uma barreira para a criação geral de APIs.
 15

Figura 4 – Presunção de Tecnologias Futuras que Acabam Envolvendo Implementações de APIs

REST, gRPC e outras inclusas

Fonte: (POSTMAN, 2022)

Com essas informações levantadas, este trabalho acadêmico traz o foco em verificar
atualmente o uso de tecnologias para a comunicação entre sistemas distribuídos, principalmente
quanto a implementação, arquitetura, modelagem e organização interna. No caso, é tratado em
específico, duas tecnologias: REST (Representational State Transfer) e gRPC (gRPC Remote
Procedure Call), ambas sendo voltadas geralmente para serviços Web. A partir da análise de
recursos e uso de ambas em uma aplicação testada, será buscado entender em quais situações
o uso de uma pode se tornar mais relevante do que outra. Portanto, seu valor ou a finalidade
de uma tecnologia sem necessariamente precisar entender todos seus detalhes técnicos, além
de também buscar outras conclusões mais profundas baseadas nas especificidades de cada tec-
nologia (como, por exemplo, as implicações futuras das duas no mercado e para o trabalho
de desenvolvedores), deixando ramificações para futuros trabalhos acadêmicos se inspirarem e
utilizarem deste como referência.
Logo, será apresentada uma visão geral dessas tecnologias, seus conceitos, seme-
lhanças e diferenças, demonstrando sobre o que a tecnologia faz, quais problemas resolve, como
se encaixa no contexto mais amplo dos sistemas de computação e quais são suas principais ca-
racterísticas e benefícios.
Baseado nessas informações sobre ambas as tecnologias a próxima seção dá um
maior enfoque no que será abordado nesse trabalho e nos seus futuros testes.
 16

1.1 JUSTIFICATIVA

Como o mundo da Web e especificamente do comércio eletrônico continua a evoluir

rapidamente, é crucial adotar tecnologias que possam otimizar o sistema e aprimorar as expe-
riências do usuário e desenvolvedores. Este estudo busca implementar o crescente gRPC na
orquestração de serviços em um sistema de e-commerce da Web e comparativamente analisá-lo
com o REST, justamente por conta de sua hegemonia.
Este estudo contribui para a compreensão mais aprofundada dessas duas aborda-
gens significativas usadas na criação, integração e comunicação de sistemas. Ao comparar a
facilidade de implementação, a flexibilidade arquitetônica e as implicações na modelagem e
organização interna de sistemas de cada abordagem, este trabalho pode orientar decisões de
design de sistemas e escolhas tecnológicas. Consequentemente o estudo consegue elucidar em
quais contextos uma abordagem pode ser mais apropriada que a outra. Enquanto o REST, por
exemplo, pode ser adequado para aplicações Web públicas que requerem escalabilidade, o gRPC
pode ser mais eficaz em contextos de microsserviços onde a eficiência de comunicação e a baixa
latência são fundamentais.
A adoção do gRPC pode ser uma boa escolha na orquestração de um sistema, pois
é notável destacar suas vantagens, como o uso do HTTP/2, o suporte inerente para streaming
bidirecional e a forte tipagem de dados com Protocol Buffers, levando isso em conta a sistemas
baseados em REST. Isso pode proporcionar informações valiosas para desenvolvedores consi-
derando essa migração. O valor deste trabalho encontra-se na capacidade de fornecer insights
práticos e orientação estratégica para o desenvolvimento e tomadas de decisão na indústria, fa-
cilitando a escolha da tecnologia mais adequada de acordo com as necessidades e os contextos
específicos dos projetos.
Sendo assim, a adoção do gRPC (com seus componentes específicos) pode ser vista
como um investimento para garantir o futuro do aplicativo específico diante da evolução de
aplicações Web.

1.2 OBJETIVO GERAL

Esse trabalho tem como principal objetivo comparar e listar diferenças nos estilos
arquitetônicos gRPC e REST para o desenvolvimento na orquestração de sistemas e aplicações
Web em geral.
 17

1.2.1 Objetivos Específicos

Para um melhor detalhamento do objetivo geral, abaixo estão listados os objetivos

específicos propostos:
- Análise do histórico na comunicação e integração de sistemas, indicando as arqui-
teturas utilizadas corroborano no levantamento de qual se utilizar para a aplicação específica;
- Recolhimento das informações de como a tecnologia gRPC e do modelo REST
são usados em aplicações Web reais, suas semelhanças e diferenças;
- Avaliação do uso de ambas (curva de aprendizado, qualidade, disponibilidade de
documentação e suporte) em um cenário de uso determinado, no caso aplicação de e-commerce;
- Fornecimento de recomendações, sobre quando um se torna mais interessante uti-
lizar em relação ao outro e sugestão tendências futuras, baseado nas observações anterioras.
 18

2 FUNDAMENTAÇÃO TEÓRICA I: DEFINIÇÃO HISTÓRICA DE COMUNICAÇÃO

E INTEGRAÇÃO NA ORQUESTRAÇÃO DE SISTEMAS

2.1 CONCEITO E HISTÓRICO DA WEB

Como citado previamente na introdução, tanto gRPC quanto o REST são, basica-
mente, tecnologias utilizadas para a arquitetura de sistemas voltados para Web, com o gRPC
sendo mais abrangente, utilizado para aplicações comuns como: microsserviços, aplicações
Web, comunicação entre plataformas, IoT e streaming de dados em tempo real. Antes de en-
tender o que de fato são às duas aplicações, é necessário tomar a conceitualização de alguns
termos, contextos históricos e também do que corroborou para a existência dos mesmos até
chegar em como utilizamos nossas aplicações atualmente.
A Web como é conhecida hoje, criada por Tim Berners-Lee, estaria desde sua ori-
gem sendo constituída de vários programas e um grupo de protocolos e normas, que serviram
de base para muitas das tecnologias atuais, e isso surgiu inicialmente utilizando-se de métodos
de hipertexto e diversos recursos multimídias (W3C, 2001). Em 1980 as informações passaram
a ser armazenadas com links aleatórios, servindo de base para que em 1989 isso alcançasse
um escopo global (afim de atingir o usuário comum), Tim o denominou como um “Identifi-
cador Universal de Documentos”, e em 1990 de fato o termo “World Wide Web (WWW)” foi
empregado para o projeto (W3C, 1998).
Como resultado, novos protocolos comuns passaram a ser discutidos e implemen-
tados para a Web, com o objetivo de evoluir a ideia (W3C, 1998). Tanto que existem múltiplas
versões pensadas da mesma, onde cada uma tenta corrigir limitações e expande a lógica das
anteriores (KHANZODE, 2016).
A Web só alcançou um escopo global pois foi proposto o uso do hipertexto para
ligar e acessar informações como se fosse uma teia constituída de múltiplos nós onde o usuário
poderia navegar à vontade. Sendo assim, ela foi projetada para que a interação humana fosse for-
tificada pelas redes tecnológicas, baseando-se em ampliar o conhecimento e comunicação dos
indivíduos (KHANZODE, 2016). De maneira simplificada, a Linguagem de Marcação de Hi-
pertexto (HyperText Markup Language - HTML), foi o recurso utilizado para moldar e estruturar
o conteúdo de um site na Web, e isso possibilitou que a informação fosse disposta em diversos
formatos, tais como parágrafos, listas numeradas, figuras e tabelas (MOZILLA, 2023c).
A “Web 1.0”, como passou a ser conhecida essa primeira fase de criação, foi mar-
 19

cada por ser apenas uma oportunidade de usuários lerem informações contidas em um site, não
havia a mínima possibilidade para eles interagirem com o conteúdo presente, não podendo edi-
tar, comentar, postar e outras ações comuns atualmente (NATH; DHAR; BASISHTHA, 2014).
Considerando essas características citadas, faz sentido pensar de que a mesma tinha seus da-
dos sendo apresentados por páginas HTML estáticas (monodirecional) (AGHAEI; NEMAT-
BAKHSH; FARSANI, 2012).
Em 2004, foi denominada uma nova fase em que a Web se encontrava: “2.0”, como
passou a ser cunhada. Era conhecida diferentemente da primeira por ser “de leitura e escrita”,
pois, trazia uma nova ideia para desenvolvimento de serviços e sites já que agora permitia inte-
ração entre usuários (bidirecional) (AGHAEI; NEMATBAKHSH; FARSANI, 2012). Essa nova
fase representa a transformação nos negócios do setor de informática, impulsionada pela adoção
da Internet como principal plataforma pelas entidades, e por esforços para desenvolver normas
(AGHAEI; NEMATBAKHSH; FARSANI, 2012) (NATH; DHAR; BASISHTHA, 2014).
Após a conceitualização da Web, é necessário entender uma das principais ferra-
mentas utilizadas pelos desenvolvedores: a Interface de Programação de Aplicativos (Applica-
tion Programming Interface - API). Para a "Web 2.0", a popularização das APIs forneceu uma
maneira eficiente de acessar e manipular dados, expondo funcionalidades específicas de um
sistema, permitindo que outros sistemas interajam com ele de maneira controlada. Isto trouxe
acesso direto aos dados subjacentes e funcionalidades do sistema, tornando-as menos propensas
a quebrar com alterações na interface do usuário (PAUTASSO; ZIMMERMANN; LEYMANN,
2008). A próxima seção foca justamente em abordar essa tecnologia ainda extremamente utili-
zada em contextos atuais.

2.2 REPRESENTAÇÃO DAS APLICAÇÕES E APIS PARA A WEB

Tendo em mente os conceitos base que constituem a Web de fato, é possível sa-
ber que quando algum usuário está navegando para realizar qualquer atividade específica na
Internet, ele está usufruindo justamente de aplicativos presentes nela.
Um aplicativo Web é um programa de computador armazenado em um servidor
remoto e que tende a ser executado por usuários por meio de um navegador, por isso acaba
permitindo que ele seja compatível com a maioria dos computadores e sistemas operacionais
padrão, podendo ser acessado por qualquer dispositivo desde que tenha conexão com a Internet
(VOLLE, 2022). Sendo assim, qualquer serviço oferecido por ela, por definição, é uma forma
 20

de aplicação Web, sendo neste caso serviços conhecidos como e-mail, google drive, dropbox,
canva e github, considerando uma perspectiva mais generalista (VOLLE, 2022).
Para a construção de tais serviços pode-se utilizar diferentes linguagens de progra-
mação tanto para o front-end (lado do cliente ou usuário) quanto para seu back-end (lado do
servidor) que irão realizar um tratamento das informações obtidas. Com relação à arquitetura
de ambos os lados, elas se fazem presentes em inúmeras linguagens e possibilidades que podem
ser empregadas para a construção da lógica de cada uma delas. No início da Web até a contem-
poraneidade é apresentado uma mesma base lógica para a comunicação entre o lado cliente e
servidor, funcionando da seguinte forma: o usuário acessando o aplicativo inicia uma solicita-
ção por meio de seu navegador, o servidor então envia, executa ou responde a solicitação de
maneira condizente com o que foi pedido na mensagem solicitada, permitindo que o usuário
realize a ação pretendida (VOLLE, 2022).
Muitas vezes essa comunicação mencionada é realizada por meio de uma Inter-
face de programação de aplicativos (Application programming interface - API), representando
um conjunto de normas estabelecidas que possibilitam especificamente a comunicação entre
diferentes aplicativos. Ela funciona como uma camada intermediária responsável por geren-
ciar transferências de dados entre sistemas, permitindo que as organizações compartilhem seus
dados e recursos de aplicativos com desenvolvedores externos, parceiros comerciais e setores
internos, podendo ser implementada em diferentes arquiteturas, até mesmo opostas, como em
microsserviços e a monolítica, por exemplo (AL-DEBAGY; MARTINEK, 2018).
A arquitetura baseada em microsserviços funciona como um conjunto de pequenos
serviços que realizam chamadas entre si, mas que funcionam de maneiras separadas, indivi-
dualmente. Já aplicações monolíticas, possuem a programação de seus serviços em uma única
base de código os gerenciando, sem a mesma estar dividida em outros programas. Entretanto,
independente da arquitetura em questão, ambas podem fazer o uso de APIs para melhoria na
produtividade e padronizações do código, com uma comunicação se dando por conta dessas
interfaces. Por isso se faz necessário entender o que de fato é esse termo, seus princípios e fun-
cionalidades (AL-DEBAGY; MARTINEK, 2018). As especificações e protocolos presentes em
uma API auxiliam as empresas a conectar diversos aplicativos utilizados em suas atividades co-
tidianas, poupando tempo dos colaboradores e eliminando barreiras que dificultam a cooperação
e a inovação. Para os desenvolvedores, a documentação de uma API oferece a interface neces-
sária para a comunicação entre os aplicativos, facilitando a integração entre eles (REDHAT,
 21

2022) (GU et al., 2016).

Uma representação gráfica a seguir demonstra o conceito atrelado a orquestração de
APIs. Ela esquematiza a forma como os aplicativos interagem com o sistema de gerenciamento
de API, que, por sua vez, se comunica com os sistemas de backend através de APIs:

Figura 5 – Orquestração de Comunicações de API: Gerenciamento e Interação entre Aplicativos

e Sistemas de Backend

Fonte: (REDHAT, 2022)

Na lógica proposta, o sistema de gerenciamento de API atua como um intermediário

que controla e gerencia a comunicação entre os aplicativos e as APIs dos sistemas de backend.
Ele fornece funcionalidades como roteamento de solicitações, limitação de taxa, autenticação e
autorização, além de oferecer ferramentas para monitorar e analisar o uso da API. Dessa forma,
os aplicativos podem se comunicar de maneira eficiente com os sistemas de backend (REDHAT,
2022).
É bom citar também de que embora a transferência de dados possa variar conforme
o serviço utilizado, todas as requisições e respostas ocorrem por meio da API. Não há visibili-
dade na interface do usuário, o que significa que as APIs trocam informações internamente no
computador ou aplicativo e, para o usuário, parecem uma conexão contínua (IBM, 2020).
Vendo essas questões de lado cliente e servidor, as APIs ditam muito atualmente
sobre o funcionamento na comunicação e integração em muitos dos sistemas, entretanto, nem
sempre aplicações funcionavam dessa maneira, a próxima seção tem como objetivo apresentar
um histórico de principais tecnologias que trouxeram até o entendimento atual do solidificado
REST e do emergente gRPC.
 22

2.3 EVOLUÇÃO DA COMUNICAÇÃO E INTEGRAÇÃO DE SISTEMAS: PRINCIPAIS

TECNOLOGIAS EMPREGADAS

A comunicação e integração de sistemas engloba a conexão de diferentes sistemas

de software e aplicativos que necessitam de uma troca eficiente dos dados ou informações, per-
mitindo com que exista um conversa entre eles. Uma exemplificação básica e contemporânea
do que essas ideias tratam pode ser analisada da seguinte forma: considerando um site atrelado
ao comércio eletrônico e que o mesmo apresente um sistema de estoque por meio de uma API,
quando o usuário desejar realizar uma encomenda, o sistema desenvolvido para o site precisa
se comunicar com a API integrada ao sistema de gerência do estoque, que consequentemente
atualizaria o número de unidades do produto em específico comprado. Durante essa comunica-
ção entre ambos os sistemas, a mensagem repassada do site para o estoque poderia conter dados
como a ID do que foi comprado em questão, preço, data, quantidade, e muitas outras informa-
ções que sejam pertinentes para o funcionamento pleno de todo o projeto conforme construído
por seus desenvolvedores. Com esta mensagem enviada, depois que o sistema do estoque re-
cebesse uma chamada da API, o mesmo atualizaria suas unidades do produto em questão e
retornaria uma resposta para o site, onde também poderia ser preenchido com informações si-
milares as que foram citadas anteriormente (HEYDARI, 2022).
A figura apresentada na próxima página é uma representação gráfica desse sistema
básico de comunicação, presente em muitos negócios de e-commerce atuais.
O exemplo anterior e o da figura mencionada, é uma clara conceitualização básica
de integração, pois, envolve o comprometimento e pleno funcionamento de mais de uma enti-
dade (site e gerência de estoque) e também de comunicação para que haja um desenvolvimento
correto e claro da atividade que deve ser realizada. Por conta disso é importante saber que as
necessidades da integração e da comunicação entre dois ou mais sistemas com certeza tende a
variar considerando o software empregado, a intenção da organização ou pessoa, o escopo do
projeto em questão, e muitas outras especificidades.
 23

Figura 6 – Funcionamento prático de uma API

Fonte: (HEYDARI, 2022)

A maneira apresentada é como muitos sites operam atualmente. Além dessas ex-
plicações de tecnologias e termos, outro elemento que se faz necessário para o entendimento
aprofundado desses estilos arquitetônicos (no caso gRPC e REST) é a noção do histórico de
evolução tanto da lógica quanto de ferramentas implementadas ao longo dos anos que envol-
vem integrações e comunicações no desenvolvimento de sistemas, que estão representados e
divididos nas seguintes subseções: "Mainframe", "EDI", "Banco de dados e SQL", "CORBA e
Java RMI", "XML e SOAP", "SOA", para então de fato sobre o gRPC e REST.

2.3.1 Mainframe: Primeiras Implicações na Integração de Aplicações Empresariais (En-

terprise Application Integration - EAI)

Entre 1950 e durante a década de 1960, o processamento remoto de dados conseguiu

ser realizado por conta da integração entre mainframes. Isso se deve pela criação do modem,
uma ferramenta que acabou permitindo que terminais remotos conseguissem se conectar jus-
tamente as máquinas, mas todo o processamento ainda era realizado pelo próprio mainframe,
que eram grandes computadores (compostos de diversos componentes de hardware) que ocu-
pavam salas inteiras com estes ambientes devendo ser controlados e assegurados rigorosamente
 24

(TECHNOLOGYUK, 2009).
Inicialmente mainframes eram utilizados para o processamento em bloco onde um
conjunto de tarefas era reunido e executado sequencialmente. Mesmo que com o uso de fi-
tas e discos magnéticos acelerasse a entrada de informações, a unidade de processamento do
mainframe ainda permanecia inativa na maior parte do tempo. Por conta disso desenvolveu-se
o conceito de multiprogramação, onde diversos programas coexistem na memória ao mesmo
tempo, possibilitando que o computador dedicasse uma pequena quantidade de tempo de pro-
cessamento para cada operação individualmente. Com essas otimizações, inúmeros terminais
conseguiam acessar e aproveitar a capacidade de processamento de um computador ao mesmo
tempo (TECHNOLOGYUK, 2009).
A ideia de interconectar mainframes de diferentes entidades ainda não era comum.
A necessidade não era percebida, pois, manter as máquinas operando de forma independente
não representava um problema e com o tempo eles se tornaram máquinas multiusuário. Con-
tanto que as pessoas estivessem conectadas ao mesmo computador, elas poderiam compartilhar
dados e até enviar e-mails umas para as outras. De certo modo, essas máquinas eram as precur-
soras do moderno conceito de data center (RESELMAN, 2020).
Os mainframes funcionando como servidores centrais executavam o gerenciamento
de recursos, processamento de dados e armazenamento de informações na ARPANET (precur-
sora da Internet, responsável por gerenciar conexões de rede, roteamento e controle de congesti-
onamento, posteriormente substituído pelo TCP/IP). Isso era feito com o Protocolo de Controle
de Rede (Network Control Protocol - NCP) sendo utilizado para estabelecer a comunicação na
rede, possibilitando que as máquinas hospedassem serviços e aplicativos acessados por outros
dispositivos, como terminais de computador. Esse antigo protocolo permitia, por exemplo, o
acesso remoto a dispositivos usando o protocolo TELNET e a transferência de arquivos por
meio do Protocolo de Transferência de Arquivos (File Transfer Protocol - FTP). Essa interco-
nectividade entre os mainframes e a utilização do protocolo NCP foram elementos essenciais
para o desenvolvimento da rede moderna (RESELMAN, 2020) (TECHNOLOGYUK, 2009).
Entretanto, ainda no início dos anos 1980, por conta do alto custo nos recursos que
envolviam mainframes, novas evoluções passaram a ocorrer, conforme também uma otimização
no tamanho e capacidade de processamento dos hardwares (RESELMAN, 2020).
 25

2.3.2 EDI: Início da Popularidade na Comunicação Eletrônica de Dados

No final da década de 60, outra tecnologia inovava na comunicação e integração

de sistemas, o Intercâmbio Eletrônico de Dados (Electronic Data Interchange - EDI), onde era
criado um formato de mensagem eletrônica para transmitir dados de embarque relacionados
à carga, além de iniciar uma padronização de dados eletrônicos na indústria de transporte (é
interessante mencionar de que ele possuia um comitê responsável por criação de normas). En-
tretanto, foi apenas a partir dos anos 70 que ele se provou efetivo para o mercado, justamente
porque para a evolução de sua tecnologia, necessitou muito do auxílio da publicação do FTP,
que possibilitava o movimento de arquivos, e futuramente até entre sites na Internet, especifi-
cando as portas que deveriam ser utilizadas, comandos aceitos e configurações de parâmetros
permitidos para os diferentes modos de transferência (CLEO, 2020).
O EDI é um processo que possibilita a transferência eletrônica de informações de
negócios entre organizações, eliminando a necessidade do uso do papel. Esse método padro-
nizado de enviar e receber dados sobre transações e mensagens melhorou a eficiência das co-
municações empresariais, pois, reduziu custos, acelerou o processamento e fortaleceu relações
com os parceiros comerciais. Portanto, pode-se considerar o EDI como uma língua universal
para a comunicação eletrônica de negócios (CLEO, 2020). De início, os dados são coletados
e organizados em um arquivo eletrônico. Na segunda etapa, os dados são alimentados em um
aplicativo tradutor que converte o formato interno para o padrão EDI. Por fim, os documentos
convertidos são transmitidos para o parceiro de negócios (BASICS, 2017). Para garantir uma
troca fluida de documentos, as empresas devem concordar sobre o padrão e a versão do EDI.
Também necessário um software tradutor EDI (podendo ser interno ou fornecido por um pro-
vedor de serviços), é utilizado para converter o formato específico gerado em dados utilizáveis
para os aplicativos internos das empresas (BASICS, 2017) (ENCYCLOPEDIA, 2022).
Em 1991, surgiu o EDI pela Internet (EDIINT), visando padronizar as transmissões
de dados pela mesma. Uma década depois, em 2001, foi permitido o envio criptografado de
dados pela Internet utilizando o protocolo HTTP (CLEO, 2020).
Sendo assim, torna-se claro algumas vantagens que o EDI conseguia proporcionar:
uma economia substancial (eliminando gastos com impressão, armazenamento e postagem), au-
tomatizou transações, com isso concomitantemente eliminou a necessidade de entrada manual
de dados e os erros humanos associados (CLEO, 2020).
Em contrapartida, ele ainda apresentou certos desafios: a criação e leitura de docu-
 26

mentos eram e são trabalhosos, havendo uma grande carga cognitiva dos desenvolvedores de
mapear e testar regras. Por isso muitas entidades acabam por não aderir completamente aos pa-
drões. Outro problema que se faz presente é de não apresentar um custo claro para a integração
de cada novo parceiro comercial (ADEPTIA, 2015).

2.3.3 Banco de Dados e SQL: Novas Formas para Representação de Dados

Mesmo com a popularidade nos anos 80 envolvendo a implementação dos sistemas

de gerenciamento de banco de dados relacionais (RDBMS) e da tecnologia SQL (linguagem
de consulta estrutura), seu primórdio foi marcado nos anos 60, sendo a ascensão do conceito
de "banco de dados", onde houve o uso interativo compartilhado sobre o processamento em
lote. Nisso, dois modelos de dados notáveis surgiram nessa época: o modelo de rede CODASYL
(Conference on Data System Language) e o modelo hierárquico IMS (Information Management
System). Esses sistemas pioneiros eram orientados à navegação, onde os dados eram acessados
seguindo ponteiros de um registro a outro, e a estrutura de armazenamento era moldada pelo
tipo de dados. Modificar a estrutura do banco de dados, como adicionar um campo, exigia a
reescrita do esquema subjacente de acesso/modificação (o usuário tinha que ter conhecimento
sobre a estrutura física do banco de dados para executar consultas) (BERG; SEYMOUR; GOEL,
2013).
Em 1970, foi concebida a ideia de estruturar um conjunto de tabelas interligadas
que possibilitavam o armazenamento único de qualquer dado, permitindo a resposta a qualquer
pergunta cuja resposta estivesse contida no banco de dados (COCKROACHLABS, 2022). Entre
1974 e 1977, propuseram um novo modelo chamado entidade-relacionamento, que priorizava o
foco nos dados da aplicação em vez da estrutura lógica da tabela, e o termo RDBMS foi criado
(BERG; SEYMOUR; GOEL, 2013).
Durante os anos 80 e 90, a dominação dos bancos de dados relacionais se acentuou,
caracterizada pelo fornecimento de índices complexos que garantiam a eficiência das consultas.
O SQL se estabeleceu como a linguagem oficial de dados, com desenvolvedores aprendendo
a utilizar para solicitar informações, deixando ao banco de dados a decisão de como fornecê-
las, tendo assim suas primeiras implementações comerciais (COCKROACHLABS, 2022). Em
1986, um padrão de definição de linguagem denominado “Database Language SQL” foi ofici-
alizado. Então, com o tempo, novas versões foram lançadas, com atualizações significativas.
Esse modelo de dados relacional criado em 70, que aumentava o nível de abstração
 27

para interação com dados armazenados, foi um elemento essencial para o sucesso do SQL. A
linguagem se mostrou simples e expressiva o suficiente para realizar tarefas úteis. Outro fator
de sucesso foi unir consulta, atualização e tarefas administrativas em uma única linguagem,
facilitando a modificação de esquemas de banco de dados (CHAMBERLIN, 2012).
Atualmente, os dados estruturados são mantidos em uma série de tabelas, cada uma
composta por registros ou linhas, também referidos como tuplas e atributos, que são as colunas
(estas últimas são projetadas para guardar tipos específicos de informação como datas, nomes ou
valores). Dentro de cada banco de dados, encontramos grupos de objetos proprietários chamado
esquemas, que abrigam objetos como tabelas, visualizações e procedimentos. Existem objetos,
como certificados e chaves assimétricas, que residem no banco de dados, porém, não estão
incluídos em um esquema (MICROSOFT, 2023c) (DAGA, 2022).

2.3.4 CORBA e Java RMI: Interação Transparente entre Objetos de Software em Siste-
mas Separados

Nos anos 90 surgem os primeiros sistemas que permitiam a comunicação direta

entre diferentes aplicações de software através das redes, como, por exemplo, o CORBA e o
Java RMI.
A diversidade de ambientes de hardware e software em sistemas distribuídos fre-
quentemente resulta em desafios para a integração dessas soluções na criação de aplicações que
aproveitem tais plataformas. A especificação aberta Common Object Request Broker Architec-
ture (CORBA), promulgada pela Object Management Group (OMG), foi projetada para solu-
cionar este problema, se destacando por permitir interoperabilidade entre aplicações diversas,
ancorando-se no modelo cliente e servidor e no paradigma da orientação a objetos distribuídos
(LINK et al., 2007?).
Muitos consideram que a história da tecnologia começa em 1991, com a versão 1.0,
onde foram introduzidos o modelo de objeto CORBA, a Interface Definition Language (IDL)
utilizada para definir os tipos de objetos através da descrição de sua interface, contendo di-
ferentes métodos e parâmetros associados, e APIs para a gestão de solicitações dinâmicas e
invocação (CORBA, 2011). Nos anos seguintes o CORBA viu várias atualizações incremen-
tais, aprimorando a segurança, adicionando novos mapeamentos de linguagem (CORBA, 2011)
(HENNING, 2008).
Entretanto, mesmo que tenha sido popular em seu início, por conta da grande difi-
culdade que era escrever um aplicativo, além de APIs complexas e porque contrariava a sim-
 28

plicidade de outros modelos competentes, fez com que o CORBA perdesse espaço no mercado.
Outro ponto foi, novamente, o custo da implementação, além dos grandes tempos de desenvol-
vimento e taxa de defeitos. Por isso, atualmente, é majoritariamente aplicado para estabelecer
conexões entre componentes operando dentro das redes corporativas (tecnologia de nicho e
desatualizada) (HENNING, 2008).
O advento do CORBA com suas capacidades RPC (que será abordado mais deta-
lhadamente durante o aprofundamento do gRPC) motivou uma evolução da tecnologia. Nessa
mesma época havia um conceito criado para interfaces gráficas conhecido como Dynamic Data
Exchange (DDE). Esse protocolo possibilitava que aplicativos que conseguissem trocar dados
via área de transferência em tempo real. Entretando ele foi um início para a tecnologia OLE (Ob-
ject Linking and Embedding), sendo claramente uma evolução do mesmo, possuindo o conceito
de "objetos incorporados"(com eles podendo ser armazenados diretamente no documento ou re-
ferenciados através de links). Isto trouxe uma melhor noção no gerenciamento de documentos.
Porém, devido ao aumento da complexidade e das demandas, percebeu-se que era necessário
um novo modelo de objetos (HENNING, 2008) (THOMPSON et al., 1997). Como resposta a
evolução crescente nos sistemas distribuídos, a Microsoft então desenvolveu o Component Ob-
ject Model (COM), que focava unicamente em documentos, representando a realização prática
das normas presente na tecnologia OLE, onde se estabeleceu uma norma para a comunicação
entre módulos cliente e servidor através de diversas interfaces, por isso, notavelmente os ter-
mos OLE e COM são frequentemente usados de maneira intercambiável. E consequetemente
no futuro o DCOM veio sendo uma evolução dessa última tecnologia citada, mais aprofundado
e com mais possibilidades (THOMPSON et al., 1997).
Além do CORBA, em 97 surge na palaforma Java, o Java Remote Method Invoca-
tion (RMI). Essa API tem a capacidade de realizar a invocação de objetos em uma Java Virtual
Machine (JVM). Servindo para resolver a complexidade que surgia ao permitir que objetos em
diferentes JVMs se comunicassem entre si, o objetivo era simplificar esse processo fazendo com
que os objetos parecessem estar operando na mesma máquina virtual, mas invocando métodos
de outra. Essa capacidade habilitou os programadores a escreverem código distribuído de ma-
neira nativa e eficiente, o que era um grande salto em termos de desenvolvimento de aplicações
distribuídas (WOLLRATH; RIGGS; WALDO, 1996).
No contexto histórico, a chegada do Java RMI, por estar completamente integrado
à linguagem Java, eliminou a necessidade de uma linguagem de definição de interface separada
 29

(como no caso anterior do CORBA), tornando acessível e reduzindo a complexidade do código

(WOLLRATH; RIGGS; WALDO, 1996). À medida que a demanda por sistemas distribuídos
e aplicações Web continuou a crescer, o Java RMI representou uma ferramenta valiosa para os
desenvolvedores que se dedicaram a linguagem na época (WALDO, 1999).
Em seu funcionamento o RMI serve como um mecanismo que permite a invocação
de métodos ou técnicas por um objeto localizado em uma máquina virtual distinta. A comunica-
ção é possibilitada por dois componentes: stub e skeleton (conceitos que também serão relem-
brados durante menções aprofundadas do REST e gRPC). O stub funciona como uma espécie
de porta (proxy) no lado do cliente, encaminhando todos os aplicativos de saída e representando
o objeto remoto, quando um método é invocado nele, um conjunto de operações é iniciado. O
stub estabelece uma conexão com a JVM remota, codifica e envia os parâmetros para ela. Em
seguida, ele aguarda um retorno, decodifica o valor ou a exceção retornada e, finalmente, en-
trega esse valor ao solicitante. Por outro lado, o skeleton desempenha um papel semelhante no
lado do servidor, agindo como um gateway para o objeto remoto. Ao receber uma solicitação, o
skeleton decodifica o parâmetro do método remoto e invoca o método no objeto remoto autên-
tico. Posteriormente, codifica e envia o resultado para o chamador (KNOWLEDGEHUT, 2020)
(GROSSO, 2001).

Figura 7 – Funcionamento do Java RMI

Fonte: (KNOWLEDGEHUT, 2020)

2.3.5 XML e SOAP: Troca e Armazenamento de Dados Estruturados na Web e Interope-

rabilidade entre Aplicações Distintas Através de Redes

No final dos anos 90 surgiu o XML (Extensible Markup Language), estabelecendo

um padrão para a marcação de documentos, prescrevendo uma sintaxe universal que emprega
tags simples e compreensíveis ao ser humano para marcar os dados. De maneira mais detalhada
é uma versão "leve"do SGML lançado em 98, que foi prontamente adotado por muitos desenvol-
vedores que precisavam de uma linguagem de marcação estrutural, mas não conseguiam lidar
 30

com a complexidade do antigo padrão. Logo após vieram outros padrões que enriqueciam o
XML, vale destacar o Extensible Stylesheet Language (XSL), que permitia a transformação de
documentos em um formato que pudesse ser visualizado em navegadores da Web (BAX, 2001)
(HAROLD; MEANS, 2004).
O XML apresenta um formato padrão para documentos digitais que demonstra uma
flexibilidade suficiente para ser adaptado a uma vasta gama de domínios (websites, serialização
de objetos, chamadas de procedimento remoto e outros) (W3C, 2016) (HAROLD; MEANS,
2004). É possível desenvolver programas próprios que interajam e manipulem os dados em
documentos XML, permitindo que a atenção seja direcionada para as necessidades exclusivas
do programa em desenvolvimento (FITZGERALD, 2004).
A especificação XML delimita uma gramática para documentos que estipula onde
as tags podem ser inseridas, como devem ser formatadas, quais nomes de elementos são per-
mitidos, como os atributos são acoplados aos elementos e outros. É importante denotar que um
documento pode ser rejeitado se conter erros de formação (W3C, 2008) (HAROLD; MEANS,
2004). Documentos XML eliminam a necessidade de adivinhar a formatação dos dados, uma vez
que se pode ler diretamente os nomes das tags para entender o que está no documento, todos os
detalhes importantes sobre a estrutura do documento são explícitos (BAX, 2001) (HAROLD;
MEANS, 2004).
O XML possibilita a transferência de documentos e dados de um sistema para outro,
esperando que o sistema de recepção seja capaz de interpretá-los. Ademais, a validação permite
que o receptor verifique se recebeu o que esperava (HAROLD; MEANS, 2004).
Regras mais específicas sobre exatamente quais elementos e atributos são permi-
tidos e onde, são normalmente ditadas por aplicações XML individuais, mas algo que todas
tendem a necessitar em comum é o analisador de validação. Esse validador, é uma ferramenta
usada para verificar se um documento está bem formado e segue um determinado esquema. Se
um analisador de validação (verificação de um documento em relação a um esquema) encontrar
um erro de validade, ele o reportará à aplicação em cujo nome está analisando o documento.
Esta aplicação pode então decidir se deseja continuar analisando o documento (erros de vali-
dade não são necessariamente fatais, diferentemente dos de formação) e uma aplicação pode
optar por ignorá-los (HAROLD; MEANS, 2004) (BOURRET, 2005).
A aplicação que recebe os dados do analisador pode ser um navegador da Web, um
processador de texto, um banco de dados, uma planilha, um programa escrito por um desenvol-
 31

vedor independente, entre muitos outros (HAROLD; MEANS, 2004) (BOURRET, 2005).
Na mesma época do XML surgiu o Protocolo de Acesso a Objetos Simples (Sim-
ple Object Access Protocol - SOAP). Sendo um protocolo de troca de mensagens padronizado
que permite a comunicação entre aplicações através de redes (W3C, 2000). A tecnologia ra-
pidamente evoluiu, tornando-se um padrão de fato para a troca de informações em ambientes
distribuídos, e eventualmente foi adotado como um padrão pela W3C. A principal motivação por
trás do desenvolvimento do SOAP foi a necessidade de normas de comunicação padronizadadas
que permitissem a interoperabilidade entre diferentes sistemas. Essa necessidade era evidente
à medida que a Internet crescia e se tornava mais complexa, com uma multiplicidade de sis-
temas operacionais, linguagens de programação e protocolos de rede. Nos anos 2000, o SOAP
foi amplamente utilizado na construção de serviços da Web e na implementação de arquitetu-
ras orientadas a serviços (SOA, abordada na próxima seção). Ele permitia a comunicação entre
diferentes sistemas e linguagens de programação usando o XML como meio de codificação de
mensagens (W3C, 2000) (W3C, 2007).
O SOAP não estabelece, por si só, quaisquer semânticas específicas de aplicativo
ou de implementação. Em contrapartida, determina um método simplificado para expressar as
semânticas da aplicação, ofertando um modelo de embalagem modular e técnicas de codificação
para a inserção de dados nesses módulos. O protocolo apresenta três partes fundamentais (W3C,
2000) (W3C, 2007) (IBM, 2021b):

1. Estrutura do envelope: define um corpo geral para a expressão do conteúdo de uma

mensagem, o destinatário e se ela é de caráter opcional ou obrigatório;

2. Regras de codificação: delimita um mecanismo de serialização aplicável à troca de

instâncias de tipos de dados definidos pelo aplicativo;

3. Representação SOAP RPC: estabelece uma convenção para a representação de chama-

das e respostas de procedimentos remotos. Além do envelope, das regras de codificação
e das convenções RPC, esta especificação também define dois vínculos de protocolo que
explicam como uma mensagem SOAP pode ser transportada via mensagens HTTP.

Um aplicativo SOAP que recebe uma mensagem deve processar essa mesma se-
guindo os seguintes passos em sequência de maneira básica, evitando especificidades (W3C,
2000) (W3C, 2007) (IBM, 2021b):

1. Identificação de todos os segmentos da mensagem dirigidos a este aplicativo;

 32

2. Confirmação se todas as partes essenciais identificadas no passo 1 são suportadas pelo

aplicativo para essa mensagem específica e as processe apropriadamente, caso contrário,
a mensagem deve ser descartada;

3. O processador pode ignorar as partes opcionais identificadas na etapa 1 sem alterar o

resultado do processamento.

2.3.6 SOA: Estímulo do Design Modular e Interoperabilidade em Sistemas de Computa-

ção

O protocolo de Arquitetura Orientada a Serviços (Service-oriented architecture -

SOA) merece uma análise mais aprofundada no contexto da orquestração de sistemas devido ao
seu profundo significado e abordagem abrangente para estruturar e conectar componentes de
software. Os motivos do porque isso se faz é necessário é que o SOA é um paradigma de design
e um estilo de arquitetura que estrutura os aplicativos como uma coleção de serviços fracamente
acoplados. Ao contrário de outras tecnologias apresentadas, ele traz um nível totalmente novo de
facilidade na gerência de complexidade, melhora na flexibilidade e na promoção de reutilização.
Os serviços nesse protocolo são independentes de plataforma e se comunicam entre si por meio
de uma rede, oferecendo um nível de interoperabilidade que é particularmente vital nos cenários
tecnológicos distribuídos e heterogêneos de hoje. Além disso, os princípios do SOA têm sido
fundamentais para possibilitar estilos arquitetônicos modernos, como microsserviços. Portanto,
aprofundar o SOA não apenas fornece informações sobre esse protocolo específico, mas também
elucida conceitos mais amplos que sustentam a orquestração de sistemas (PENNINGTON et al.,
2007) (IBM, 2019).
As arquiteturas de objetos distribuídos surgidas na década de 1990, como Java RMI
e DCOM, tinham várias limitações, incluindo restrições à plataforma. Além disso, havia di-
ficuldades significativas na integração de aplicativos distribuídos desenvolvidos em diferentes
linguagens, uma questão ainda de grande importância para os executivos de tecnologia da in-
formação. Assim, com o objetivo de lidar com as limitações dessas arquiteturas mais antigas, o
SOA emergiu no início dos anos 2000, promovendo uma estratégia que simplifica o desenvolvi-
mento e combinação de serviços modulares, que podem ser integrados e reutilizados facilmente
para criar aplicações distribuídas (PENNINGTON et al., 2007) (IBM, 2019).
Nesse início dos anos 2000, também, muitas organizações já experimentaram as
vantagens de usar XML para representar dados para trocas de informações baseadas na Web
 33

(como comunicações B2B). Comunicações B2B (business-to-business), se referem à troca de

informações e serviços entre duas ou mais empresas, utilizando tecnologias e plataformas como
sistemas de troca de dados eletrônicos (EDI, APIs, e serviços de mensagens). No entanto, as
organizações perceberam que suas estratégias levaram ao desenvolvimento de soluções arqui-
tetônicas que muitas vezes exibiam um forte acoplamento entre os aplicativos de software in-
terativos, o que limitava a flexibilidade e a adaptação dinâmica dos sistemas de TI. Como re-
sultado e para superar essas limitações, o conceito de arquitetura orientada a serviços (SOA)
foi introduzido e definiu um método de projetar, desenvolver, implantar e gerenciar serviços
(PENNINGTON et al., 2007) (IBM, 2019).
Um acoplamento fraco implica que cada serviço tem uma independência relativa e
não necessita conhecer detalhadamente os funcionamentos internos dos outros serviços. Esta
abordagem é vantajosa por permitir maior escalabilidade, uma vez que os serviços podem ser
ajustados individualmente de acordo com a demanda. Além disso, proporciona flexibilidade, já
que modificações em um serviço não requerem alterações em outros, desde que a API perma-
neça inalterada. Ademais, um sistema baseado em serviços fracamente acoplados pode ser mais
resiliente, porque uma falha em um serviço pode ser isolada e corrigida sem causar a paralisa-
ção completa do sistema. Em comparação, os serviços fortemente acoplados tendem a ter maior
interdependência, o que pode levar a desafios. Por exemplo, alterações em um serviço podem
exigir mudanças em muitos outros, tornando o sistema mais difícil de manter e evolui, além
disso, um problema em um serviço pode ter um efeito cascata, potencialmente levando a uma
falha em todo o sistema. Dito isso, existem cenários onde o acoplamento forte pode ser neces-
sário ou benéfico, como em aplicações de alto desempenho onde a latência é um fator crítico.
Entretanto, no geral, o acoplamento fraco é frequentemente preferido e mais utilizado devido à
sua flexibilidade, escalabilidade e resiliência (PENNINGTON et al., 2007) (IBM, 2019).
Com as informações baseadas anteriormente, uma síntese dos objetivos do SOA é de
alcançar estruturação, baixo acoplamento e padronização da funcionalidade de negócios entre
os aplicativos de software interativos. Dessa forma, definindo uma maneira de tornar os compo-
nentes de software reutilizáveis e interoperáveis por meio de APIs, com esses usando padrões
de interface comuns e um padrão de arquitetura para que possam ser rapidamente incorporados
a novos aplicativos (PENNINGTON et al., 2007) (IBM, 2019).
Ainda atrelado aos serviços em si, eles são expostos usando protocolos de rede pa-
drão (como SOAP/HTTP ou Restful HTTP (JSON/HTTP)) para enviar solicitações de leitura ou
 34

alteração de dados. A governança de serviços controla o ciclo de vida do desenvolvimento e, no

estágio apropriado, os serviços são publicados em um registro que permite aos desenvolvedores
localizá-los rapidamente e reutilizá-los para montar novos aplicativos ou processos de negócios
(IBM, 2019).
Comparando SOA com as abordagens anteriores, é notado diferenças importantes.
O middleware tradicional (tipo de software que reside entre diferentes aplicativos, sistemas ou
serviços, servindo como ponte ou camada intermediária), como os sistemas de objetos distribuí-
dos, se baseia no paradigma cliente-servidor, apresentando um modelo de interação fortemente
assimétrico e se concentrando em protocolos síncronos (com a função principal sendo facilitar a
comunicação e gerenciar as trocas de dados entre sistemas diferentes). Esses sistemas atribuem
interfaces públicas a objetos acessíveis pela rede e suportam a descoberta de objetos baseada
em nomes. No entanto, o middleware orientado a serviços adota um paradigma peer-to-peer,
combina protocolos síncronos e assíncronos e atribui contratos públicos a objetos acessíveis na
rede. Além disso, favorece a descoberta de serviços baseada em capacidade, e reforça a necessi-
dade de padronização dos protocolos de interação e contratos para garantir a interoperabilidade
e seleção correta de contratos (PENNINGTON et al., 2007) (IBM, 2019).
Dentro de uma SOA, três ações estão comumente associadas a um serviço (PEN-
NINGTON et al., 2007) (IBM, 2019):

1. Descoberta: localização do serviço que oferece a funcionalidade necessária;

2. Requisição: entrada para o serviço;

3. Resposta: saída do serviço.

Assim, pode-se concluir que uma SOA deve envolver três atores principais: o solicitante, o pro-
vedor e o registro. Esse processo começa quando o provedor de serviços publica a descrição do
serviço da Web (WSD) e a semântica no registro. Em seguida, o solicitante do serviço descobre
esse serviço (PENNINGTON et al., 2007) (IBM, 2019).
Uma vez que o WSD e a semântica são aceitos e carregados por ambos os parti-
cipantes, eles podem interagir para realizar a operação necessária. Um provedor de serviços
pode desenvolver e implementar um ou mais serviços Web, cada um dos quais deve conter ao
menos uma operação, chamado também de endpoint, já que é a parte do serviço que realiza o
processamento (PENNINGTON et al., 2007) (IBM, 2019).
 35

Sendo assim, atualmente, SOA é um tema de grande relevância. Essa arquitetura

demanda a existência de componentes e conceitos-chave, tais como serviços, descrições de ser-
viços, parâmetros e limitações de segurança dos serviços, publicidade e descoberta, bem como
contratos de serviços para a implementação de sistemas distribuídos. Frequentemente, há uma
associação entre SOA e serviços Web, por vezes até confundindo ambos, porém, não significam
necessariamente a mesma coisa. De fato, os serviços Web podem ser considerados como uma
implementação específica de SOA, que engloba os principais aspectos de uma abordagem de
arquitetura orientada a serviços (PENNINGTON et al., 2007) (IBM, 2019).
Com serviços Web (que avançaram significativamente em direção ao objetivo da
SOA), os desenvolvedores não precisam entender o funcionamento de um programa remoto,
basta conhecer a entrada necessária, a saída fornecida e como invocá-lo para execução. Eles
estabelecem padrões e especificações que criam um ambiente propício para o design, execução
e composição de serviços em processos, a fim de realizar tarefas complexas. O progresso alcan-
çado conforme os avanços resultou no desenvolvimento de novas especificações que detalham
como novos serviços podem estabelecer comunicações seguras, definir políticas de interação de
serviços e estabelecer regras de confiança entre os serviços (PENNINGTON et al., 2007) (IBM,
2019).

2.3.7 Microsserviços, Serverless e Outros Atuais

Em 2010, à medida que os sistemas se tornaram maiores e mais intrincados, novas

formas de gerenciar essa complexidade tornaram-se necessárias. Antes dos microsserviços, a
maioria dos sistemas era projetada usando uma arquitetura monolítica. As arquiteturas mono-
líticas foram o padrão por muito tempo porque eram fáceis de desenvolver, testar e implantar
(relembrando o que já foi citado). No entanto, à medida que os aplicativos cresciam, as limi-
tações dessa abordagem começaram a surgir. Todo o aplicativo precisava ser dimensionado,
mesmo que apenas uma parte dele exigisse mais recursos. Da mesma forma, atualizações ou al-
terações exigiam a reimplantação de todo o aplicativo, o que poderia ser demorado e arriscado
(LEWIS; FOWLER, 2014).
A arquitetura de microsserviços evoluiu como uma abordagem mais refinada da
arquitetura orientada a serviços. Essa abordagem divide ainda mais o aplicativo em serviços
menores e implantáveis de forma independente que se comunicam por meio de APIs simples,
geralmente por HTTP usando protocolos como REST e gRPC. Cada microsserviço é responsá-
 36

vel por uma única capacidade de negócios e pode ser desenvolvido, implantado e dimensionado
de forma independente (NEWMAN, 2022).
Os microsserviços trazem muitos benefícios, incluindo maior agilidade, resiliência
e escalabilidade, além de melhor alinhamento com as práticas de DevOps. No entanto, eles
também introduzem novas complexidades em áreas como coordenação de serviços, consistência
de dados e latência de rede, que exigem um design cuidadoso e ferramentas sofisticadas para
gerenciar (RICHARDSON, 2018).
Os microsserviços foram adotados por muitas empresas de grande escala e desem-
penharam um papel fundamental ao permitir que essas empresas dimensionassem seus sistemas
e organizações para suportar um alto ritmo de inovação. Os microsserviços continuam a evo-
luir, com as tendências atuais focadas em arquiteturas serverless, malhas de serviço e projetos
orientados a eventos. Falando da tecnologia serverless, embora esse termo "sem servidor"possa
sugerir a ausência, ele se refere à abstração de servidores para que os desenvolvedores pos-
sam se concentrar em escrever código sem se preocupar com a infraestrutura subjacente (IBM,
2021a).
Historicamente, as organizações precisavam comprar, instalar e manter seus pró-
prios servidores físicos. Com o advento das máquinas virtuais foi permitido a abstração de
servidores físicos em vários servidores virtuais rodando no mesmo hardware físico. Isso le-
vou a uma melhor utilização dos recursos, mas o gerenciamento de VMs ainda envolvia uma
sobrecarga considerável (BALDINI et al., 2017).
A introdução da computação em nuvem e da infraestrutura como serviço (IaaS)
permitiu que as organizações alugassem recursos de computação de provedores de nuvem. Em-
bora a IaaS tenha removido a necessidade de manutenção de hardware físico, ela ainda exigia o
gerenciamento e dimensionamento de servidores (BALDINI et al., 2017). A plataforma como
serviço (PaaS) representou o próximo passo, abstraindo o sistema operacional e o ambiente de
tempo de execução. No entanto, os desenvolvedores ainda precisavam considerar como dimen-
sionar seus aplicativos e garantir a disponibilidade de recursos suficientes (ROBERTS, 2018).
A computação sem servidor, geralmente chamada de Function as a Service (FaaS), surgiu por
volta de 2014 e eliminou completamente a necessidade de gerenciar servidores. Os desenvol-
vedores podem simplesmente carregar seu código e a plataforma sem servidor aloca automa-
ticamente os recursos necessários, dimensiona o aplicativo e cobra apenas pelo tempo real de
computação usado (HELLERSTEIN et al., 2018).
 37

3 FUNDAMENTAÇÃO TEÓRICA II: APROFUNDAMENTO NO HISTÓRICO, LÓ-

GICA E FUNCIONAMENTO BASE DO GRPC E REST

O objetivo deste capítulo é de aprofundar e explorar minuciosamente nas tecnolo-

gias que serão base de estudo neste trabalho: Representational State Transfer (REST) e gRPC
Remote Procedure Call (gRPC). As próximas seções não só se comprometem a apresentar
o funcionamento intricado de ambos, mas também traçar um contraste meticuloso entre suas
abordagens para orquestrar um sistema, destacando as diferenças significativas na lógica e na
implementação que cada um deles oferece. Esta análise enriquecerá a compreensão de como
estas duas tecnologias moldam a atual paisagem da computação distribuída.
Reforçando informações apresentadas na introdução, a comparação (forças, fraque-
zas e caso de uso) entre as tecnologias REST e gRPC na orquestração de sistemas é fundamental,
guiada pela sua adoção e relevância na indústria. O REST, conhecido por sua abordagem base-
ada em recursos e compatibilidade com várias tecnologias, é o padrão atual para APIs Web. Por
outro lado, o gRPC é uma tecnologia emergente que suporta streaming de dados bidirecional e,
com a utilização do Protocol Buffers, promove uma melhor interoperabilidade entre diferentes
linguagens de programação. O contraste entre as abordagens do REST, que é stateless, e do
gRPC, que emprega o modelo stateful de chamada RPC, cria contextos interessantes para aná-
lise. Além disso, o gRPC, mesmo ainda ganhando espaço no mercado, pode indicar tendências
atuais e futuras para a adoção de tecnologias e de API atuais (MICROSOFT, 2023b).
Ao explorar os detalhes do REST e gRPC, este estudo se apropria da noção de "es-
tado da arte", um termo que se refere à avaliação crítica e aprofundada do mais alto nível de
desenvolvimento de um campo, neste caso, das mencionadas tecnologias. Com o propósito de
entender e destacar o avanço e a sofisticação alcançados por elas, a análise presente neste tra-
balho contempla não apenas a descrição de suas funcionalidades, mas também a comparação
meticulosa de suas implementações e abordagens para a orquestração de sistemas. Esta investi-
gação, portanto, tem a intenção de contribuir para um estado da arte, agregando uma compilação
de informações atualizadas e relevantes para a literatura existente, potencialmente útil para pes-
quisadores e profissionais, além de identificar possíveis lacunas que poderiam ser abordadas em
futuras pesquisas.
 38

3.1 REST: ESTILO ARQUITETÔNICO PARA APLICAÇÕES EM REDE

O termo REST (Representational State Transfer) concebido em 2000, trouxe como

conceito um estilo arquitetônico que delineava várias restrições que, quando seguidas, poderiam
levar a uma sistema mais eficiente e escalável. O REST representou uma mudança significativa
em relação às arquiteturas tradicionais de serviços da Web como por exemplos os protocolos
SOAP, que geralmente exigiam uma grande quantidade de metadados e uma estrutura mais
complicada, além de estarem fortemente ligados ao formato de dados XML, que, embora versá-
til e altamente estruturado, era prolixo e difícil de usar (BLOG, 2016) (NEUMANN; LARAN-
JEIRO; BERNARDINO, 2021) (SURWASE, 2016).
O REST é centrado no conceito de recursos identificados por URLs (Localizador
Uniforme de Recursos, significando o endereço Web) e é manipulado usando métodos HTTP
padrão, como GET, POST, PUT e DELETE. Essa simplicidade tornou esses aplicativos mais fá-
ceis de entender, projetar, implementar e usar, levando à uma rápida adoção. Na mesma época, o
formato de dados JSON (JavaScript Object Notation) também estava se tornando cada vez mais
popular, considerado um formato leve de intercâmbio de dados baseado em texto, sendo proje-
tado para dar facilidade de leitura e escrita para humanos, e fácil para as máquinas analisarem
e gerarem dados. O JSON logo se tornou o formato de dados preferido de muitos desenvolve-
dores que constroem aplicativos RESTful devido à sua simplicidade e leveza em comparação
com o XML. A adoção do mesmo foi catalisada pela ascensão do JavaScript como a linguagem
de desenvolvimento Web dominante, e o fato desse formato de dados ser entendido nativamente
pelo JavaScript tornou-o o parceiro perfeito para REST na criação de aplicativos Web modernos
(MICROSOFT, 2023b) (BLOG, 2016) (NEUMANN; LARANJEIRO; BERNARDINO, 2021)
(SURWASE, 2016). Além de que também com o advento da arquitetura de microsserviços em
meados da década de 2010, o REST consolidou seu lugar como uma tecnologia central para
a construção de aplicativos da Web modernos (BLOG, 2016) (NEUMANN; LARANJEIRO;
BERNARDINO, 2021) (SURWASE, 2016).
No entanto, o aumento no uso da API RESTful também revelou algumas limitações.
Por exemplo, a busca excessiva ou insuficiente de dados era um problema comum porque o
REST normalmente expõe recursos em determinados caminhos predefinidos, levando o cliente
a obter mais ou menos dados do que precisa. Como resposta, foi desenvolvido o gRPC em
2015. Diferentemente do REST, que utiliza caminhos de recursos predefinidos, o gRPC opera
com base em contratos de serviço fortemente tipados que permitem uma definição precisa das
 39

operações e dados necessários, evitando problemas de busca de informações. No entanto, apesar

da crescente adoção do gRPC, o REST permanece como um estilo de arquitetura amplamente
utilizado, graças à sua simplicidade, facilidade de uso, e ao extenso conhecimento e ferramen-
tas disponíveis na comunidade de desenvolvedores (GOOGLE, 2023a) (NEUMANN; LARAN-
JEIRO; BERNARDINO, 2021) (SURWASE, 2016).
Relembrando o que foi mencionado durante a introdução, além do relatório pre-
sente no Postman, a mesma conclusão pode ser tirada de outras plataformas, como por exemplo
do Google Trends que aborda as diferenças em interesse ao longo do tempo dos usuários, com
REST contendo grande parte do interesse em relação ao gRPC. Outro resultado similar, pro-
vando a relevância e de que realmente REST é a arquitetura mais pensada e utilizada para o
desenvolvimento de APIs de uma forma geral (o que acaba corroborando na idea da orquestra-
ção de um sistema) pode ser visto na figura abaixo:

Figura 8 – Popularidade do REST entre Desenvolvedores

Fonte: (RAPID, 2022)

Nela percebe-se que a arquitetura alcançou 69.3% de desenvolvedores da plataforma

afirmando usar em produção. Outras porcentagens soam auto explicativas, com exceção da "atu-
almente em POC". Nesse caso "POC"significando uma "prova de conceito", sendo esta uma
demonstração cujo objetivo é verificar se certos conceitos ou teorias têm potencial para aplica-
ção no mundo real. Essencialmente, ele representa um pequeno exercício para testar uma ideia
ou suposição de design. Nesse caso pode representar testes ou ideias novas e complementares
 40

na arquitetura REST que estão sendo usados, significando como uma boa métrica para tentar
confirmar potenciais avanços futuros na arquitetura.
Agora em relação ao gRPC:

Figura 9 – Popularidade do gRPC entre Desenvolvedores

Fonte: (RAPID, 2022)

Apenas 8.2% dos desenvolvedores afirmam usar em produção, demonstrando ainda

o desconhecimento da tecnologia, além da própria porcentagem de 55.3% de pessoas que con-
sideram não se familiarizar com o mesmo.
Para as seguintes seções, se faz de grande importância entender não só o funcio-
namento do protocolo HTTP, mas também do que exatamente são aplicativos RESTful, para a
compreensão total do funcionamento e lógica dessa arquitetura e sua importância geral e tam-
bém na orquestração de sistemas.

3.1.1 Entendendo sobre o Protocolo HTTP

Desde a sua criação em 1990, o Hypertext Transfer Protocol - HTTP tem servido
como o protocolo de transferência de dados dominante para a Web. Ele representa um conjunto
de protocolos de nível de aplicação baseados em uma lógica de solicitação/resposta sem es-
tado, permitindo uma interação adaptável com sistemas de informação de hipertexto em rede
(MOZILLA, 2023a).
 41

O protocolo proporciona uma interface consistente aos usuários, mascarando os

pormenores da implementação do serviço, independentemente da variedade de recursos dis-
ponibilizados. Por sua vez, os servidores não precisam ter conhecimento da intenção de cada
cliente, tornando possível tratar cada solicitação de forma independente, sem associação a um
cliente específico ou a um conjunto predefinido de passos do aplicativo. Isso não só possibilita
a utilização eficaz de implementações genéricas em uma ampla gama de contextos, mas tam-
bém minimiza a complexidade da interação e favorece a evolução autônoma ao longo do tempo
(RFC, 2022). A definição do protocolo não pode ser baseada no que acontece além da interface,
por isso o que resta a estabelecer é a sintaxe da interação, propósito da mensagem recebida e o
comportamento que se espera dos receptores (RFC, 2022).
Um protocolo ser considerado de "nível de aplicação"envolve sempre comunicação
em aplicações de rede, justamente por definir mensagens (solicitação e resposta) (VERMA,
2022). Um cliente forma mensagens de solicitação que transmitem seus objetivos e direciona
essas mensagens para um servidor de origem reconhecido. Um servidor, por outro lado, aguarda
solicitações, decompõe cada mensagem recebida, compreende a semântica da mensagem em
referência ao recurso de destino designado e responde a essa solicitação com uma ou mais
mensagens de resposta. O cliente examina as respostas recebidas para avaliar se seus objetivos
foram cumpridos, decidindo o curso de ação subsequente com base nos códigos de status e
conteúdo recebidos (MOZILLA, 2023b).

Figura 10 – Componentes e Contexto da Implementação do Protocolo HTTP na Web

Fonte: (MOZILLA, 2023b)

 42

É importante lembrar de que entre o cliente e o servidor existem inúmeras entidades,

chamadas coletivamente de proxies, que realizam diferentes operações e atuam como gateways (
componente de hardware ou software servindo como um ponto de conexão entre dois sistemas
ou redes que usam protocolos de comunicação diferentes) por exemplo. Necessário lembrar
que em contexto reais, há muito mais dispositivos do que apenas um navegador e um servidor
(MOZILLA, 2023b).
Sobre o lado usuário, encontra-se o termo "user-agent", representando qualquer fer-
ramenta que atua em nome do usuário, executado geralmente pelo navegador. Esta é a entidade
que sempre inicia a solicitação para então buscar documentos que representem a página. Sendo
assim, o navegador traduz as instruções em solicitações HTTP e interpreta ainda mais as respos-
tas HTTP para apresentar ao usuário uma resposta clara (MOZILLA, 2023b). Agora quanto ao
lado do servidor Web, por conta de transparência o usuário tende a não ter noção da dimensiona-
lidade do mesmo, podendo ser um conjunto de instâncias de software hospedadas em diferentes
máquinas (MOZILLA, 2023b). Sendo assim por sua arquitetura ser baseada em um modelo
cliente-servidor, juntamente com a possibilidade de anexar cabeçalhos, o protocolo evoluiu em
conjunto com a expansão das funcionalidades da Web. Embora o HTTP/2 (abordado no gRPC)
introduza um nível de complexidade ao encapsular mensagens em quadros para aumentar o de-
sempenho, o formato fundamental das mensagens permaneceu consistente desde o advento do
HTTP/1.0. A simplicidade do fluxo da sessão é mantida, facilitando seu exame e depuração por
meio de um monitor direto de mensagens HTTP.
A próxima seção apresenta agora de fato o funcionamento mais detalhado do pro-
tocolo, suas mensagens e também sobre seus métodos.

[Link] Funcionamento Aprofundado do Protocolo HTTP, Mensagens e Métodos

Essa seção tem como foco abordar o que ocorre a partir do momento em que o
cliente deseja se comunicar com o servidor. A primeira etapa é uma conexão (geralmente TCP:
protocolo responsável por estabelecer uma conexão confiável entre dois pontos em uma rede,
garantindo a entrega ordenada de pacotes de dados de uma origem para um destino) para que
haja o envio da solicitação e do recebimento da resposta. Após a conexão realizada, a mensagem
HTTP é enviada, apresentando geralmente a seguinte estrutura (RFC, 2022):

GET /[Link] HTTP/1.1

User-Agent: curl/7.64.1
 43

Host: [Link]
Accept-Language: en, mi

O texto acima representa um cabeçalho (primeira parte de uma mensagem) de uma

requisição do cliente, realizando uma leitura do canto superior esquerdo até o último sendo o
inferior direito as seguintes informações podem ser encontradas (RFC, 2022):

1. "GET": é o método, define a operação que o cliente quer realizar;

2. "/[Link]": é o URI (Uniform Resource Identifier) do recurso que o cliente deseja

acessar (caminho do recurso);

3. "HTTP/1.1": refere-se a versão do protocolo;

4. "User-Agent: curl/7.64.1": identifica o software do cliente;

5. "Host: [Link]": especifica o domínio de Internet para o qual a requisição

está sendo enviada;

6. "Accept-Language: en, mi": especifica as preferências de idioma do cliente.

Outros cabeçalhos opcionais poderiam compor a mensagem também, além disso, a mensagem
tende a ter um "corpo"baseando-se em outros métodos como o POST (RFC, 2022).
Quanto a resposta enviada pelo servidor, ela apresenta a seguinte estrutura (RFC,
2022):

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 [Link] GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 [Link] GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

Hello World! My content includes a trailing CRLF.

A mensagem acima representa uma resposta do servidor, com a leitura de análise

dela se dando da mesma forma que a requisição do cliente (MOZILLA, 2023b).
 44

1. Primeiro há a versão do protocolo;

2. "200": código de status, um indicativo padrão de que a solicitação foi bem-sucedida

(havendo outros significando diferentes resultados);

3. "OK": a frase de razão associada ao código de status;

4. "Date": data indicando o momento que a resposta foi gerada pelo servidor;

5. Especificação em que tipo de servidor veio a resposta;

6. "ETag: "34aa387-d-1568eb00: identificador único para a versão específica do recurso,

permitindo que o servidor e o cliente saibam se o recurso foi modificado;

7. "Accept-Ranges: bytes": indica que o servidor aceita solicitações de intervalos de bytes

(retomar downloads interrompidos ou streaming de mídia);

8. "Content-Length: 51": informa ao cliente o tamanho, em bytes, do corpo da resposta;

9. "Content-Type: text/plain": informa ao cliente o tipo de mídia do corpo da resposta.

E quanto aos seus principais métodos segue-se (RFC, 2022):

1. GET: transfere uma representação atual do recurso de destino;

2. HEAD: o mesmo que GET, mas não transfere o conteúdo da resposta;

3. POST: executa o processamento específico do recurso no conteúdo da solicitação;

4. PUT: substitui todas as representações atuais do recurso de destino pelo conteúdo da

solicitação;

5. DELETE: remove todas as representações atuais do recurso de destino;

Faz-se de extrema importância entender que qualquer serviço da Web definido por
HTTP não é REST. E o REST pode ser implementado usando HTTP e também de outros proto-
colos da camada de transporte (SURWASE, 2016).

3.1.2 Funcionamento do REST

Esse estilo arquitetônico possui uma série de restrições: interface uniforme, sem
estado, armazenável em cache ("cacheable"), cliente-servidor, sistemas em camadas e código
sob demanda ("code on demand") (SURWASE, 2016).
A interface uniforme estabelece a conexão entre o usuário do serviço e o provedor
do serviço. Solicitações se baseiam em recursos individuais que são reconhecidos através de
 45

URIs atuando como identificadores de recursos. O cliente obtém a representação do recurso

juntamente com metadados adicionais que sejam capaz de direcionar o cliente para executar
operações adicionais no recurso (SURWASE, 2016).
"Hipermedia como o Motor do Estado do Aplicativo"("Hypermedia as the Engine
of Application State - HATEOAS") é empregada para direcionar a aplicação no lado servidor. O
utilizador da API transmite o seu estado através do corpo da solicitação, parâmetros de consulta,
cabeçalhos e URI. O prestador de serviços transmite o estado da sua aplicação através do corpo
da resposta, códigos e cabeçalhos de resposta (referido como hipermedia ou hiperlinks conti-
dos no hipertexto). Adicionalmente, HATEOAS implica que os links da resposta de serviço são
anexados ao conteúdo da resposta no corpo retornado, permitindo ao cliente obter informações
para construir URIs adicionais para operações subsequentes nos recursos e em outros objetos
na coleção de recursos (SURWASE, 2016).
Ausência de estado significa que todas as informações necessárias para gerenciar a
solicitação estão contidas na própria solicitação, seja como parte do URI, parâmetros da solici-
tação, corpo ou cabeçalhos. O URI identifica unicamente o recurso e o corpo contém o estado
(ou alterações de estado) desse recurso relevante. A partir dessa solicitação, o servidor adquire
o conhecimento do estado do cliente, nisso, uma resposta é gerada com o estado correspondente
e transmitida ao cliente. Dentro da Web, os clientes têm a capacidade de armazenar em cache
as respostas. Portanto, as respostas devem definir-se, de forma implícita ou explícita, como ca-
cheáveis ou não, para prevenir que os clientes reutilizem dados desatualizados ou inadequados
em resposta a solicitações adicionais. O gerenciamento eficaz do cache pode reduzir ou mesmo
eliminar algumas interações entre o cliente e o servidor, aumentando ainda mais a escalabilidade
e a eficiência (SURWASE, 2016).
A interface uniforme estabelece uma divisão entre os clientes e os servidores. Tal
separação implica que os clientes não precisam se preocupar com o armazenamento de informa-
ções, o qual está centralizado em cada servidor, melhorando assim a portabilidade do código do
cliente. Da mesma forma, os servidores não precisam se preocupar com a interface do usuário
ou com o estado do cliente, tornando os servidores mais simplificados e escaláveis (SURWASE,
2016).
O usuário de uma API estruturada em camadas, normalmente, não consegue dis-
cernir se está conectado diretamente ao servidor principal ou a um intermediário durante o
processo. Servidores intermediários podem aprimorar a escalabilidade do procedimento, habili-
 46

tando o balanceamento de carga e proporcionando caches compartilhados (SURWASE, 2016).

Os servidores têm a capacidade de expandir temporariamente ou personalizar a fun-
cionalidade de um cliente através do envio de lógica executável (levando a opções conhecidas
como Código sob Demanda) (SURWASE, 2016).

3.1.3 Definição de uma API REST empregada na Web

Tendo uma contextualização mais concreta da lógica por trás da arquitetura REST e
também do que é uma API é possível entender mais facilmente elementos que tangem uma API
REST (SURWASE, 2016).
A API REST descreve um conjunto de recursos. O cliente HTTP usa um caminho
relativo ao caminho base que identifica o recurso na API REST que o cliente está acessando. Os
caminhos para um recurso podem ser hierárquicos e uma estrutura de caminho bem projetada
pode ajudar a entender os recursos disponíveis. Cada recurso na API REST possui um conjunto
de operações que podem ser chamadas por um cliente HTTP (SURWASE, 2016).
Uma operação em uma API REST tem um nome e um método HTTP. O nome da
operação deve ser exclusivo em todos os recursos nessa API REST. A combinação do cami-
nho e do método HTTP especificados pelo cliente que está fazendo a solicitação é usada para
identificar o recurso e a operação que está sendo chamada (SURWASE, 2016).
Por exemplos o método GET seria responsável pela operação "getX"com o "X"se
referindo a um elemento específico de um banco de dados. O mesmo segue-se para "upda-
teX"com o método PUT e a mesma lógica também para o DELETE (SURWASE, 2016).

3.2 GRPC: FRAMEWORK OPEN-SOURCE PARA CHAMADAS DE PROCEDIMENTO

REMOTO

Essa tecnologia esta se tornando popular porque disponibiliza para todos, como
código aberto, uma década de experiência no Google usando RPC. Sendo assim o gRPC, é
uma implementação específica do RPC, este que é um protocolo mais abrangente destinado a
chamadas de procedimentos remotos, sendo esta sua diferenciação (GOOGLE, 2023b).
Enquanto o RPC adota um formato binário para a transmissão de dados, o gRPC
tem a capacidade de suportar múltiplos formatos de serialização. A compatibilidade do RPC é
extensa, abrangendo uma variedade de plataformas e linguagens de programação, já o gRPC
oferece um suporte mais robusto para linguagens de programação contemporâneas, além do
 47

gRPC usar o protocolo HTTP/2 para estabelecer a comunicação. Quando se trata de eficiência,
o gRPC se destaca pelo uso mesmo protocolo citado anteriormente e também da serialização
binária, além de possuir recursos adicionais não presentes no RPC tradicional: streaming bidi-
recional e streaming no servidor, ampliando ainda mais suas capacidades (MEDIUM, 2023).
O gRPC foi projetado especialmente para serviços em nuvem, mas também fun-
ciona perfeitamente na arquitetura cliente-servidor (sendo versátil e funcional para esses dois
ambientes). Como a arquitetura cliente-servidor já foi abordada é necessário entender um pouco
sobre os serviços em nuvem: a diferença é essencialmente um nível extra de indireção. Isso
significa que o chamador identifica o serviço que deseja invocar e um balanceador de carga
direciona essa invocação para um dos muitos servidores disponíveis processos (containers) que
implementam esse serviço (PETERSON; DAVIE, 2019).
Entendendo nos parágrafos anteriores sobre as diferenças entre o RPC e o gRPC, a
subsequente seção está destinada detalhar o funcionamento de ambos além das particularidades
singulares do gRPC.

3.2.1 Funcionamento aprofundado da técnica RPC

A chamada de procedimento remoto (Remote Procedure Call - RPC) não deve ser
confundida como um protocolo como o REST, sendo mais um paradigma que envolve a trans-
missão síncrona de controle ao nível da linguagem de programação entre softwares em espaços
de endereço distintos, que se comunicam principalmente por um canal de conexão restrito,
sendo uma técnica para construir sistemas distribuídos (NELSON, 1981). Ele permite que um
programa em uma máquina consiga chamar uma sub-rotina em outra máquina sem saber que
ela é remota (funcionando como uma função específica que está sendo chamada). Entretanto
ele também não deve ser confundido como um protocolo de transporte. É um método de usar
os recursos de comunicação existentes de maneira transparente (BIRRELL; NELSON, 1984)
(NELSON, 1981) (TANENBAUM; STEEN, 2007).
É importante notar de que o software aplicativo pode ser projetado e escrito antes
mesmo de se escolher o hardware e protocolos de comunicação específicos que deverão ser
usados, do sistema operacional escolhido e da sequência de chamada necessária para usar o
software de comunicação subjacente. O RPC também é transparente na ordenação de bytes e
diferenças da representação de dados, e é bom salientar que o mesmo não é uma ideia recente
(TANENBAUM; STEEN, 2007). Protocolos de requisição-resposta surgiram no final da década
 48

de 60, enquanto as propostas teóricas para chamadas de procedimentos remotos como o modelo
para operações em rede remontam à década de 70, e as implementações práticas iniciaram no
começo dos anos 80. Entretanto, a atribuição da criação do termo "chamada de procedimento
remoto"foi dada em 1981 (AWRPC, 2016) (NELSON, 1981) (TANENBAUM; STEEN, 2007).
Assim como uma chamada de procedimento local, um RPC é síncrono ou bloque-
ador por natureza, o que significa que o chamador espera até que o procedimento conclua sua
execução e retorne um resultado. Isso torna os RPCs fáceis de entender e implementar, con-
tribuindo para sua popularidade. Parte dessa lógica pode ser encontrada na figura a seguir que
demonstra o funcionamento teórico do RPC (BIRRELL; NELSON, 1984) (GEEKS, 2023):

Figura 11 – Funcionamento RPC entre Cliente e Servidor

Fonte: (EDUCATIVE, 2020)

Simplificando consideravelmente a tarefa do programador de aplicações, o RPC

oculta se o procedimento está ocorrendo localmente ou não. Este mesmo conceito, quando apli-
cado a métodos de objetos remotos em uma linguagem orientada a objetos, é conhecido como
Invocação de Método Remoto (RMI). Apesar da simplicidade da ideia, dois desafios principais
complicam o RPC em relação às chamadas de procedimento locais: primeiramente, a rede entre
o processo de solicitação e o processo requisitado possui características muito mais complexas
do que a infraestrutura de um computador individual, tendo restrições de tamanho de mensagem
e predisposição para perder e reorganizar as mensagens. Em segundo lugar, os computadores
 49

onde os processos requisitante e requisitado são executados podem apresentar diferenças ar-
quitetônicas e formatos de representação de dados diversos (TANENBAUM; STEEN, 2007)
(BIRRELL; NELSON, 1984). Logo, uma estrutura completa de RPC engloba principalmente
dois elementos fundamentais: um protocolo que coordena as mensagens transmitidas entre os
processos cliente e servidor e que gerencia as características potencialmente adversas da rede
base, além disso, há suporte da linguagem de programação e do compilador para compactar
os argumentos em uma mensagem de solicitação no sistema cliente, para depois converter essa
mensagem de volta nos argumentos do sistema servidor, bem como com o valor retornado (GE-
EKS, 2023) (ROSENCRANCE; MATTURRO, 2021) (EDUCATIVE, 2020).
O diagrama a seguir esclarece de maneira simplificada a execução de um RPC:

Figura 12 – Execução do RPC entre Cliente e Servidor

Fonte: (GEEKS, 2023)

 50

Inicialmente, o cliente inicia o processo chamando um stub local (trecho de código

que representa o procedimento remoto), uma espécie de substituto ou intermediário, fornecendo
os parâmetros necessários. Este stub atua como um disfarce para a verdadeira natureza remota
do procedimento, transformando os argumentos em uma mensagem que será encaminhada para
a máquina do servidor através de um protocolo RPC (TANENBAUM; STEEN, 2007) (PETER-
SON; DAVIE, 2019). O stub do cliente é responsável por empacotar os parâmetros. O empa-
cotamento é o processo em que os parâmetros são compactados em uma mensagem adequada
para transporte pela rede. Esse processo inclui a conversão dos parâmetros em um formato pa-
drão (que pode ser tão simples quanto um fluxo de bytes ou um formato de dados estruturados
mais complexos) para garantir que o sistema receptor possa interpretar corretamente os dados,
independentemente das diferenças nas representações internas de dados em diferentes sistemas
(TANENBAUM; STEEN, 2007) (PETERSON; DAVIE, 2019) (GEEKS, 2023).
Na máquina servidora, o protocolo RPC passa a mensagem (parâmetros empaco-
tados em uma mensagem) ao stub do servidor, também conhecido como skeleton. O skeleton
é uma estrutura que desempenha um papel semelhante ao stub, mas no lado do servidor. Ele
descompacta a mensagem em seus argumentos originais para o procedimento (extraindo os pa-
râmetros e convertendo-os de volta em um formato que o servidor entenda) e, em seguida, o
skeleton chama o procedimento de servidor desejado usando esses parâmetros. O procedimento
do servidor é executado como se fosse uma chamada de procedimento local. Quando a execu-
ção do procedimento do servidor é concluída, ele retorna o resultado para o stub do servidor. O
skeleton então organiza esses valores de retorno em uma mensagem e a passa para a camada de
transporte (TANENBAUM; STEEN, 2007) (PETERSON; DAVIE, 2019) (GEEKS, 2023).
Quando o procedimento no servidor é finalizado, ele produz uma mensagem de
resposta que é entregue ao protocolo RPC para ser enviada de volta ao cliente. No lado do
cliente, o protocolo RPC passa essa mensagem ao stub do cliente. O stub do cliente, então,
converte essa mensagem de volta em um valor de retorno que é enviado ao programa cliente
(PETERSON; DAVIE, 2019) (GEEKS, 2023).

3.2.2 Especificidades no Funcionamento do gRPC

A filosofia fundamental do gRPC gira em torno da definição de um serviço, deter-

minando os métodos que podem ser acionados de forma remota junto com seus argumentos e
retornos. Na parte do servidor, a interface é implementada e um servidor gRPC é ativado para
 51

gerenciar as solicitações do cliente. Por sua vez, o cliente dispõe de um substituto que dispo-
nibiliza os mesmos métodos que o servidor (GOOGLE, 2023b). Os sistemas cliente e servidor
gRPC têm a flexibilidade de operar e interagir em diversos ambientes, desde servidores da Go-
ogle até dispositivos pessoais, e podem ser programados em qualquer uma das linguagens que
o gRPC suporta (exemplo: servidor Java com clientes em Go, Python ou Ruby (GOOGLE,
2023b).
Partindo para as funcionalidades do gRPC. Ele acaba por terceirizar muitos dos
problemas para outros protocolos, deixando para o gRPC de fato, essencialmente, empacotar
esses recursos de uma forma fácil de usar (PETERSON; DAVIE, 2019).
Primeiro, o gRPC é executado sobre TCP em vez de UDP, evitando problemas de
gerenciamento de conexão e transmissão de maneira confiável de mensagens de solicitação.
Ainda quanto a isso é interessante mencionar que o gRPC na verdade é executado em cima
de uma versão segura do TCP chamada Transport Layer Security (TLS), este que garante a
responsabilidade de proteger o canal de comunicação para que não haja espionagem ou se-
questro na troca de mensagens. Em segundo, pelo gRPC ser executado sobre o HTTP/2 outros
dois problemas são sedimentados: codificação/compactação eficiente de dados binários em uma
mensagem, e o outro sendo a multiplexação de várias chamadas de procedimento remoto em
uma única conexão TCP (PETERSON; DAVIE, 2019). A estrutura integral do gRPC é ilustrada
na figura a seguir, que também apresenta seus componentes específicos.

Figura 13 – Estrutura do gRPC

Fonte: (PETERSON; DAVIE, 2019)

 52

Ainda sobre as às características únicas do gRPC. Ele suporta quatro padrões dife-
rentes de solicitação/resposta (PETERSON; DAVIE, 2019):

1. RPC simples: o cliente envia uma única mensagem de solicitação e o servidor responde
com uma única mensagem de resposta;

2. Server Streaming RPC: o cliente envia uma única mensagem de solicitação e o servidor
responde com um fluxo de mensagens de resposta. O cliente conclui assim que tiver todas
as respostas do servidor;

3. Client Streaming RPC: O cliente envia um fluxo de solicitações para o servidor e o

servidor retorna uma única resposta, geralmente (mas não necessariamente) depois de
receber todas as solicitações do cliente;

4. RPC de Streaming Bidirecional: A chamada é iniciada pelo cliente, mas depois disso,
o cliente e o servidor podem ler e gravar solicitações e respostas em qualquer ordem; os
fluxos são completamente independentes.

Essa liberdade extra na forma como o cliente e o servidor interagem significa que
o protocolo de transporte gRPC precisa enviar metadados adicionais e mensagens de controle,
além das mensagens reais de solicitação e resposta, entre os dois pares. Os exemplos incluem
códigos de erro e status (para indicar sucesso ou por que algo falhou), timeouts (para indicar
quanto tempo um cliente está disposto a esperar por uma resposta), PING (um aviso de ma-
nutenção de atividade para indicar que um lado ou outro ainda está execução), EOS (aviso de
fim de fluxo para indicar que não há mais solicitações ou respostas) e GOAWAY (um aviso de
servidores para clientes para indicar que eles não aceitarão mais novos fluxos). O HTTP/2 já in-
clui um conjunto de campos de cabeçalho e códigos de resposta dos quais o gRPC se beneficia
(PETERSON; DAVIE, 2019).
Uma solicitação RPC simples (sem streaming) pode incluir a seguinte mensagem
HTTP do cliente para o servidor(PETERSON; DAVIE, 2019):

HEADERS (flags = END_HEADERS)

:method = POST
:scheme = http
:path = /[Link]/CreateTopic
:authority = [Link]
 53

grpc-timeout = 1S
content-type = application/grpc+proto
grpc-encoding = gzip
authorization = Bearer y235.wef315yfh138vh31hv93hv8h3v
DATA (flags = END_STREAM)
<Length-Prefixed Message>

Neste exemplo, HEADERS e DATA são duas mensagens de controle HTTP padrão. Especifica-
mente, cada linha após HEADERS, mas antes de DATA, é um par atributo = valor que compõe
o cabeçalho. Estes pares que começam com dois pontos fazem parte do padrão HTTP. Quanto
aos pares que não começam com dois pontos, são personalizações específicas do cabeçalho do
gRPC:

1. "grpc-timeout = 1S": indica que a solicitação deve ser cancelada se não for concluída
em 1 segundo;

2. "content-type = application/grpc+proto": o formato dos dados que estão sendo envia-

dos (formato de dados binários compactos usado pelo gRPC);

3. "grpc-encoding = gzip": o tipo de codificação usado para comprimir os dados da men-

sagem. Neste caso, é gzip;

4. "authorization = Bearer y235.wef315yfh138vh31hv93hv8h3v": contém o token de au-

tenticação que o servidor usará para verificar se o cliente tem permissão para fazer a
solicitação.

Isso leva à seguinte mensagem de resposta do servidor de volta ao cliente (PETER-

SON; DAVIE, 2019):

HEADERS (flags = END_HEADERS)

:status = 200
grpc-encoding = gzip
content-type = application/grpc+proto
DATA
<Length-Prefixed Message>
HEADERS (flags = END_STREAM, END_HEADERS)
grpc-status = 0 # OK
 54

trace-proto-bin = jher831yy13JHy3hc

Nesse caso com "grpc-status = 0 # OK" sendo um cabeçalho específico que indica o
status da resposta (processada com sucesso). E quanto ao "trace-proto-bin = jher831yy13JHy3hc",
representa um rastreio binário, utilizado para depuração ou rastreamento da requisição.
Além dessas mensagens, buffers de protocolo são a maneira do gRPC de especi-
ficar como os parâmetros, que estão sendo passados para o servidor, são codificados em uma
mensagem, que por sua vez é usada para gerar os stubs que ficam entre o mecanismo RPC sub-
jacente e as funções reais que estão sendo chamadas. Além da serialização de dados, o protobuf
também serve como uma linguagem de definição de interface (IDL) para serviços gRPC, usado
para definir seus métodos de serviço e tipos de mensagem, e essa definição é usada para gerar
automaticamente o código do cliente e do lado do servidor em vários idiomas, simplificando a
criação de um serviço e cliente gRPC. Um recurso importante do protobuf, também, é o suporte
para evoluir seu formato de dados ao longo do tempo, preservando a compatibilidade com ver-
sões mais antigas do formato de dados, um aspecto crítico ao atualizar os serviços gRPC sem
interromper os clientes existentes (PETERSON; DAVIE, 2019).
Uma vantagem significativa que potencializa a velocidade do protobuf é a distinção
entre contexto e conteúdo. Com formatos como o JSON, o contexto é integrado à mensagem,
como no exemplo a seguir (SANTOS, 2021):

{
"name": "Lucas",
"age": 26
}

Ao converter isto para uma mensagem no formato protobuf, é obtido um arquivo

similar ao seguinte (SANTOS, 2021):

syntax = "proto3";
message Name {
string name = 1;
int32 age = 2;
}
 55

O cabeçalho da mensagem não está incorporado na mensagem em si. Ao invés

disso, há apenas um índice que indica a posição onde o campo em questão deveria se encon-
trar.(SANTOS, 2021). Além dos buffers de protocolo, outro ponto levantado em vantagem ao
gRPC é se utilizar do HTTP/2, apresentado na próxima seção.

3.2.3 Entendendo sobre o Protocolo HTTP/2

Este, criado em 2015, começou com a intenção de reduzir a latência de carrega-

mento de uma página da Web usando técnicas como compactação, multiplexação e priorização.
Uma das características mais significativas que distinguem HTTP/1.1 e HTTP/2 é a camada de
framing binário. Ao contrário do HTTP/1.1, que mantém todas as solicitações e respostas em
formato de texto simples, o HTTP/2 usa a camada de enquadramento binário para encapsular
todas as mensagens em formato binário, mantendo a semântica HTTP, como verbos, métodos e
cabeçalhos. Uma API de nível de aplicativo ainda criaria mensagens nos formatos HTTP con-
vencionais, mas a camada subjacente converteria essas mensagens em binário. Isso garante que
os aplicativos da Web criados antes do HTTP/2 possam continuar funcionando normalmente ao
interagir com o novo protocolo (ABCOM, 2019).
No protocolo HTTP/2, a camada de enquadramento binário estabelece um único
objeto de conexão entre dois sistemas, comportando diversos fluxos de dados. Cada fluxo inclui
várias mensagens no típico formato de solicitação/resposta, que são subsequentemente subdivi-
didas em unidades menores chamadas de quadros. No nível mais detalhado, o canal de comuni-
cação é composto por vários quadros codificados binariamente, cada um vinculado a um fluxo
específico. As tags de identificação facilitam a intercalação dos quadros durante a transferência
e a reconstrução no ponto de recepção. Este processo de multiplexação permite que solicita-
ções e respostas intercaladas operem paralelamente sem obstruir as mensagens subsequentes,
mitigando o problema de bloqueio na cabeça da fila presente no HTTP/1.1 e permitindo que
servidores e clientes enviem solicitações e respostas concorrentes para um controle e gerencia-
mento de conexão mais eficientes (ABCOM, 2019).
A priorização de fluxos no HTTP/2, ao mitigar possíveis conflitos por recursos e
permitir a personalização do peso das solicitações, abre caminho para a otimização do desem-
penho do aplicativo. Nesse protocolo, a camada de enquadramento binário categoriza mensa-
gens em fluxos de dados paralelos. Quando um cliente envia várias solicitações a um servidor,
ele atribui um peso a cada fluxo (1-256, com um número mais alto indicando maior prioridade)
 56

e estabelece dependências entre os fluxos. A ausência de um fluxo pai atribuído faz com que
um fluxo seja considerado dependente do fluxo raiz. O servidor, ao receber essas informações,
cria uma árvore de dependência que direciona a ordem de recebimento de dados pelas solici-
tações. A alocação de recursos leva em consideração o peso dos fluxos e suas dependências.
Por exemplo, se o fluxo 1 é dependente do fluxo raiz e não há outros fluxos derivados da raiz,
todos os recursos disponíveis são alocados para o fluxo 1 antes dos demais. Os desenvolvedores
têm a liberdade de definir os pesos das solicitações com base nas necessidades específicas do
aplicativo, como priorizar a carga de uma imagem em miniatura sobre uma de alta resolução em
uma página da Web. Além disso, o HTTP/2 permite ao cliente alterar dependências e reatribuir
pesos em tempo real, em resposta à interação do usuário, embora um servidor possa ajustar as
prioridades se um fluxo estiver bloqueado para acessar um recurso (ABCOM, 2019).
Ferramentas de compactação como gzip têm sido tradicionalmente utilizadas no
HTTP/1.1 para reduzir os dados transportados em mensagens HTTP. No entanto, o segmento
de cabeçalho de uma mensagem sempre é transmitido como texto não criptografado. Este fato
implica que a tensão dos dados não compactados na conexão aumenta com a multiplicação das
solicitações, gerando uma penalidade expressiva para aplicativos Web complexos e dependentes
de API, que exigem diversos recursos e, por consequência, múltiplas solicitações de recursos.
Adicionalmente, a utilização de cookies pode, em algumas ocasiões, inchar os cabeçalhos, in-
tensificando a necessidade de algum tipo de condensação. Como resposta a esse desafio, o
HTTP/2 implementa a compactação HPACK para condensar cabeçalhos. Outro aspecto mar-
cante do HTTP/2 é a habilidade de manipular detalhes com mais eficiência por meio da camada
de enquadramento binário. Isso é observado na compactação de cabeçalho, onde o HTTP/2 pode
isolar os cabeçalhos de seus dados, resultando em um quadro de cabeçalho e um quadro de da-
dos distintos. A ferramenta de compactação própria do HTTP/2, HPACK, pode então condensar
esse quadro de cabeçalho, reduzindo drasticamente seu tamanho (ABCOM, 2019).
Embora o gRPC seja muito promissor, também é importante considerar a comple-
xidade que ele pode introduzir e garantir que seja adequado para o caso de uso antes de optar
por implementá-lo. E é isto que é tratado e analisado na próxima seção.

3.3 PONTOS POSITIVOS E NEGATIVOS: REST E GRPC

Levando em conta sobre o que foi apresentado na composição de ambas as tecnolo-

gias, essa seção apresenta uma síntese de vantagens e desvantagens de cada.
 57

Um dos principais benefícios do REST é sua interface uniforme (que simplifica e

desconecta a arquitetura, permitindo que cada componente evolua independentemente). Além
disso, o mesmo é stateless (o estado do cliente é mantido no lado do cliente e para o servidor,
cada solicitação é processada de maneira independente) que aumenta a confiabilidade e a esca-
labilidade do sistema. O REST também permite que as respostas sejam armazenadas em cache
(cliente e servidor) (MICROSOFT, 2023a). No entanto, há desvantagens como o overhead, já
que o REST usa HTTP, afetando nos dados transmitidos. Cada solicitação vem com cabeça-
lhos e metadados que podem aumentar o tamanho geral dos dados. Ser stateless, também pode
ser uma desvantagem, pelo REST exigir que o cliente mantenha o estado, isso pode resultar
em uma maior transferência de dados se cada solicitação tiver que conter todas as informações
necessárias para o processamento. Como o REST depende do HTTP, que é um protocolo sín-
crono, várias solicitações para recuperação de recursos pode aumentar a latência. Sendo assim,
o REST pode ser menos flexível, pois sua insistência na ausência de estado e na comunicação
por meio de métodos HTTP pode ser limitante para alguns aplicativos que exigem comunicação
em tempo real, transferência de dados binários ou interações mais dinâmicas (MICROSOFT,
2023a).
Agora com relação ao gRPC, em termos de pontos positivos, se destaca pelo seu
alto desempenho. Por ele utilizar o protocolo HTTP/2 para a transferência de dados (dando a
capacidade de transmissão de dados binários, multiplexação, controle de fluxo, e outros recur-
sos) isso reduz a latência e o uso da largura de banda da rede em comparação com o HTTP/1.1.
Além disso, o gRPC é independente de linguagem (suportando várias linguagens de progra-
mação), tornando-o adaptável para diferentes ambientes de sistema (PUNNEN, 2017). Outra
vantagem é o suporte nativo para streaming bidirecional (cliente e servidor trocam uma sequên-
cia de mensagens de maneira independente) mostrando-se útil para, por exemplo, negociações
em tempo real (MICROSOFT, 2023a). Também pode se destacar pela sua geração de código
nativa, eliminando a necessidade de recorrer a ferramentas de terceiros, como é o caso das APIs
REST, que normalmente necessitam do uso de ferramentas como o Swagger para a geração
automática do código para chamadas de API (VERTIGO, 2020). Porém, o gRPC também tem
suas desvantagens. Como sua complexidade pelo uso do Protobuf e suas convenções específi-
cas, tornando a curva de aprendizado mais difícil. Além disso, o suporte e compatibilidade com
navegadores é um ponto fraco por não ser ainda mundialmente aceito. A legibilidade humana e
as ferramentas também são afetadas, não sendo tão legível quanto o REST (com o uso de JSON
 58

ou XML) (MICROSOFT, 2023a).

Sendo assim as APIs REST, são a primeira escolha para integrações de aplicações,
microsserviços e desenvolvimento de serviços Web, pois ao serem disponibilizadas publica-
mente, apresentam cada componente como um recurso acessível através de uma interface que
aceita comandos HTTP. Já APIs gRPC, devido à falta de compatibilidade, são mais utilizadas na
construção de sistemas internos. Apesar disso, são úteis para comunicações de baixa latência e
alta velocidade entre microsserviços (VERTIGO, 2020). É importante mencionar que, para fins
de curiosidade, o gRPC e o REST podem conviver dentro do mesmo projeto. É plenamente pos-
sível adotar uma abordagem híbrida, utilizando o gRPC para, por exemplo, microsserviços que
demandem alto desempenho e optando pelo REST para outras seções do sistema. Essa combina-
ção estratégica permite que se usufrua das vantagens distintas de cada uma dessas tecnologias,
garantindo que os requisitos do projeto sejam cumpridos de maneira eficaz (FACTORY, 2023).
Com essa diferença entre ambos é importante ainda entender o que exatamente en-
volve a orquestração de sistemas. No centro da orquestração do sistema está o conceito de
automação, um processo que se estende além da simples automação de script e no domínio
do gerenciamento de scripts interdependentes em diferentes sistemas (DATABRICKS, 2022)
(PIPEFY, 2023). É aqui que tecnologias como REST e gRPC entram em cena. O REST, com
sua arquitetura sem estado, fornece uma plataforma ideal para criar e gerenciar scripts, per-
mitindo solicitações independentes sem que o servidor precise reter as informações da sessão,
simplificando muito o gerenciamento em sistemas distribuídos (MICROSOFT, 2023b). Por ou-
tro lado, o gRPC oferece suporte a streaming bidirecional e RPCs, permitindo fluxos de trabalho
altamente interativos e em tempo real. Sua capacidade de lidar com solicitações de streaming
pode facilitar orquestrações mais complexas que exigem interação cliente-servidor contínua,
enquanto o uso de Protocol Buffers pode levar a uma comunicação mais eficiente, suportando
assim outros cenários de orquestração mais específicos (MICROSOFT, 2023b). Consequente-
mente, escolher entre essas tecnologias depende dos requisitos específicos do sistema que está
sendo orquestrado.

3.4 ORQUESTRAÇÃO DE SISTEMAS: CONTEXTO HISTÓRICO, DEFINIÇÃO E IM-

PORTÂNCIA

Em essência, a orquestração do sistema envolve a configuração, coordenação e

gerenciamento automatizados de sistemas, aplicativos e serviços de computador (REDHAT,
 59

2019). O termo é frequentemente usado no contexto em que um grande número de máquinas é

necessário para trabalhar em conjunto para fornecer um único recurso de computação unificado
(DATABRICKS, 2022).
Ao contrário da ideia de automação simples, que envolve a automação de tarefas
individuais, a orquestração do sistema geralmente se refere à automação de fluxos de trabalho
inteiros, principalmente quando esses fluxos de trabalho abrangem vários sistemas ou aplicati-
vos (PIPEFY, 2023) (VMWARE, 2023). No contexto da orquestração de sistemas modernos, a
automação serve como o pivô. As ferramentas de automação são usadas para iniciar e gerenciar
fluxos de trabalho em diferentes sistemas, automatizando uma série de ações que são realizadas
com base em regras ou políticas predefinidas (PHOENIXNAP, 2021).
O estudo da orquestração é impulsionado pela necessidade de melhorar o entendi-
mento e a implementação do gerenciamento de sistemas automatizados, uma área que continua
a evoluir e se expandir na atual era tecnológica (DATABRICKS, 2022) (PIPEFY, 2023). A or-
questração, com seus recursos de automação, reduz erros manuais e libera recursos humanos
para tarefas mais complexas. Assim, desenvolve novas estratégias para alcançar maior efici-
ência operacional (PIPEFY, 2023) (PHOENIXNAP, 2021). Também aumenta a confiabilidade
gerenciando e reduzindo falhas em um sistema, ao definir como diferentes componentes de um
sistema interagem e respondem a várias situações, a orquestração ajuda a garantir um compor-
tamento consistente e previsível do sistema (PIPEFY, 2023).

3.5 CORRELATOS: MIGRAÇÃO E PROPOSTAS DE USO PARA GRPC

O primeiro artigo, "Proposta do gRPC como uma Nova API Northbound para Efi-
ciência na Comunicação na Camada de Aplicação em SDN", propõe o uso do gRPC com o
objetivo de melhorar a eficiência da comunicação entre o plano de controle e o plano de dados.
O segundo artigo, "Utilizando Refatoração para Migrar Aplicações REST para gRPC", explora
um método para a transição suave de sistemas baseados em REST para gRPC, procurando uma
melhoria em termos de eficiência de comunicação.
Juntos, esses estudos fornecem uma visão ampla sobre a utilidade e a aplicabilidade
do gRPC em diferentes contextos de sistemas distribuídos.
 60

3.5.1 Primeiro Artigo: Proposta do gRPC como uma Nova API Northbound para Efici-
ência na Comunicação na Camada de Aplicação em SDN

O artigo aborda a implementação acelerada da tecnologia SDN (Rede Definida por

Software), graças ao surgimento do OpenFlow e ao desenvolvimento de controladores de có-
digo aberto por vários fornecedores. Com o aumento da aplicabilidade do SDN em redes de
diferentes tamanhos, a segurança fornecida pela camada de aplicação e middleware existente
tornou-se crucial. Embora o OpenFlow seja amplamente adotado como o padrão para a API
Southbound, a API Northbound ainda carece de um padrão claro, com muitas APIs como REST,
NETCONF, AMQP, Frentic e FML em uso. A API mais utilizada, REST, opera sobre HTTP/1.1
e herda todos os problemas de desempenho associados a este protocolo. Diante disso, o estudo
propõe a adoção do protocolo gRPC, que pode ser executado sobre o HTTP/2.0, como a nova
API Northbound. O uso do gRPC pode ser uma alternativa ao REST para resolver os problemas
existentes em termos de velocidade de comunicação, conveniência do desenvolvedor e segu-
rança na comunicação. Assim, o gRPC surge como uma opção promissora para aumentar a
velocidade da comunicação entre as camadas de aplicação e controle (DU; LEE; KIM, 2018).
Por estabelecer o contexto para a implementação de gRPC em cenários onde o REST
tem sido tradicionalmente utilizado, isso torna possível aplicar as conclusões deste estudo em
um contexto de aplicação da vida real. Assim como o artigo destaca as limitações do REST,
especialmente em termos de desempenho, neste trabalho torna interessante tomar de como es-
sas limitações se aplicam ao ambiente de um aplicativo de comércio eletrônico (podendo ser
continuado em projetos futuros), analisando como a migração para o gRPC pode abordar essas
questões e potencialmente melhorar a eficiência e a segurança na comunicação entre diferentes
serviços em uma plataforma de e-commerce. Consequentemente, este trabalho tende a forne-
cer uma valiosa contribuição qualitativa, verificando especificidades do gRPC no contexto do
comércio eletrônico.

3.5.2 Segundo Artigo: Utilizando Refatoração para Migrar Aplicações REST para gRPC

Pelo artigo fornecer uma metodologia concreta para a migração de aplicações ba-
seadas em REST para gRPC, ele acaba conseguindo contribuir para aprofundamentos de ideias
que visam a eficiência na comunicação e no desempenho das aplicações. Como este trabalho se
concentra na comparação da implementação do gRPC e REST em um aplicativo de comércio
eletrônico, este artigo serve como uma boa referência. Em partes, justamente porque permite
 61

entender a refatoração proposta pelos autores para realizar a transição de REST para gRPC para
possivelmente ter algo implementado para a aplicação de e-commerce. Por conta do artigo abor-
dar a migração, ele traz a oportunidade de avaliar os benefícios e desafios desta transição, mas
levando no contexto do comércio eletrônico em específico. Fornecendo percepções aprofunda-
das em um âmbito específico, englobando, nesse caso, a aplicabilidade dessa estratégia neste
setor (LEE; LIU, 2022).
 62

4 METODOLOGIA DE PESQUISA: ANÁLISE COMPARATIVA DE REST E GRPC

NA ORQUESTRAÇÃO DE SISTEMAS

Este trabalho será desenvolvido em termo de uma comparação sistemática de REST

e gRPC. O processo consistirá na criação de um cenário realista de uso, execução dos testes,
coleta, interpretação dos resultados e conclusão sobre as vantagens relativas de cada tecnologia
nas condições especificadas.

4.1 IDENTIFICAÇÃO DO PROBLEMA E REVISÃO BIBLIOGRÁFICA

O trabalho traz uma definição clara das implementações empregadas em cada tec-
nologia, além do comprometimento em garantir que o cenário reflita condições típicas que os
desenvolvedores podem encontrar na orquestração de sistemas do mundo real. Afim de revisar
não só os tipos de arquitetura levantados ao longo do texto como também as lógicas emprega-
das, abrangendo várias ideias diferentes para a implementação do gRPC comparado ao REST,
aprofundando possibilidades e conhecimento empregado nas tarefas subsequentes.

4.2 CONFIGURAÇÃO

No cenário será aplicado a tecnologia gRPC e comparada quanto ao REST. Cada

ambiente será projetado e configurado para replicar os cenários de uso específicos identificados
na primeira etapa, se baseando em aplicações reais presentes na Web.
A arquitetura de um comércio eletrônico oferece uma plataforma robusta para ex-
plorar muitos recursos e funcionalidades do gRPC e do REST. Ambos podem ser implemen-
tados e utilizados em várias partes do sistema, desde a camada de front-end até o back-end e
a integração com outros serviços. Isso permite uma comparação prática e significativa entre os
dois, com base em critérios relevantes e observáveis. No entanto, vale ressaltar que não será
possível ou prático explorar todos os aspectos do gRPC e REST assim como por exemplos seus
desempenhos (âmbitos quantitativos). Alguns recursos ou funcionalidades podem ser mais re-
levantes para outros tipos de aplicações, ou podem requerer uma implementação que está além
do escopo do projeto de e-commerce.
Por fim, a implementação de uma arquitetura SOA, serverless ou de microsserviços
proporcionará uma visão profunda de como o gRPC e o REST podem ser usados e otimizados
em contextos de produção reais. Será uma oportunidade para aprender mais sobre suas vanta-
 63

gens e desvantagens, e como elas podem ser melhor aproveitadas para melhorar a eficiência e a
experiência.
Uma aplicação de e-commerce pode ser composta pela seguinte série de serviços:

1. Interface do Usuário: implementada com APIs RESTful, pois elas são simples, fáceis
de usar e amplamente suportadas pelos navegadores. Carregando informações de produ-
tos, detalhes de usuários, etc;

2. Back-End: gRPC com seu alto desempenho e baixa latência, é adequado para comuni-
cações internas do sistema, enquanto o REST pode ser usado para interfaces externas;

3. Banco de Dados: REST é ideal para operações simples de CRUD, enquanto gRPC é
melhor para transações complexas e em tempo real;

4. Sistema de Pagamento: processamento de pagamento, REST é normalmente preferido

devido à sua ampla aceitação e fácil integração com provedores de pagamento de tercei-
ros;

5. Sistema de Gerenciamento de Pedidos e Inventário: gRPC pode ser uma escolha me-
lhor devido à sua eficiência e capacidade de streaming em tempo real, que é útil para
rastrear pedidos e estoque.

4.3 TESTE

Será realizada uma série de testes, baseados justamente nos serviços citados anteri-
ormente, visando avaliar arquitetura e funcionalidades do gRPC e do REST na orquestração do
sistema, com possivelmente não só o uso do próprio conhecimento, mas também de possíveis
ferramentas de teste automatizadas (BloomRPC, gRPCurl, Evans, ghz, Taurus e outros).

4.4 COLETA DE DADOS

Durante os testes, será coletado dados sobre o comportamento do REST e do gRPC

(permitindo que haja uma comparação direta com o mesmo tipo de dados). Muito disso será
baseado no levantamento da comparação teórica entre os dois com as seguintes métricas (qua-
litativas) sendo levantadas:

1. A implementação pode ser coletada pela dificuldade e o tempo que leva para imple-
mentar uma funcionalidade específica, como gerenciamento de estoque, usando gRPC.
 64

Isso inclui a escrevita do código, teste e possíveis correções. Quanto ao REST, a lógica
funcionaria similarmente ao gRPC;

2. A arquitetura, com relação ao gRPC e REST, pode-se considerar fatores como a faci-
lidade de escalabilidade, resiliência e o desacoplamento dos componentes do sistema;

3. Para a modelagem será feita a analise a facilidade na eficiência da modelagem dos

dados e dos serviços de e-commerce usando o gRPC. Isso pode envolver a avaliação da
complexidade do esquema de dados e a facilidade de evolução do esquema ao longo
do tempo. Para o REST, similarmente, você pode avaliar a modelagem dos dados e dos
serviços usando REST, com foco na simplicidade do esquema de dados e na facilidade de
integração com outras plataformas;

4. Quanto a organização interna, isso engloba a organização do código e a estrutura do

projeto ao usar gRPC ou REST. Isso inclui a modularidade do código, o padrão de design
adotado, a facilidade de manutenção e atualização do código, entre outros.

Esses dados serão coletados ao longo do tempo e em várias iterações do desenvol-

vimento, fazendo-se especificamente também do uso de ferramentas específicas para destacar
as especificidades do gRPC como o BloomRPC, gRPCurl, ghz, e outros.

4.5 ANÁLISE

Baseado nos dados levantados, isso envolverá a identificação de quaisquer dife-

renças significativas entre ambos. Também será considerado os aspectos qualitativos, como a
facilidade de implementação, a arquitetura, modelagem e organização interna com diferentes
sistemas e o suporte a recursos avançados. Uma tabulação inicialmente levantada para auxiliar
na análise pode ser encontrada a seguir:
 65

Métricas gRPC REST

(Implementação) Facilidade de implementação
Correção de problemas
(Arquitetura) Resiliência
Desacoplamento dos componentes
(Modelagem) Facilidade na modelagem de dados
Eficiência na modelagem dos serviços
Complexidade no esquema de dados
Facilidade da evolução do esquema
(Organização interna) Modularidade de código
Padrão de design adotado
Facilidade de manutenção
Facilidade de atualização do código

Além disso é interessante mencionar um levantamento de ferramentas necessárias

para corroborar na construção da análise:

1. IDEs e Editores de Texto: Ferramentas como Visual Studio Code, que suporta diversas
linguagens de programação e possui plugins para suporte ao gRPC e REST;

2. Diagramas de Arquitetura: Ferramentas de desenho para construir a arquitetura do

sistema;

3. Ferramentas de Modelagem de Dados (APIs REST e APIs gRPC);

4. Sistemas de Controle de Versão: Git para gerenciar o código e o histórico de mudanças.

E de adicional ainda possivelmente ferramentas de análise de código.

4.6 COMPARATIVO

Por fim, serão vistas as vantagens relativas de cada uma das tecnologias na orques-
tração do sistema, com base nos resultados dos testes e análise. Prevendo que, potencialmente,
a escolha indicará que depende do cenário de uso específico.
É importante observar que os resultados do estudo serão influenciados pelas con-
dições específicas dos testes. Portanto, baseando-se nessa previsão de dualidade (dependendo
da intenção e planejamento dos desenvolvedores) eles podem não ser diretamente aplicáveis a
todos os cenários ou ambientes possíveis.
 66

4.7 ORÇAMENTO

Este estudo e análise comparativa entre REST e gRPC, utilizando como base a im-
plementação de uma aplicação de comércio eletrônico com uma arquitetura específica levantada
(SOA, serverless ou microsserviços), não implicará em necessidade de recursos financeiros. As
tecnologias e ferramentas a serem utilizadas estão amplamente disponíveis de forma gratuita
e/ou de código aberto. A análise será conduzida inteiramente com base em critérios técnicos e
práticos, sem a necessidade de quaisquer investimentos financeiros adicionais.

4.8 CRONOGRAMA

Seguindo um cronograma estruturado, haverá respectivamente o planejamento do

sistema de e-commerce. Seguido pela implementação do sistema com o estilo arquitetônico,
posteriormente a fase de testes e comparação das abordagens. Por fim, será dedicado à consoli-
dação das descobertas e preparação da documentação final.

Divisão de atividades Julho Agosto Setembro Outubro Novembro Dezembro

Revisão bibliográfica X X
Modelagem da aplicação (escolha de arquitetura e serviços) X X X
Desenvolvimento da aplicação X X X X
Coleta e levantamento dos resultados X X
Análise comparativa dos resultados X X
Escrita X X
Apresentação X
 67

5 CONCLUSÃO

Na avaliação dos paradigmas REST e gRPC na orquestração de sistemas, é funda-

mental considerar o impacto potencial de cada um em um ambiente de comércio eletrônico.
Com a implementação do gRPC e comparação de tecnologias empregadas no REST, espera-se
obter uma maior eficiência na comunicação entre os diferentes componentes do sistema, me-
lhorando assim a experiência geral do usuário e a escalabilidade da plataforma.
O REST, sendo um estilo arquitetônico simples e de fácil entendimento, com ampla
adoção e suporte, torna-se apropriado para cenários onde a interoperabilidade e a facilidade de
integração com sistemas de terceiros são cruciais. Sua natureza orientada a recursos e estado
sem servidor é ideal para situações que requerem escalabilidade e evolução independentes dos
serviços.
Já o gRPC, com sua eficiência em termos de suporte a vários idiomas, é particu-
larmente útil para comunicações internas do sistema, onde a latência baixa e o alto rendimento
são essenciais. Ele é ideal quando há uma necessidade de comunicação ponto a ponto rápida
entre microsserviços, especialmente em operações complexas que exigem múltiplas chamadas
de serviço.
Além de fornecer subsídios valiosos para a adoção do gRPC na orquestração de
sistemas em determinados parâmetros analisados, este estudo abre caminho para uma compre-
ensão mais aprofundada de como estas duas abordagens podem ser efetivamente usadas no
domínio do comércio eletrônico. Além disso, ele ilumina os desafios específicos e as considera-
ções importantes ao fazer a transição de REST para gRPC em uma aplicação prática. Contudo,
é importante ressaltar de que a escolha entre REST e gRPC não precisa ser mutuamente exclu-
siva. Em um site de comércio eletrônico, por exemplo, o REST pode ser usado para interfaces
de usuário Web e móveis devido à sua natureza baseada em texto e facilidade de uso, enquanto o
gRPC pode ser empregado para comunicação eficiente entre os microsserviços em backend. As-
sim, a recomendação seria adotar uma abordagem híbrida que aproveite as vantagens distintas
de ambos os paradigmas, adaptando-os às necessidades específicas do sistema de e-commerce
em questão.
Este trabalho também contribui significativamente para a literatura acadêmica e téc-
nica na área de desenvolvimento de sistemas, apresentando uma avaliação direta e abrangente
das duas tecnologias. Espera-se que essa análise ajude nas escolhas dos desenvolvedores para
 68

orquestração, com base em parâmetros tangíveis, de acordo com as necessidades específicas de

seus projetos.
Com relação aos resultados, é de se esperar que este estudo não apenas destaque os
pontos fortes e fracos do gRPC e do REST no contexto específico de um aplicativo de comér-
cio eletrônico, mas que também forneça concepção sobre os possíveis desafios e soluções ao
utilizar-se de um em relação ao outro. Este trabalho tem o potencial de servir como um guia
valioso para a implementação do gRPC em ambientes de comércio eletrônico, potencialmente
levando a melhorias na eficiência desses sistemas.
 69

REFERÊNCIAS

ABCOM. HTTP/1.1 vs HTTP/2: What’s the Difference? 2019. Disponível em: <https:
//[Link]/community/tutorials/http-1-1-vs-http-2-what-s-the-difference>.
ADEPTIA. What Is EDI? An Insanely Complex Relic of the 1970s. 2015. Disponível em:
<[Link]
AGHAEI, Sareh; NEMATBAKHSH, Mohammad Ali; FARSANI, Hadi Khosravi. Evolution
of the world wide web: From web 1.0 to web 4.0. International Journal of Web & Semantic
Technology (IJWesT), IJWesT, v. 3, n. 1, p. 1–6, 2012.
AL-DEBAGY, Omar; MARTINEK, Peter. A comparative review of microservices and
monolithic architectures. In: IEEE. 2018 IEEE 18th International Symposium on
Computational Intelligence and Informatics (CINTI). Budapest, Hungary: IEEE, 2018.
AWRPC. RPC History. 2016. Disponível em: <[Link]
BALDINI, Ioana et al. Serverless Computing: Current Trends and Open Problems. 2017.
BASICS, EDI. How Does EDI Work? 2017. Disponível em: <[Link]
what-is-edi/how-does-edi-work/>.
BAX, Marcello Peixoto. Introdução às linguagens de marcas. Escola de Ciência da
Informação Universidade Federal de Minas Gerais, Universidade Federal de Minas Gerais,
v. 30, n. 1, 2001.
BERG, Kristi L.; SEYMOUR, Tom; GOEL, Richa. History of databases. International
Journal of Management & Information Systems, The Clute Institute, v. 17, n. 1, p. 29–36,
2013.
BIRRELL, ANDREW D.; NELSON, BRUCE JAY. Implementing remote procedure calls.
ACM Transactions on Computer Systems, ACM, v. 2, n. 1, p. 39–59, 1984.
BLOG, Readme. The History of REST APIs. 2016. Disponível em: <[Link]
com/the-history-of-rest-apis/>.
BOURRET, Ronald. Xml and databases. 2005.
CHAMBERLIN, Donald D. Early history of sql. IEEE Annals of the History of Computing,
IEEE, v. 34, n. 4, p. 78–82, 2012.
CLEO, Team. What is EDI? Electronic Data Interchange. 2020. Disponível em:
<[Link]
COCKROACHLABS. A brief history of databases: From relational, to NoSQL,
to distributed SQL. 2022. Disponível em: <[Link]
history-of-databases-distributed-sql/>.
CORBA. CORBA HISTORY. 2011. Disponível em: <[Link]
[Link]>.
DAGA, Bikash. Database Management Systems and SQL – Tutorial for Beginners. 2022.
Disponível em: <[Link]
 70

DATABRICKS. Orchestration. 2022. Disponível em: <[Link]

orchestration>.

DU, Sang Gyun; LEE, Jong Won; KIM, Keecheon. Proposal of grpc as a new northbound api
for application layer communication efficiency in sdn. IMCOM ’18: Proceedings of the 12th
International Conference on Ubiquitous Information Management and Communication,
IMCOM, n. 68, p. 1–6, 2018.

EDUCATIVE. What is a Remote Procedure Call (RPC)? 2020. Disponível em:

<[Link]

ENCYCLOPEDIA. Electronic Data Interchange. 2022. Disponível em: <https:

//[Link]/entry/27800>.

FACTORY, Dream. gRPC vs. REST: How Does gRPC Compare with Tra-
ditional REST APIs? 2023. Disponível em: <[Link]
grpc-vs-rest-how-does-grpc-compare-with-traditional-rest-apis/>.

FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based Software
Architectures. Tese (PhD thesis) — UNIVERSITY OF CALIFORNIA, IRVINE, 2000.
Available at <[Link]

FITZGERALD, Michael. XML Hacks: 100 Industrial-Strength Tips and Tools. [S.l.]:
O’Reilly Media, 2004.

GEEKS, Geeks for. Remote Procedure Call (RPC) in Operating System. 2023. Disponível
em: <[Link]

GOOGLE. About gRPC. 2023. Disponível em: <[Link]

. What is gRPC? Introduction to gRPC. 2023. Disponível em: <[Link]

what-is-grpc/introduction/>.

GROSSO, William. Java RMI. [S.l.]: O’Reilly Media, 2001.

GU, Xiaodong et al. Deep API learning. CoRR, abs/1605.08535, 2016. Disponível em:
<[Link]

HAROLD, Elliotte Rusty; MEANS, W. Scott. XML in a Nutshell. [S.l.]: O’Reilly Media,
2004.

HELLERSTEIN, Joseph M. et al. Introduction to web services. 2018.

HENNING, Michi. The rise and fall of corba. COMMUNICATIONS OF THE ACM, ACM,
v. 51, n. 8, p. 53–57, 2008.

HEYDARI, Sajjad. What Are E-Commerce APIs? 2022. Disponível em: <https:
//[Link]/blog/ecommerce-apis/>.

IBM. What is service-oriented architecture (SOA)? 2019. Disponível em: <https:

//[Link]/topics/soa>.

. What is an API? 2020. Disponível em: <[Link]

 71

. O que são microsserviços? 2021. Disponível em: <[Link]

microservices>.

. Simple Object Access Protocol. 2021. Disponível em: <[Link]

sc-and-ds/8.1.0?topic=stack-simple-object-access-protocol>.

KHANZODE, Ku. Chhaya A. Evolution of the world wide web: From web 1.0 to 6.0.
International Journal of Digital Library Services, Ijodls Geetanjali Research Publication,
v. 6, n. 2, p. 1–4, 2016.

KNOWLEDGEHUT. Java RMI. 2020. Disponível em: <[Link]

tutorials/java-tutorial/java-rmi>.

LEE, Yunhyeok; LIU, Yi. Using refactoring to migrate rest applications to grpc. ACM SE ’22:
Proceedings of the 2022 ACM Southeast Conference, ACM, p. 219–223, 2022.

LEWIS, James; FOWLER, Martin. Microservices. 2014.

LINK, Eduardo et al. Uma introdução ao corba. PUCRS, 2007?

MEDIUM. Diferenças entre gRPC e RPC. 2023. Disponível em: <[Link]

[Link]/differences-between-grpc-and-rpc-76d122104b4c>.

MICROSOFT. Comparar serviços gRPC com APIs HTTP. 2023. Disponível em:
<[Link]

. . 2023. Disponível em: <[Link]

comparison?view=aspnetcore-7.0>.

. Databases. 2023. Disponível em: <[Link]

relational-databases/databases/databases?view=sql-server-ver16>.

MOZILLA. Evolution of HTTP. 2023. Disponível em: <[Link]

docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP>.

. An overview of HTTP. 2023. Disponível em: <[Link]

docs/Web/HTTP/Overview>.

MOZILLA, Developer. Getting started with the web HTML basics. 2023. Disponível em:
<[Link]
basics>.

NATH, Keshab; DHAR, Sourish; BASISHTHA, Subhash. Web 1.0 to web 3.0 - evolution
of the web and its various challenges. In: ICROIT. [S.l.]: 2014 International Conference on
Optimization, Reliabilty, and Information Technology (ICROIT), 2014. p. 1–3.

NELSON, Bruce Jay. Remote procedure call. Carnegie Mellon University ProQuest
Dissertations, 1981.

NEUMANN, Andy; LARANJEIRO, Nuno; BERNARDINO, Jorge. An analysis of public rest

web service apis. IEEE TRANSACTIONS ON JOURNAL NAME, IEEE, 2021.

NEWMAN, Sam. Criando Microsserviços: Projetando Sistemas com Componentes

Menores e Mais Especializados. [S.l.]: Novatec Editora, 2022.
 72

PAUTASSO, Cesare; ZIMMERMANN, Olaf; LEYMANN, Frank. Restful web services vs.
big web services: Making the right architectural decision. In: ACM. 17th World Wide Web
Conference (WWW 2008). Beijing, China: ACM, 2008. p. 805–814.

PENNINGTON, Cary et al. Introduction to web services. IGI Global, IGI, p. 134–154, 2007.

PETERSON, Larry; DAVIE, Bruce. Computer Networks: A Systems Approach. [S.l.]:

systemsapproach, 2019.

PHOENIXNAP. Orchestration vs Automation: Overlapping, but Different IT Concepts.

2021. Disponível em: <[Link]

PIPEFY. Process Orchestration: How It Works. 2023. Disponível em: <https:

//[Link]/blog/process-orchestration/>.

POSTMAN. 2022 State of the API Report. 2022. Disponível em: <[Link]
com/state-of-api/api-technologies/#api-technologies>.

PUNNEN, Alex. REST is not the Best for Micro-Services GRPC and Docker
makes a compelling case. 2017. Disponível em: <[Link]
rest-in-peace-grpc-for-micro-service-and-grpc-for-the-web-a-how-to-908cc05e1083>.

RAPID. 2022 State of APIs. 2022. Disponível em: <[Link]

REDHAT. What is orchestration? 2019. Disponível em: <[Link]

automation/what-is-orchestration>.

. What is an API? 2022. Disponível em: <[Link]

what-are-application-programming-interfaces>.

RESELMAN, Bob. A brief history of network connectivity: Connected mainframes. 2020.

Disponível em: <[Link]

RFC. RFC 9110 HTTP Semantics. 2022. Disponível em: <[Link]

rfc9110>.

RICHARDSON, Chris. Microservices Patterns: With Examples in Java. [S.l.]: Manning

Publications, 2018.

ROBERTS, Mike. Serverless architectures. 2018.

ROSENCRANCE, Linda; MATTURRO, Brein. Remote Procedure Call (RPC).

2021. Disponível em: <[Link]
Remote-Procedure-Call-RPC>.

SANTOS, Lucas. O guia completo do gRPC. 2021. Disponível em: <[Link]

guia-grpc-1/>.

SURWASE, Vijay. Rest api modeling languages - a developer’s perspective. IJSTE -

International Journal of Science Technology & Engineering, IJSTE, v. 2, n. 10, p. 634–637,
2016.

TANENBAUM, Andre S.; STEEN, Maarten Van. SISTEMAS DISTRIBUÍDOS: princípios

e paradigmas. São Paulo - SP: Pearson Prentice Hall, 2007.
 73

TECHNOLOGYUK. Mainframe Computers. 2009. Disponível em: <[Link]

[Link]/computing/computer-hardware/[Link]>.

THOMPSON, Dean et al. Distributed component object model (dcom). Department of

Software Development Faculty of Computing and Information Techonology, p. 1–12,
1997.

VERMA, Aditi. Application Layer Protocols. 2022. Disponível em: <[Link]

com/application-layer-protocols-i>.

VERTIGO. gRPC ou REST: qual utilizar? 2020. Disponível em: <[Link]

grpc-ou-rest-qual-utilizar/>.

VMWARE. What is Cloud Orchestration? 2023. Disponível em: <[Link]

com/br/topics/glossary/content/[Link]>.

VOLLE, Adam. Web application. 2022. Disponível em: <[Link]

Web-application>.

W3C. The World Wide Web: A very short personal history. 1998. Disponível em:
<[Link]

. Simple Object Access Protocol (SOAP) 1.1. 2000. Disponível em: <https:
//[Link]/its/worldpac/Standards/[Link]>.

. About The World Wide Web. 2001. Disponível em: <[Link]

. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). 2007. Disponível
em: <[Link]

. Extensible Markup Language (XML) 1.0 (Fifth Edition). 2008. Disponível em:
<[Link]

. Extensible Markup Language (XML). 2016. Disponível em: <[Link]

XML/>.

WALDO, Jim. The jini architecture for network-centric computing. Communications of the
ACM, ACM, v. 42, n. 7, p. 76–82, 1999.

WOLLRATH, Ann; RIGGS, Roger; WALDO, Jim. A distributed object model for the java
system. The USENIX Association, Computing Systems, USENIX, v. 9, n. 4, p. 265–290,
1996.