9. Conclusões

Podemos constatar a forte interoperabilidade entre APIs implementadas em linguagens diferentes. As dificuldades de implementação das tecnologias de chamadas remotas do passado, como CORBA e RMI adivinham da complexidade dos programadores terem de se preocupar com detalhes da comunicação, como conexão, o controle do fluxo de dados e serialização. Com o gRPC toda essa complexidade fica abstraída a cargo do framework, uma vez que os plugins compiladores geram todo o código necessário a comunicação. O gRPC fornece a interface para o uso da infraestrutura lógica de baixo nível, gerando a abstração necessária por meio de classes do modelo do domínio. Com isso o programador está livre para focar mais na regra de negócio e menos na comunicação.

Notamos uma diferença na clareza dos conceitos elementares da comunicação do gRPC nas interfaces expostas pelas bibliotecas implementadas em cada linguagem. Vemos que o JavaScript fez um ótimo trabalho de abstração carregando e compilando arquivos .proto em memória, usando função de callback, tão familiar entre a comunidade JS, para fazer o payload, de tal forma que com poucas linhas o programador já pode usar o gRPC em seu código. Entretanto, com exceção de protobuf, não fica claro os conceitos de Channel e Stub, quais classes geradas e disponibilizadas pelos plugins fariam esses papeis. Em contraponto, vemos no Java os conceitos de Channel e Stub explicitamente nos nomes das classes geradas, como em ManagedChannel, CrudAlunoBlockingStub e SorteioServiceBlockingStub.

Vislumbramos um cenário positivo com a adoção do gRPC em larga escala, como é hoje com o REST. Com o gRPC as equipes exporão seus dados e funcionalidades por meio de interfaces de serviço e devem se comunicar por meio dessas interfaces. Não será permitida nenhuma outra forma de comunicação entre processos: sem links diretos, sem leituras diretas do armazenamento de dados de outra equipe, sem modelo de memória compartilhada, sem backdoors. A única comunicação permitida é por meio de chamadas de interface de serviço pela rede. Todas as interfaces de serviço, sem exceção, devem ser projetadas desde o início para serem externalizáveis. Ou seja, a equipe deve planejar e projetar para poder expor a interface aos desenvolvedores do mundo exterior.

Salientamos que a tecnologia gRPC ainda precisa expandir sua disponibilidade a mais linguagens e que o suporte nos navegadores ainda é incipiente, o que restringe sua utilização ao back-end e aplicações mobile. Todavia, é apenas uma questão de tempo, porque a perspectiva de menor latência, menor carga computacional na serialização de objetos e menor tráfego pela rede são argumentos fortes para esse suporte se materializar.

Em âmbito geral, constatamos que a partir dos estudos teóricos realizados e do conhecimento adquirido durante a implementação da arquitetura de microserviços, podemos concluir que os resultados acadêmicos foram satisfatórios, tendo proporcionado um bom entendimento da tecnologia gRPC e de seus benefícios relacionados à outras arquiteturas de implementação de API’s como o REST.