gRPC: Por que você ainda usa REST?

O REST é ainda hoje a opção mais usada para criação de APIs para comunicação entre processos sobre rede, embora em muitos casos não seja realmente uma escolha, mas um uso pelo fato de ser simples e amplamente usado e conhecido. Por outro lado, soluções como gRPC e GraphQL vêm crescendo e se popularizando cada vez mais como alternativa ao “plain old” REST.

Essa palestra tem o objetivo de apresentar o gRPC como uma solução aos problemas do REST para APIs, principalmente para microsserviços. Será trazido um pouco do contexto histórico da web e de comunicação entre processos (IPC), para entendermos como chegamos até aqui, levantando alguns questionamentos como “RPC sobre HTTP” e “REST com HTTP/2”. Também serão abordados os principais conceitos e características do gRPC, mostrando seus prós e contras, e exemplos de uso do gRPC com protobuffers.

Link para o código: https://github.com/yagotome/grpc-cache

Transcript

1. gRPC: Por que você ainda usa REST?
2. Yago Tomé 2 Senior Software Engineer
3. Disclaimer ➔ Não trabalho para a Google ➔ Não estou vendendo um produto ➔ Não existe bala de prata ➔ Tudo tem tradeoffs 3
4. Um Pouco de História ➔ IPC ➔ HTTP ➔ Web Services ➔ RPC ➔ REST 4
5. IPC (Inter-Process Communication) ➔ Shared Memory (shmctl, shmget, shmat) ➔ Signal (SIGTERM, SIGKILL, SIGPOLL) ➔ File ➔ Socket (TCP, UDP) 5
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
7. Web Services ➔ Serviços remotos sobre HTTP ➔ SOAP ➔ REST é Web Service? 7
8. 8 SOAP
9. SOAP ➔ Simple Object Access Protocol??? ➔ RPC sobre HTTP (com XML) ➔ Já foi o padrão de mercado mais usado 9
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
21. 21 1s 12s
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
26. E o que acontece com o REST agora? 26
28. Live Coding? 28
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
33. CONECTE-SE COMIGO! 33 @yagotome yg.tome @yagotome yagotome
34. 34 Pedro Belfort pedro.belfort@lutick.com Yago Tomé yago.tome@lutick.com
35. 35 We’re hiring!
36. Bônus
37. E o HTTP/3? ➔ HTTP over QUIC ◆ Aceito pelo IETF em novembro de 2018 ◆ Suporte do Chrome lançado em setembro de 2019 37
41. Links Úteis 41 • https://http2.github.io/ • https://developers.google.com/web/fundamentals/performance/http2 • https://freecontent.manning.com/animation-http-1-1-vs-http-2-vs-http-2-with-push/ • https://grpc.io/docs/talks/ • https://grpc.io/docs/guides/benchmarking/ • https://medium.com/@bimeshde/grpc-vs-rest-performance-simplified-fd35d01bbd4 • https://imagekit.io/demo/http2-vs-http1 • https://developers.google.com/protocol-buffers/docs/proto3 • https://medium.com/@giefferre/from-00s-to-20s-migrating-from-restful-to-grpc-5a5aa0cf27ba • https://grpc.io/blog/loadbalancing/ • https://about.sourcegraph.com/go/grpc-in-production-alan-shreve/ • https://github.com/yagotome/grpc-cache • http://bit.do/fhN4D • https://blog.usejournal.com/what-the-hell-is-protobuf-4aff084c5db4
42. Perguntas? :)
43. Obrigado! :D