Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Por que você ainda usa REST? gRPC vs REST
Semelhante a Por que você ainda usa REST? gRPC vs REST (20)
Por que você ainda usa REST? gRPC vs REST
- 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
- 10. 10
- 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
- 16. 16
- 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
- 19. 19
- 20. 20
- 21. 21
- 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
- 23. 23
- 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
- 27. 27
- 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
- 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
- 38. 38
- 39. 39
- 40. 40
- 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!
Notas do Editor
- 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)
- Benchmark relação a tamanho do payload
- Benchmark relação a tamanho do payload