A maioria das aplicações de software precisa de ser capaz de se ligar a outros códigos por várias razões. Isto pode ser qualquer coisa, desde a integração até à adição de novas funcionalidades. Para garantir que o software possa ligar-se a outras aplicações e para assegurar a sua integração em outros programas, os programadores utilizam APIs. É por isso que é necessária uma Interface de Programação de Aplicações para a maioria do software. Através do seu papel de ponte entre sistemas, as APIs permitem aos indivíduos o acesso a uma variedade de serviços web. Por conseguinte, é importante escolher a tecnologia apropriada para oferecer uma API ao seu projecto.
Qualquer organização que queira partilhar a sua aplicação ou plataforma com os seus utilizadores necessita de utilizar APIs. Há muitas formas de desenvolver e afinar APIs para as tornar perfeitas para a sua aplicação. Um dos métodos mais recentes que os programadores estão a utilizar para conceber APIs é o gRPC. Vejamos o que é o gRPC e os seus prós e contras.
O que é o gRPC?
gRPC significa Google Remote Procedure Call. gRPC é uma estrutura RPC de código aberto que é utilizada para criar APIs escaláveis e rápidas. Permite o desenvolvimento de sistemas em rede e comunicação aberta entre aplicações cliente e servidor gRPC. gRPC tem sido adoptado por várias empresas de tecnologia de ponta, incluindo Google, IBM, Netflix, e muito mais. A estrutura gRPC depende de pilhas de tecnologia de ponta como HTTP/2, buffers de protocolo, e mais para uma óptima protecção de API, chamadas de procedimento remoto de alto desempenho, e escalabilidade.
O que são RPCs?
RPC e REST - Representational State Transfer- têm sido historicamente duas abordagens distintas à construção de APIs. Além disso, protocolos como SOAP e GraphQL são também utilizados para este fim. As chamadas de procedimento remoto permitem-lhe escrever software como se fosse executado localmente, embora possa ser executado num dispositivo diferente.
São a estrutura mais utilizada convencionalmente para a concepção de APIs. Em contraste com uma chamada de protocolo HTTP típica, um RPC emprega uma chamada de função como método primário de interacção cliente-servidor. RPC é uma técnica produtiva para criar APIs, uma vez que as trocas são simples, e os conteúdos são leves. Os serviços gRPC também imitam esta arquitectura de comunicação. RPC emprega IDL - Interface Definition Language para contratar o tipo de dados e os métodos que serão invocados. Os serviços gRPC adoptados dos RPCs têm-se tornado muito populares nos últimos anos.
Porque foram desenvolvidos os serviços de gRPC?
À medida que mais empresas abrem canais de integração, está a tornar-se difícil ligar esse software. RPC Os APIs são desafiantes para integrar e arriscados para distribuir porque podem revelar especificidades internas. São desenvolvidos em muitas linguagens de programação e estão estreitamente ligados à estrutura subjacente.
Esta questão foi abordada, e a acessibilidade às APIs foi aumentada quando a API REST foi lançada em 2000. Especificamente, deu aos utilizadores uma forma consistente de recuperar informações indirectamente através de recursos que utilizam técnicas HTTP padrão como GET, PUT, POST, e outras. A principal distinção de RPC do REST API é que com RPC, os processos são abordados, mas não é fácil prever o que poderiam ser os processos em vários sistemas.
O REST API não poderia substituir completamente o RPC simples e leve porque produzia uma grande quantidade de metadados, mesmo quando oferecia um formato melhorado para lidar com muitas aplicações. Isto resultou no eventual aparecimento do GraphQL do Facebook e dos serviços gRPC do Google.
O Google construiu o gRPC em 2015 como um complemento à estrutura do RPC para ligar numerosas arquitecturas de microserviços feitas com várias técnicas. O gRPC estava originalmente estreitamente relacionado com a infra-estrutura central do Google, mas acabou por ser tornado código aberto e normalizado para utilização pelo público em geral.
Visão geral dos conceitos de gRPC
A utilização de tecnologias de ponta, que têm alto desempenho sobre JSON e XML e oferecem maior integridade API, é responsável pela criação e popularidade do gRPC. Alguns dos conceitos de gRPC de que deve estar ciente são:
Buffers de protocolo
Os buffers de protocolo, também conhecidos como Protobuf, são normas de serialização ou de desserialização que simplificam a definição de aplicações e executam automaticamente a geração de códigos das bibliotecas clientes. A versão mais recente, proto3, é mais simples de utilizar e oferece as mais recentes capacidades para o gRPC.
.Proto Os ficheiros permitem os serviços e comunicações gRPC entre clientes gRPC e mensagens de servidor. O ficheiro .proto é carregado na memória no momento da execução pelo compilador Protobuf - protoc. Este compilador constrói aplicações cliente gRPC e servidor gRPC que empregam a estrutura in-memory para serializar e deserializar os dados binários. Cada comunicação é enviada e recebida entre o utilizador e o serviço remoto após geração de código no gRPC.
Como os dados são traduzidos numa forma binária e os sinais encriptados são mais pequenos, a análise com Protobuf utiliza menos CPU potência para o gRPC. Portanto, mesmo em computadores com um CPU mais fraco, tais como telemóveis, as mensagens são enviadas mais rapidamente com gRPC.
HTTP/2
O serviço gRPC é construído sobre HTTP/2, a versão do HTTP/1.1 que tem menos limitações. Embora funcione com o protocolo HTTP mais antigo, o HTTP/2 tem várias características sofisticadas para o gRPC. Isto inclui uma camada de enquadramento binário, que divide cada consulta e resposta HTTP/2 em mensagens mais pequenas e enquadra-as em formato binário para melhorar a entrega de mensagens. Além disso, o gRPC suporta múltiplos pedidos e respostas do cliente e do servidor gRPC em streaming bidireccional full-duplex.
O HTTP/2 tem um método de controlo de fluxo que permite o controlo preciso do RAM necessário para guardar os pacotes em voo. Oferece também compressão de cabeçalho para serviços gRPC. Tudo no HTTP/2 é encriptado antes da transmissão, mesmo cabeçalhos, que fornecem chamadas de procedimento remoto de alto desempenho. gRPC fornece processamento assíncrono e síncrono com HTTP/2, permitindo a execução de vários tipos de RPC interactivos e em fluxo contínuo.
Com a ajuda de todas estas características do HTTP/2, os serviços gRPC podem utilizar menos recursos, o que leva a tempos de resposta mais rápidos entre as aplicações baseadas na nuvem e os serviços gRPC e a uma maior duração da bateria para os clientes gRPC que operam em dispositivos móveis.
Streaming
Uma ideia crucial que o gRPC suporta é o streaming, que permite a execução de vários processos dentro de um único pedido. O gRPC torna isto viável através da funcionalidade de multiplexagem do HTTP/2, que permite que várias respostas ou pedidos sejam enviados ou recebidos simultaneamente através de uma ligação TCP - Transmission Control Protocol -. Os formatos primários de streaming são RPCs server-streaming, cliente-streaming RPCs, e bidirectional-streaming RPCs.
Canais
Ao contrário dos fluxos HTTP/2, que permitem numerosos fluxos simultâneos numa única ligação de pedido, um canal com gRPC suporta múltiplos fluxos contínuos através de múltiplos pedidos. São utilizados para construir um stub de cliente e dar um mecanismo de ligação a um servidor gRPC sobre um IP e porta específicos.
Arquitectura gRPC
A arquitectura gRPC consiste tanto num cliente gRPC como num servidor gRPC. Cada serviço cliente gRPC contém um stub ou um ficheiro auto-gerado, que é semelhante a uma interface que contém os processos remotos activos. O cliente gRPC inicia uma chamada de procedimento local para um stub contendo argumentos a serem encaminhados para as mensagens do servidor gRPC. O stub do cliente gRPC envia então a consulta para a unidade de tempo do cliente local no computador local, após a serialização dos argumentos usando o procedimento de marshaling Protobuf.
O sistema operativo utiliza o protocolo HTTP/2 para comunicar com o computador do servidor distante. O SO do servidor aceita as mensagens e invoca o processo stub do servidor, que utiliza Protobuf para invocar a operação apropriada depois de descodificar os parâmetros de entrada. A camada de transporte do cliente recebe então a resposta encriptada a partir do stub do servidor. A execução passa de novo para o chamador após o stub do cliente gRPC receber as mensagens de resposta e desembrulhar os argumentos fornecidos.
Vantagens do gRPC
O gRPC tem várias vantagens sobre outros mecanismos de concepção API. O gRPC também melhora a estrutura RPC. Aqui estão os benefícios mais proeminentes dos serviços de gRPC:
- Chamadas de procedimento remoto de alto desempenho
Utilizando Protobuf e HTTP/2, os serviços gRPC fornecem até 10 vezes o elevado desempenho e protecção API da interacção REST+JSON. Com a utilização de server pushes, multiplexing, e compressão de cabeçalho, o HTTP/2 fornece rankings de alto desempenho para serviços gRPC. Enquanto a multiplexação elimina com atraso de cabeça de linha, o push do servidor torna possível que o HTTP/2 empurre o material do servidor para o cliente antes de ser necessário. As mensagens são comprimidas mais eficazmente usando HTTP/2, resultando num carregamento mais rápido com os serviços gRPC.
- Streaming
A descrição do serviço para serviços de streaming gRPC já inclui os princípios de streaming de cliente ou de fim de servidor. A construção de clientes gRPC e de serviços de streaming são significativamente facilitados como resultado.
- Geração de código
A geração de código para programas cliente gRPC e gRPC server é o componente chave da abordagem web gRPC. Para a geração de código a partir do ficheiro .proto, os módulos gRPC empregam o compilador .protoc. O formato Protobuf é controlado através da geração de código no gRPC, que é utilizado para definir tanto os formatos de dados como os pontos finais da aplicação. Pode criar stubs de rede do lado do cliente e esqueletos do lado do servidor, o que reduz a quantidade de tempo necessário para conceber programas com uma variedade de serviços nos serviços gRPC.
- Interoperabilidade
Numerosos sistemas e linguagens de programação, como Java, Ruby, GoC#, e muito mais, são apoiados pelos recursos e bibliotecas gRPC. Com estas linguagens de programação, os programadores podem criar aplicações de desempenho enquanto utilizam compatibilidade completa entre plataformas com o gRPC. Isto é graças ao formulário de cablagem binária Protobuf e à geração eficaz de código para quase todos os sistemas.
- Segurança
A segurança API é assegurada no gRPC utilizando HTTP/2 sobre uma sessão encriptada TLS de ponta a ponta. O gRPC promove a adopção de SSL/TLS para encriptação e autenticação de dados entre o servidor e o cliente gRPC.
- Produtividade e Usabilidade
Uma vez que o gRPC é uma alternativa completa RPC, funciona sem problemas numa vasta gama de sistemas e línguas. O gRPC também dispõe de grandes ferramentas, sendo gerado manualmente grande parte do código da placa de caldeira necessário. Os engenheiros podem agora concentrar-se mais na funcionalidade central devido à significativa economia de tempo com gRPC.
Contras do gRPC
Embora possamos esperar que os inconvenientes do gRPC acabem por ser resolvidos, eles colocam agora alguns problemas à sua utilização. Alguns dos inconvenientes do gRPC de que deve estar ciente são:
- Falta de maturidade
O desenvolvimento de uma tecnologia pode ser uma barreira significativa à adopção. Isso também é evidente durante a utilização do gRPC. GraphQL O gRPC, um dos pares do gRPC, tem mais de 14k consultas em StackOverflow, enquanto o gRPC tem apenas um pouco menos de 4k no momento. À comunidade gRPC falta conhecimento das melhores práticas, soluções, e sucessos porque não há muita assistência de programadores para HTTP/2, bem como buffers de protocolo fora do Google. No entanto, à medida que a comunidade gRPC se expande e atrai novos programadores, isto acabará por evoluir.
- Apoio limitado ao navegador
Como nenhum navegador web gRPC actual pode lidar com frames HTTP/2, não se pode efectivamente chamar um serviço gRPC a partir de um navegador uma vez que o gRPC Web depende principalmente do HTTP/2. Como resultado, é necessário utilizar um proxy com gRPC, que vem com vários inconvenientes.
- Não legível por humanos
Ao contrário do XML e do JSON, os ficheiros Protobuf não são legíveis por humanos, uma vez que os dados são comprimidos para um formato binário. Os programadores devem fazer uso de ferramentas adicionais, tais como o protocolo de reflexão do servidor e o prompt de comando gRPC para avaliar as cargas úteis, realizar a resolução de problemas, e criar consultas manuais.
- Curva de aprendizagem íngreme
Levará algum tempo a familiarizar-se com buffers de protocolo e descobrir métodos para lidar com o atrito HTTP/2, em contraste com o REST e o GraphQL, ambos os quais empregam principalmente o JSON.
Como é que o AppMaster ajuda?
A geração denão-códigos está a mudar a forma como as pessoas vêem a programação. A geração de código sem código torna possível às pessoas aprenderem e criarem software mais rapidamente com a geração de código. A geração de código para a sua aplicação é mais simples utilizando plataformas sem geração de código, como o AppMaster. Também não há problemas de propriedade, uma vez que a geração de código está protegida, e o código que criar pertencerá exclusivamente a si. Pode criar aplicações cliente e servidor mais rapidamente e mais facilmente com o AppMaster.
A plataforma sem geração de código AppMaster permite aos programadores utilizar o protocolo gRPC para fazer pedidos entre a arquitectura backend dos microserviços. No próximo ano iremos alargar o suporte gRPC incluindo API tanto para aplicações gRPC Web como gRPC Mobile.
Conclusão
Embora os serviços gRPC tenham vários benefícios que os tornam atractivos para as empresas e para os desenvolvedores, finalmente, a decisão de utilizar os serviços gRPC em vez de outros como REST ou SOAP depende da sua aplicação. Enquanto alguns softwares terão benefícios de alto desempenho com gRPC, outros poderão ser mais adequados às suas alternativas. Deve compreender os inconvenientes e vantagens dos serviços gRPC e decidir se funciona para si.
