TheDevConf 2020 - Paradigma reativo? Por dentro da programação reativa com Spring Webflux e Projeto Reactor - Trilha Design de Código e XP

Já ouviu falar de programação reativa? Nessa palestra vamos abordar os conceitos de programação reativa, reactive streams specification , RxJava, Spring Webflux e principalmente a biblioteca Reactor, passando pela utilização do Flux, Mono, Publisher, Subscriber e seus operadores. Também veremos como fazer sua primeira aplicação com Spring Webflux, Reactor e o Driver reativo do mongoDB

Transcript

1. PARADIGMA REATIVO? Kamila Santos Por dentro da programação reativa com Spring Webflux e Projeto Reactor
2. KAMILA SANTOS Desenvolvedora Backend Ame Digital Bacharel em ciência da computação Co organizadora das comunidades Perifacode, WoMakersCode e DevsJavaGirl
3. PARADIGMA REATIVO
4. PARADIGMA REATIVO É um paradigma de programação orientado a fluxos de dados/eventos, bem como a propagação dos mesmos de forma assíncrona.
5. PARADIGMA REATIVO Por trabalhar de forma assíncrona é altamente recomendada para lidar com grande volume de dados que sofrem grandes mudanças em tempo real.
6. PARADIGMA REATIVO Também é bastante utilizado em redes sociais (front e back) por funcionar orientado a ações do usuário que resultam em eventos.
7. MANIFESTO REATIVO
8. https://www.reactivemanifesto.org/
9. RESPONSIVO O sistema responde em tempo hábil, se possível
10. RESILIENTE O sistema permanece responsivo a falhas
11. ELÁSTICO O sistema permanece responsivo em face de uma carga de trabalho variável.
12. MESSAGE DRIVEN Os aplicativos reativos contam com a passagem de mensagens assíncronas para estabelecer um limite entre os componentes, garantindo acoplamento flexível, isolamento e transparência
13. RX JAVA
14. RXJAVA É uma implementação para a JVM das Reactie Extensions , que é uma biblioteca assíncrona e baseada em eventos que trabalha com sequências de observables.
15. RXJAVA Estende do padrão observer -> cada objeto chamado (subject), tem uma listas de dependentes (observers) que são notificados pelo subject automaticamente a cada mudança de estado por meio de seus operadores e métodos.
16. RXJAVA Suporta sequências de dados e eventos para compor suas sequências de eventos de forma declarativa.
18. REACTIVE STREAMS
19. REACTIVE STREAMS Iniciativa para fornecer um padrão / guia / regras para processamento de fluxo assíncrono com backpressure NIO
20. INTERFACE FLOW.PUBLISHER<T> métodos para produzir streams e demais eventos
22. INTERFACE FLOW.SUBSCRIBER<T> métodos para receber streams e demais eventos
24. INTERFACE FLOW.SUBSCRIPTION métodos para vincular o Publisher e o Subscriber.
26. INTERFACE FLOW.PROCESSOR<T,R> define métodos para fazer algumas operações avançadas, como transformar itens de publishers para subscriber
28. CLASS SUBMISSIONPUBLISHER<T> IMPLEMENTS FLOW.PUBLISHER<T> Producer flexível de itens, em conformidade com a Reactive Streams.
30. REACTIVE STREAMS destinado a ambientes de tempo de execução (JVM), bem como protocolos de rede.https://github.com/reactive-streams/reactive-streams-jvm
31. REACTIVE STREAMS o objetivo principal é definir a troca de dados de fluxo através de um limite assíncrono.
32. REACTIVE STREAMS seu escopo é encontrar um conjunto mínimo de métodos, interfaces e protocolos que irão descrever as operações e entidades necessárias para ter fluxos de dados assíncronos com backpressure NIO.
33. CONCEITOS DE PROGRAMAÇÃO REATIVA
34. BACKPRESSURE Resistência ou força que se opõe ao fluxo de dados desejado por meio do software. Feedback do receptor ao produtor de que ele não está suportando a carga.
35. STREAM Sequência de objetos que suporta vários métodos que podem ser operados para produzir um resultado
36. STREAM vinculado a uma fonte de dados, um stream é capaz de emitir três eventos:
37. ONNEXT() representa algum valor, vá para o próximo valor de uma lista
38. ONERROR() houve um erro na execução
39. ONCOMPLETE() no caso de eventos finitos, indica que foi concluído
40. FLUX Pode emitir de 0 to N eventos, passando por OnNext (), OnComplete () e onError.
43. OBSERVABLE um observable pode passar mensagens de forma assíncrona.
44. SUBSCRIBER consome os dados recebidos da subscription
45. PUBLISHER produz os dados que serão consumidos pela assinatura.
46. SUBSCRIPTION conexão entre o Subscriber e o Publisher
48. COLD OBSERVABLE a sequência de eventos só é executada se o Observable tiver um subscriber associado
49. HOT OBSERVABLE ele emite eventos independentemente de haver um subscriber associado
50. SPRING WEBFLUX
51. SPRING WEBFLUX Spring WebFlux pode ser definido como uma versão “paralela” ao já conhecido e amplamente utilizado Spring MVC (servlet), tendo como principal diferença o suporte para streams NIO reativos e por suportar o conceito de backpressure com o servidor Netty vindo por default embutido em seu arquitetura.
52. SPRING WEBFLUX A partir da versão 5.0 do Spring Framework temos uma parte reativa além da estrutura Servlet que já existia, cada módulo destes é opcional, você pode usar a parte Servlet, a parte reativa ou mesmo ambas em suas aplicações.
53. HTTPS://DOCS.SPRING.IO/SPRING-FRAMEWORK/DOCS/5.0.0.BUILD-SNAPSHOT/SPRING-FRAMEWORK-REFERENCE/HTML/WEB-REACTIVE.HTML
54. SPRING WEBFLUX Spring Webflux foi desenvolvido porque precisávamos de aplicativos não bloqueantes que pudessem trabalhar com um pequeno número de threads simultaneamente e que pudessem ser executados com alguns recursos de hardware.
55. SPRING WEBFLUX no Servlet 3.1, uma API NIO foi fornecida, mas seu uso não corresponde ao resto da API e a todos os conceitos por trás do Servlet, que possui contratos de bloqueio.
56. SPRING WEBFLUX Estes fatores foram decisivos para o desenvolvimento de uma nova API que fosse utilizada independentemente do tempo de execução e de forma não bloqueante, o que foi possível com os servidores (Netty por exemplo) que se consolidaram na operação assíncrona e não bloqueante.
57. SPRING WEBFLUX Outra razão é que o WebFlux torna mais fácil entender e usar conceitos de programação funcional / reativa. Com a adição de recursos funcionais do Java 8 e Flowable API no Java 9 , que permitiu ao Spring WebFlux ter functional endpoints e annotated controllers nos aplicativos.
58. COMO AS REQUESTS FUNCIONAM? Este modelo, dependendo do volume de requisições e da forma como foi desenvolvido, pode causar lentidão na sua aplicação e até mesmo um erro de Out Of Memory (este tipo de erro geralmente ocorre quando mantemos objetos por muito tempo ou tentamos processar muito de dados de uma vez)
60. E NO WEBFLUX?
63. PROJETO REACTOR
64. REACTOR É uma biblioteca baseada nas Reactive Streams Specifications, é totalmente não bloqueante e interage diretamente com a API Java funcional (Stream, Duration e Completable Future), para composição de elementos utilizando Flux e Mono em arquiteturas de microsserviços , oferecendo mecanismos de backpressure prontos para TCP, UDP e HTTP (incluindo sockets da web).
65. REACTOR Seus operators e schedulers podem suportar um grande volume de transferência (até 10 milhões de solicitações por segundo, de acordo com a documentação do Reactor https://projectreactor.io/), também foi a primeira biblioteca reativa a implementar alguns pontos sugeridos pela reactive streams applications( https://github.com/reactor/reactive-streams- commons), que mais tarde também foram implementados por RxJava2.
66. REACTOR Seus módulos são fluxos reativos abstratos e interoperáveis para facilitar o seu desenvolvimento, podendo ser utilizados com:Spring FrameworksDrivers e clientes (por exemplo CloudFoundry Java Client https://github.com/cloudfoundry/cf-java-client)- em protocolos / contratos como R2DBC (https://r2dbc.io/) e RSocket (https://rsocket.io/), por exemplo.
67. REACTOR CORE é a parte principal desta biblioteca, os outros módulos são dependentes dela, ela fornece tipos reativos que implementam um Publisher que fornece Flux e Mono
68. REACTOR NETTY é o servidor de nosso aplicativo NIO, usada para o desenvolvimento de servidores altamente escaláveis.
69. BENEFÍCIOS
70. BENEFÍCIOS não bloqueante, o que gera certo ganho de desempenho.
71. BENEFÍCIOS menos threads, menos memória usada / gasta
72. BENEFÍCIOS segue os princípios do manifesto reativo: aplicativos responsivos, resilientes, elásticos e orientados por mensagens.
73. PROBLEMAS
74. PROBLEMA Uma forma diferente de programação (programação declarativa)
75. PROBLEMAS Difícil de depurar (rastreamento de pilha mais complicado de entender).
76. SHOW ME THE CODE
85. DEMO EM: https://github.com/Kamilahsantos/TheDevConf-2020-ReactiveParadigm- Example
86. OBRIGADA <3 Demais redes sociais e demo no QRCode Linkedin https://www.linkedin.co m/in/kamila-santos- oliveira/ Twitter @kamilah_santos