O documento discute as vantagens do uso de gRPC em comparação com REST para comunicação entre serviços. Apresenta uma breve história dos protocolos RPC, HTTP, Web Services e REST e discute problemas comuns no uso de REST. Em seguida, explica como gRPC resolve esses problemas ao usar HTTP/2 de forma mais eficiente, permitindo streaming e tolerância a falhas de forma nativa. Por fim, discute algumas desvantagens de gRPC e como a abordagem pode ser usada na prática.
6. HTTP (Hypertext Transfer Protocol)
➔ O HTTP não nasceu como um protocolo de propósito geral
➔ HTTP foi criado em 1989 para transferência de Hypertext
➔ Na versão 1.0 passou a ter header
➔ A versão 1.1 foi lançada em 1997
6
11. RPC (Remote Procedure Call)
➔ Um processo chama um método que vai rodar em outro
processo sobre a rede
◆ Mas como implementar?
➔ Há muitas implementações
◆ CORBA
◆ RMI (EJB)
◆ XML-RPC
◆ SOAP
◆ gRPC (Google)
◆ Twirp (Twitch.tv)
◆ Ribbon (Netflix) 11
12. RPC sobre HTTP
➔ GET https://checkout.hurb.com/calcShipping?cep=2323156
➔ POST https://message.hurb.com/sendPushNotification
➔ POST https://checkout.hurb.com/renewCartExpiration
➔ GET https://api.hurb.com/hotels/search?q=Búzios
➔ POST https://api.hurb.com/auth/logIn
12
13. REST (Representational State Transfer)
➔ “REST é um estilo de arquitetura de software que define um conjunto
de restrições a serem usados para a criação de web services”
◆ Client-Server, Stateless, Cacheable, Uniform Interface
(HATEOAS), Layered System, etc
◆ Operações sobre recursos localizados por URI
◆ Desacoplamento entre o servidor e cliente
◆ Padronização na arquitetura de aplicações WEB
13
14. REST (Representational State Transfer)
➔ Richardson Maturity Model
1. Swamp of POX
(Plain Old XML)
2. Recursos
3. Verbos HTTP
4. Hypermedia (HATEOAS)
14
15. Problemas do REST
➔ REST impõe restrições que podem custar caro!
➔ Nem tudo é recurso!
◆ Um serviço não é só de CRUD
● Executam tarefas (indexação, envio de emails, etc)
● Fazem cálculos ou operações complexas sobre dados
● Verificam autenticidade de usuários
◆ Tentar modelar TUDO como recurso => over abstraction
15
17. Problemas do REST
➔ HTTP Status Code nem sempre são simples de escolher
➔ É comum termos que manter múltiplas versões de uma API
➔ É necessário documentar todas as operações e recursos da API
➔ Possivelmente terá problemas de under-fetching
➔ É necessário implementar um cliente para cada linguagem*
➔ Não permite streaming de dados
➔ É amplamente usado sobre HTTP/1.1
17
18. HTTP/2
➔ Comprime os headers (não apenas payload)
➔ É um protocolo binário, ao invés de textual
➔ Permite comunicação bidirecional sobre o socket
➔ Multiplexa vários requests em uma única conexão
18
22. REST sobre HTTP/2
➔ HTTP/2 só exige 1 conexão aberta entre o cliente e servidor
◆ Perfeito para microsserviços
● Apenas 1 conexão aberta entre os microsserviços
◆ E se a conexão cair?
◆ Como distribuir a carga?
➔ HTTP/2 é um protocolo binário, mas o payload será JSON?
◆ Que desperdício!
➔ Precisamos de um cara para resolver esses problemas
22
24. gRPC
➔ Usa o HTTP/2
➔ Escalável
◆ Client-side load balancing
◆ Google fazia 10 bilhões de RPCs por segundo (em 2016)
➔ Tolerância a falhas
◆ Detecção de falhas (PING do HTTP/2)
◆ Reconexão em caso de falhas (com re-descoberta de nós)
➔ Payload binário com protobuffers
➔ Streaming (client, server e bidirecional) é um 1st class citizen
24
😎
25. gRPC
➔ Não impõe restrições ao design da API
◆ Sem overabstraction, você é livre!
➔ É payload agnostic, mas usa protobuffer por padrão
➔ Possui IDL com protobuffers
◆ Não precisa de uma documentação extra da API
◆ Não é necessário escrever código para cada cliente
◆ Suporta deprecação - Para não manter várias versões de API
➔ Possui error handling próprio com poucos códigos de erros
➔ Suporta SSL/TLS
➔ Suporta envio de metadata (Auth tokens, client id, timeout, etc) 25
😎
29. E as desvantagens do gRPC?
➔ Com protobuffers
◆ Mais uma tecnologia na stack
◆ Payload não é human-readable
◆ Debugging mais complicado
➔ É um framework (não um padrão)
◆ Depende de manutenção caso encontre um bug/problema,
◆ Sua solução pode ficar acoplada ao framework
29
30. E as desvantagens do gRPC?
➔ Muito código gerado?
➔ Não possui out-of-the-box caching
➔ Load balancing não é tão simples
➔ Há inconsistências nas implementações de diferentes
linguagens
30
31. Como usamos o gRPC no Hurb
➔ Protobuffers versão 3, com Uber’s prototool
➔ Em golang
➔ Deployado no kubernetes
➔ Com load balancing feito pelo Service Mesh Linkerd
➔ Na comunicação do gateway GraphQL com os microsserviços
◆ Os microsserviços têm uma arquitetura orientada a eventos
31
32. Conclusão
➔ gRPC é uma solução bem desenhada e pode ser usada sem medo
➔ gRPC basicamente usa o HTTP/2 da forma “correta”
◆ Mais performance
➔ Mais produtividade (com geração de stubs e abstração da rede)
➔ Maior manutenibilidade
◆ Não precisa alterar códigos de cada client em caso de alteração na API
(nem documentação)
◆ Não precisa manter múltiplas versões de API
➔ Dependendo do contexto, pode fazer sentido usar REST ainda
32
Criado por Tim Berners-Lee na CERN, junto com o HTML, WWW e o browser.
O objetivo não era ser o protocolo de comunicação entre aplicações.
É muito comum associarem “Web Service” a SOAP.
REST é Web Service!
Não é um sabão! (infelizmente) Muito menos serve para limpar algo rs
O que tem de Simple no SOAP? HAHA
SOAP já foi o REST de hoje! rs
Isso é o SOAP!
gPRC tem maior comunidade com relação a Twirp e Ribbon
Netflix abandonou o Ribbon e usa bastante gRPC.
Olhando pela URL, essas APIs são REST?
Elas são exemplos de RPC com HTTP.
Surgiu na tese de doutorado de Roy Fielding de 2000.
Arquitetura da WEB.
Já teve dificuldades para modelar alguns recursos em REST?
Diferença entre HTTP Status Code 400 e 422 / 401 e 403
* Com Swagger/OpenAPI é possível gerar código do client, mas quem faz isso?
Principal problema é que é amplamente usado com HTTP/1.1
Quem aí já usou HTTP/2?
Quem aí usa HTTP/2 em produção? rs
Implementação em golang, nos links no final do slide
HTTP/1.1 = 12s
HTTP/2 = 1s
Se a conexão cair, é preciso perceber que ela caiu, e então reconectar tentando não perder o estado da conexão que caiu.
A carga vai para apenas 1 instância do servidor caso você abra apenas 1 conexão com o servidor. Para balancear, você precisará implementar alguma política de balanceamento no client ou no load balancer.
O principal ganho está em usar BEM o HTTP/2
Você pode usar gRPC com JSON se quiser, mas o protobuf é uma opção ao JSON que tem as seguintes características:
Binário
Schema (IDL)
Código gerado evita escrita desnecessária de boilerplate.
Sobre inconsistência: Em Golang Channels são chamados de Connections; Há features que uma linguagem tem e outras não.
E pra finalizar, gostaria de usar esse minutinho final para apresentar a minha empresa, que fundei com o meu amigo Pedro Belfort.
Nós somos a Lutick. Nascemos com o propósito de desenvolver produtos digitais com o mais alto nível de excelência.
Percebemos que o mercado é muito mais movido a tempo/velocidade do que à qualidade, e acreditamos que a qualidade é essencial para o sucesso de um produto e que podemos ser ágil sem abrir mão de qualidade. Por isso buscamos usar tecnologias modernas e as melhores práticas sempre.
Nosso principal princípio é o Mobile First, acreditamos muito nisso e por isso focamos no desenvolvimento mobile, mas fazendo toda stack com backend e devops com os mais altos padrões de qualidade para gerar a melhor experiência para o usuário.
Hoje estamos trabalhando com React Native, Flutter, NodeJS, GraphQL, Android e iOS nativos (Kotlin/Swift), PWA e buscamos explorar novas possibilidades como assistentes de voz, dentre outras coisas.
Enfim, aqui tem o nosso contato, caso vocês queiram saber mais ou quiser propor alguma coisa, estamos abertos. Escanie nosso QR Code!
Benchmark de velocidade entre Protobuf, JSON e JSON stream. (gráfico de tempo de processamento)
Encoding: 3x mais rápido (proto > JSON)
Decoding: 5x mais rápido (proto > JSON)
