Baixar para ler offline
Carregado porRafael Sotero Rocha
Introdução ao WebFlux
O documento discute programação reativa e o framework Spring Webflux. Aborda conceitos como programação não-bloqueante, streams de dados assíncronos e reactive streams. Também apresenta o funcionamento do Webflux e exemplos práticos de código reativo.
Introdução ao WebFlux
- 1. Spring Webflux Threads nãobloqueantes em serviços Web Spring
- 2.
- 3. Reactive Programing Programação com streams dedados (sequência de eventos) assíncronos 2077 01
- 4. Surgiu em 2077{???} 1960
- 5. Observer = ReactP. {???} React Prog. > Observer
- 6. ● É umconjunto de conceitos ● Event Driven ● Data Streams… Data Streams e Data Streams ● Assíncrono ● Não-bloqueante ● Backpressure ● Programação Funcional e Declarativa O que é React Programming
- 7.
- 8. Tipos de Observables 02 01 Esperaalgum subscriber para enviar valores COLD Envia valores mesmo sem subscribers HOT
- 9. Spring WebFlux Framework Web não bloqueantecompatível com Reactive Streams 2077 02
- 10. Por baixo damáquina chamada “WebFlux” existe um motor chamado Project Reactor
- 12. Flux é melhorque MVC Depende do Contexto
- 13. Performance em bases relacionais: CliqueAqui Benchmark
- 14.
- 15.
- 16. Porque Reativo? “Nós acreditamosque é preciso haver uma abordagem consistente para arquitetura de sistemas, e acreditamos que todos os aspectos necessários já são reconhecidos individualmente: nós queremos sistemas Responsivos, Resilientes, Elásticos e Orientados a Mensagens. Nós chamamos isso de Sistemas Reativos.” - Manifesto Reativo
- 17. Por onde começar? -Project Reactor - R2DBC - WebClient - Event Loop
- 19. CREDITS: This presentationtemplate was created by Slidesgo, including icons by Flaticon, and infographics & images by Freepik Thanks! me@soterocra.dev +55 34 99648-0888 crudtec.com.br Do you have any questions? @soterocra
Notas do Editor
- #2 Bom pessoal, quero agradecer a presença de todos aqui, vamos começar a apresentação. Vamos falar sobre Spring Webflux, o framework não bloqueante com suporte a Reactive Streams e back pressure da Spring.
- #3 O nosso conteúdo hoje está separado em 4 partes. 1 - Introdução: Para falar sobre esse framework precisamos discutir um pouco sobre programação reativa, e o que ela representa nesse contexto. 2 - Framework Depois disso vamos entrar nas particularidades do WebFlux, o framework que pretendemos conhecer um pouco mais depois dessa apresentação. 3 - Hands-on Na terceira parte da apresentação vou abrir um código que trouxe para discutirmos o funcionamento e rodarmos um exemplo. 4 - Conclusão Depois de passar por todos os tópicos vou concluir o assunto apontando minha visão sobre o tema.
- #4 Reactive Programming, um conceito que está cada vez mais presente em foruns de discussão e no mercado de trabalho. Mas afinal de contas, o que é o reactive programming? Se fossemos resumir em apenas 1 frase, eu diria… “Programação com fluxos (streams) de dados assíncronos” Mas veremos que é um pouco mais profundo que isso e no que isso impacta o framework da spring, webflux. Artigo Legal: https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
- #5 Bem, já que cada vez mais é falado o termo, vem a pergunta… E quando surgiu esse conceito? Veio do futuro, em 2077? A resposta é não, ele surgiu em 1960 e desde essa época muito se tem falado, escrito e feito com reactive programming. Quando falamos de reatividade, lembramos de um padrão de projeto já muito usado e reconhecido, o observer. O observer é muito popular em aplicações gráficas, por exemplo quando observamos eventos de clique, preenchimento de uma caixa de texto, dentre outros. https://www.scnsoft.com/blog/java-reactive-programming
- #6 Então já entendi, Observer Pattern é igual a Reactive Programming, certo? ERRADO! Reactive Programming é mais do que o padrão Observer, é algo maior. No fim do dia Reactive Programming é a combinação do padrão Observer, com o padrão Iterator e programação funcional. Por design, o padrão reativo suporta comunicação assíncrona não bloqueante com backpressure. Enquanto o observer é muito mais “rústico”, tendo como “desvantagens”: Não ser thread-safe Não suporta backpressure Não suporta composição Não suporta comunicação com assincronicidade não bloqueante com backpressure. Dentre esses e muitos outros itens é onde o React Programming brilha. Fonte: Scala Reactive Programming: Build scalable, functional reactive microservices https://stackoverflow.com/questions/16652773/what-is-difference-between-observer-pattern-and-reactive-programming
- #7 Então React Programming é: …. Antes de passar para o próximo slide, para ficar claro o que é Backpressure, imagine um restaurante, o cozinheiro possui a capacidade de produzir 10 pratos por minuto, porém o garçom possui a capacidade de buscar apenas 5 pratos por vez, então o cozinheiro tem que conseguir lhe dar com essa pressão de volta, entende? Isso é o backpressure. Fonte: reactivemanifesto.org https://www.youtube.com/watch?v=1cIO5FhV8vQ
- #8 Existe uma iniciativa para definir um padrão para Stream Reativos. Esse padrão define que ele deve ser capaz de processar um número infinito de elementos, em sequence, de forma assíncrona, não bloqueante e com backpressure. Inclusive essa especificação já está presente desde a versão 9 do java para definir interação entre componentes assincronos com backpressure. Pra fazer isso então temos 4 componentes padrões, podemos chamar de interfaces. São elas: Publisher (Observable em alguns frameworks/linguagens) Responsável por gerar os elementos, o chefe de cozinha. Subscriber Consumidor dos eventos publicados. O garçom que busca os pratos. Quando ele vai no publisher ele faz uma subscription, é um contrato. Pode dizer quantos elementos pode pegar. Subscription Processor O processor tem um contexto diferente, onde ele meio que pode ser o publisher e o subscriber ao mesmo tempo, esse vamos passar por hora. https://www.slideshare.net/TimvanEijndhoven/getting-into-the-flow-building-applications-with-reactive-streams - 12
- #9 Para comecar a entender o conceito também temos que falar dos tipos de observables que temos. HOT E COLD. Uma analogia aos tipos de observáveis seria como se o HOT fosse uma apresentação ao vivo, enquanto o cold um filme gravado. Hot publica eventos mesmo sem um subscrivber, enquanto o cold não.
- #10 Reactive Programming, um conceito que está cada vez mais presente em foruns de discussão e no mercado de trabalho. Mas afinal de contas, o que é o reactive programming? Se fossemos resumir em apenas 1 frase, eu diria… “Programação com fluxos (streams) de dados assíncronos” Mas veremos que é um pouco mais profundo que isso e no que isso impacta o framework da spring, webflux. Artigo Legal: https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
- #11 Antes de falar do framework em sí, temos que mostrar quem é o responsável por implementar a interface do “Reactive Stream” que vimos anteriormente. Ler slide… O Project Reactor é uma das implementações de reactive streams, assim como RxJava e Akka Streams Além de nos fornecer um meio de controlar os streams de dados, ele também nos fornece dois tipos de dados conhecidos no mundo reativo. Mono, quando você tem 0 ou 1 item e Flux, quando vocë tem 0 ou N itens. O encadeamento de métodos utilizando esses tipos fornece uma série de operadores que devem ser utilizados para resolver problemas de filtro e transformação de dados. Esses operadores garantem que o objeto vai ser tratado de forma exclusiva e sem concorrência.
- #13 Então quer dizer que reatividade é SEMPRE melhor e que o Spring Webflux se destaca frente ao tradicional Spring MVC, certo? Errado. Tudo depende do contexto. Assim como meu amigo Presuntinho adora ressaltar, não existe bala de prata e a reatividade não é uma exceção. É difícil dizer o que se sairia melhor em cada contexto, porém veja, se a stack inteira trabalhar bem com reatividade, desde o api gateway até o banco de dados, com certeza você terá um throuput maior. Se você tem alguma peça na sua stack que não trabalha bem com reatividade, provavelmente você terá baixos ganhos de performance. Além disso deve ser analisado se a equipe está pronta para pensar de forma reativa e se ela já tem a skill para desenvolver um sistema desse porte, caso contrário a equipe pode ser o gargalo. Devemos verificar também se vamos ter demanda para um througput maior, caso negativo, também não temos a necessidade real de implantar esse mecanismo. Rossen Stoyanchev, programador na Pivotal (empresa do spring), disse o seguinte quando apresentou o webflux pela primeira vez: “Cuidado ao escolher entre os dois, se sua aplicação já roda bem com mvc e você não tem nenhum problema com essa stack, não há motivos para trocar. Também devemos pensar nas nossas dependencias, se existem dependencias com comportamento bloqueante é melhor permanecem no spring mvc.” De acordo com ele no Webfux não é necessariamente mais rápido, mas pode se dar melhor com problemas de escalabilidade e eficiencia de uso dos recursos de hardware. Também pode se dar melhor com problemas de latencia. https://www.infoq.com/news/2017/12/servlet-reactive-stack/ Análise de performance: https://technology.amis.nl/software-development/performance-and-tuning/performance-of-relational-database-drivers-r2dbc-vs-jdbc/ Fonte da resposta curta: https://www.quora.com/Does-Spring-WebFlux-perform-better-than-Spring-MVC
- #15 Reactive Programming, um conceito que está cada vez mais presente em foruns de discussão e no mercado de trabalho. Mas afinal de contas, o que é o reactive programming? Se fossemos resumir em apenas 1 frase, eu diria… “Programação com fluxos (streams) de dados assíncronos” Mas veremos que é um pouco mais profundo que isso e no que isso impacta o framework da spring, webflux. Artigo Legal: https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
- #16 Reactive Programming, um conceito que está cada vez mais presente em foruns de discussão e no mercado de trabalho. Mas afinal de contas, o que é o reactive programming? Se fossemos resumir em apenas 1 frase, eu diria… “Programação com fluxos (streams) de dados assíncronos” Mas veremos que é um pouco mais profundo que isso e no que isso impacta o framework da spring, webflux. Artigo Legal: https://gist.github.com/staltz/868e7e9bc2a7b8c1f754