[BSB] primeiros passos com webflux

Slide 1

Slide 1 text

Programação reativa com Java Primeiros passos com Spring Webflux github.com/kamilahsantos in/kamila-santos-oliveira/ @kamilah_santos https://dev.to/kamilahsantos

Slide 2

Slide 2 text

Backend Developer github.com/kamilahsantos in/kamila-santos-oliveira/ @kamilah_santos https://dev.to/kamilahsantos

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Reactive Manifest https://www.reactivemanifesto.org/ @kamilah_santos

Slide 5

Slide 5 text

Responsivo O sistema responde em tempo hábil, se possível @kamilah_santos

Slide 6

Slide 6 text

Resiliente O sistema permanece responsivo a falhas @kamilah_santos

Slide 7

Slide 7 text

Elástico O sistema permanece responsivo em face de uma carga de trabalho variável. @kamilah_santos

Slide 8

Slide 8 text

Message Driven Os aplicativos reativos contam com a passagem de mensagens assíncronas para estabelecer um limite entre os componentes, garantindo acoplamento ﬂexível, isolamento e transparência @kamilah_santos

Slide 9

Slide 9 text

Reactive Streams Iniciativa para fornecer um padrão / guia / regras para processamento de ﬂuxo assíncrono com backpressure NIO @kamilah_santos

Slide 10

Slide 10 text

interface Flow.Publisher métodos para produzir streams e demais eventos @kamilah_santos

Slide 11

Slide 11 text

@kamilah_santos

Slide 12

Slide 12 text

interface Flow.Subscriber métodos para receber streams e demais eventos @kamilah_santos

Slide 13

Slide 13 text

@kamilah_santos

Slide 14

Slide 14 text

interface Flow.Subscription métodos para vincular o Publisher e o Subscriber. @kamilah_santos

Slide 15

Slide 15 text

@kamilah_santos

Slide 16

Slide 16 text

interface Flow.Processor deﬁne métodos para fazer algumas operações avançadas, como transformar itens de publishers para subscriber @kamilah_santos

Slide 17

Slide 17 text

@kamilah_santos

Slide 18

Slide 18 text

class SubmissionPublisher implements Flow.Publisher Producer ﬂexível de itens, em conformidade com a Reactive Streams. @kamilah_santos

Slide 19

Slide 19 text

@kamilah_santos

Slide 20

Slide 20 text

Reactive streams destinado a ambientes de tempo de execução (JVM), bem como protocolos de rede. https://github.com/reactive-streams/reactive-streams-jv m @kamilah_santos

Slide 21

Slide 21 text

Reactive streams o objetivo principal é deﬁnir a troca de dados de ﬂuxo através de um limite assíncrono. @kamilah_santos

Slide 22

Slide 22 text

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 ﬂuxos de dados assíncronos com backpressure NIO. @kamilah_santos

Slide 23

Slide 23 text

Functional Features Java 8+ @kamilah_santos

Slide 24

Slide 24 text

@kamilah_santos

Slide 25

Slide 25 text

@kamilah_santos

Slide 26

Slide 26 text

@kamilah_santos

Slide 27

Slide 27 text

@kamilah_santos

Slide 28

Slide 28 text

@kamilah_santos

Slide 29

Slide 29 text

@kamilah_santos

Slide 30

Slide 30 text

Conceitos de programação reativa @kamilah_santos

Slide 31

Slide 31 text

Backpressure Resistência ou força que se opõe ao ﬂuxo de dados desejado por meio do software. Feedback do receptor ao produtor de que ele não está suportando a carga @kamilah_santos

Slide 32

Slide 32 text

Stream Sequência de objetos que suporta vários métodos que podem ser operados para produzir um resultado @kamilah_santos

Slide 33

Slide 33 text

Stream vinculado a uma fonte de dados, um stream é capaz de emitir três eventos: @kamilah_santos

Slide 34

Slide 34 text

onNext() representa algum valor, vá para o próximo valor de uma lista @kamilah_santos

Slide 35

Slide 35 text

onError() houve um erro na execução @kamilah_santos

Slide 36

Slide 36 text

onComplete() no caso de eventos ﬁnitos, indica que foi concluído @kamilah_santos

Slide 37

Slide 37 text

Flux Pode emitir de 0 to N eventos, passando por OnNext (), OnComplete () e onError. @kamilah_santos

Slide 38

Slide 38 text

Mono Emite um evento ou nenhum (0 to 1 event). @kamilah_santos

Slide 39

Slide 39 text

Observable um observable pode passar mensagens de forma assíncrona. @kamilah_santos

Slide 40

Slide 40 text

Subscriber consome os dados recebidos da subscription @kamilah_santos

Slide 41

Slide 41 text

Publisher produz os dados que serão consumidos pela assinatura. @kamilah_santos

Slide 42

Slide 42 text

Subscription conexão entre o Subscriber e o Publisher @kamilah_santos

Slide 43

Slide 43 text

Cold Observable a sequência de eventos só é executada se o Observable tiver um subscriber associado @kamilah_santos

Slide 44

Slide 44 text

Hot Observable ele emite eventos independentemente de haver um subscriber associado @kamilah_santos

Slide 45

Slide 45 text

Por que o WebFlux foi criado? Spring WebFlux pode ser deﬁnido 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. @kamilah_santos

Slide 46

Slide 46 text

Por que o WebFlux foi criado? 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. @kamilah_santos

Slide 47

Slide 47 text

https://docs.spring.io/spring-framework/docs/5.0.0.BUILD-SNAPSHOT/spring-framework-reference/ html/web-reactive.html @kamilah_santos

Slide 48

Slide 48 text

Spring Webﬂux 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. @kamilah_santos

Slide 49

Slide 49 text

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. @kamilah_santos

Slide 50

Slide 50 text

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. @kamilah_santos

Slide 51

Slide 51 text

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. @kamilah_santos

Slide 52

Slide 52 text

Como as requests funcionam? @kamilah_santos

Slide 53

Slide 53 text

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) @kamilah_santos

Slide 54

Slide 54 text

@kamilah_santos

Slide 55

Slide 55 text

Com este modelo de design de API tradicional, não oferecemos suporte para Backpressure, a escrita da API é imperativa e, como já foi dito, funciona de forma síncrona e bloqueante @kamilah_santos

Slide 56

Slide 56 text

@kamilah_santos

Slide 57

Slide 57 text

@kamilah_santos

Slide 58

Slide 58 text

E no Webflux? @kamilah_santos

Slide 59

Slide 59 text

Neste modelo de requisição, para cada item deste Flux que é lido e retornado do banco de dados, um onNext () é chamado e quando atinge o último recebe um “sinal” de onComplete () ou se ocorre um erro, ele receberá um onError (). @kamilah_santos

Slide 60

Slide 60 text

@kamilah_santos

Slide 61

Slide 61 text

Os pedidos disparados por um cliente, são recebidos pelo Netty, que é o nosso servidor não bloqueante, que será recebido pelo loop de eventos, que irá receber este evento e enviá-lo, o adaptador reativo (reactor-netty) passará este para o dispatcher handler que é responsável pelo terminal para passar essas informações de volta ao cliente, isso ocorre de forma assíncrona e não bloqueante. @kamilah_santos

Slide 62

Slide 62 text

@kamilah_santos

Slide 63

Slide 63 text

O adaptador reativo geralmente é fornecido por uma biblioteca, aqui cobrirá o projeto do Reactor. @kamilah_santos

Slide 64

Slide 64 text

Project Reactor @kamilah_santos

Slide 65

Slide 65 text

É uma biblioteca baseada nas Reactive Streams Speciﬁcations, é 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). @kamilah_santos

Slide 66

Slide 66 text

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-common s), que mais tarde também foram implementados por RxJava2. @kamilah_santos

Slide 67

Slide 67 text

Seus módulos são ﬂuxos reativos abstratos e interoperáveis para facilitar o seu desenvolvimento, podendo ser utilizados com: Spring Frameworks Drivers 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. @kamilah_santos

Slide 68

Slide 68 text

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 @kamilah_santos

Slide 69

Slide 69 text

Reactor Netty é o servidor de nosso aplicativo NIO, usada para o desenvolvimento de servidores altamente escaláveis. @kamilah_santos

Slide 70

Slide 70 text

Reactor Test é responsável por apoiar testes reativos e asserções @kamilah_santos

Slide 71

Slide 71 text

Netty é possível trabalhar no nível do socket e criar seus próprios protocolos de comunicação @kamilah_santos

Slide 72

Slide 72 text

Netty Para essas conﬁgurações de servidor NIO, é bom ter conhecimento de threads, event loop, buffers e gerenciamento de memória @kamilah_santos

Slide 73

Slide 73 text

@kamilah_santos

Slide 74

Slide 74 text

Exemplo @kamilah_santos

Slide 75