[Java Global Summit] - Evolution of java: from object orientation to reactive applications with Webflux

[Java Global Summit] - Evolution of java: from object orientation to reactive applications with Webflux

Let's talk about the principles of reactive programming and how Java has evolved since object orientation, the concepts of functional programming that started to come with Java 8 and how this led to the emergence of Webflux. And we will see an example of an API with Spring Webflux using the Reactor library and the asynchronous server Netty.

Transcript

  1. Evolution of java: from object orientation to reactive applications with

    Webflux KAMILA SANTOS OLIVEIRA @kamilah_santos Global Summit for Java devs'20
  2. @kamilah_santos Hi Folks,i’m Kamila Santos Backend Developer github.com/kamilahsantos in/kamila-santos-oliveira/ @kamilah_santos

    https://dev.to/kamilahsantos
  3. @kamilah_santos Communities

  4. @kamilah_santos Object-oriented programming, the basics

  5. @kamilah_santos Abstraction We need to imagine what that object will

    do within our system
  6. @kamilah_santos Abstraction - identity Identity to the object that we

    are going to create
  7. @kamilah_santos Abstraction - attributes Characteristics of this object, the so-called

    attributes
  8. @kamilah_santos Abstraction - methods This object will be able to

    perform actions, which we call methods
  9. @kamilah_santos Encapsulation "protect / hide" objects from the rest of

    the application, we use getters and setters and access modifiers to define and access these values
  10. @kamilah_santos Polymorphism We changed the inner workings of a method

    inherited from the parent object
  11. @kamilah_santos inheritance daughter class inherits behaviors from parent class

  12. @kamilah_santos Reactive Manifest

  13. @kamilah_santos https://www.reactivemanifesto.org/

  14. @kamilah_santos Responsive The system responds in a timely manner, if

    possible
  15. @kamilah_santos Resilient The system remains responsive to failures

  16. @kamilah_santos Elastic The system remains responsive in the face of

    a variable workload.
  17. @kamilah_santos MESSAGE DRIVEN Reactive applications rely on asynchronous message passing

    to establish a limit between components, ensuring flexible coupling, isolation and transparency
  18. @kamilah_santos Reactive streams - Java 9 Flowable API Initiative to

    provide a standard/guide/rules for asynchronous stream processing with non-blocking back pressure
  19. interface Flow.Publisher<T> methods to produce items and control signals @kamilah_santos

  20. @kamilah_santos

  21. interface Flow.Subscriber<T> methods to receive those messages and signals @kamilah_santos

  22. @kamilah_santos

  23. interface Flow.Subscription methods to link both the Publisher and the

    Subscriber. @kamilah_santos
  24. @kamilah_santos

  25. interface Flow.Processor<T,R> defines methods to do some advanced operations like

    chaining transformations of items from publishers to subscribers @kamilah_santos
  26. @kamilah_santos

  27. class SubmissionPublisher<T> implements Flow.Publisher<T> flexible producer of items, compliant with

    the Reactive Streams initiative . @kamilah_santos
  28. @kamilah_santos

  29. Reactive streams aimed at runtime environments (JVM) as well network

    protocols. https://github.com/reactive-streams/reactive-streams-jvm @kamilah_santos
  30. Reactive streams the main goal is define the exchange of

    stream data across an asynchronous boundary. @kamilah_santos
  31. Reactive streams your scope is to find a minimal set

    of methods, interfaces and protocols that will describe the necessary operations and entities to have asynchronous streams of data with NIO back pressure. @kamilah_santos
  32. Functional Features Java 8+ @kamilah_santos

  33. @kamilah_santos

  34. @kamilah_santos

  35. @kamilah_santos

  36. @kamilah_santos

  37. @kamilah_santos

  38. @kamilah_santos

  39. Reactive Concepts @kamilah_santos

  40. Backpressure Resistance or force opposing the desired flow of data

    through software. @kamilah_santos
  41. Stream Sequence of objects that supports various methods wich can

    be operated to produce a result @kamilah_santos
  42. Stream linked to a data source, a stream is capable

    of emitting three events: @kamilah_santos
  43. onNext() represents some value, go to next value of a

    list @kamilah_santos
  44. onError() there was an error in the execution @kamilah_santos

  45. onComplete() in the case of finite events, indicates that it

    has been completed @kamilah_santos
  46. Flux It can emit 0 to N events, also passing

    through OnNext (), OnComplete () and onError. @kamilah_santos
  47. Mono Emits at most one event (0 to 1 event).

    @kamilah_santos
  48. Observable an observable can pass messages asynchronously. @kamilah_santos

  49. Subscriber consumes the data received from the subscription @kamilah_santos

  50. Publisher produces the data that will be consumed by subscription.

    @kamilah_santos
  51. Subscription connection between a Subscriber and a Publisher @kamilah_santos

  52. Cold Observable the sequence of events is only executed if

    the Observable has an associated subscriber @kamilah_santos
  53. Hot Observable it issues events regardless of whether there is

    an associated subscriber @kamilah_santos
  54. Why was webflux created? Spring WebFlux can be defined as

    a version “parallel” to the already known and widely used Spring MVC (servlet) , having as main difference the support for reactive NIO streams and for supporting the concept of backpressure with Netty server coming by default embedded in its architecture. @kamilah_santos
  55. Why was webflux created? From version 5.0 of the Spring

    Framework we have a reactive part in addition to the Servlet structure that already existed, each module of these is optional, you can use the Servlet part, the reactive part or even both in your applications. @kamilah_santos
  56. Why was webflux created? https://docs.spring.io/spring-framework/docs/5.0.0.BUILD-SNAPSHOT/spring-framework-reference/html/w eb-reactive.html @kamilah_santos

  57. Spring Webflux was developed because we needed (we developers) non-blocking

    applications that were able to work with a small number of threads simultaneously and that could be run with a few hardware resources. @kamilah_santos
  58. in Servlet 3.1 an NIO API was provided, but its

    use does not match the rest of the API and all the concepts behind Servlet, which has blocking contracts. @kamilah_santos
  59. These factors were decisive for the development of a new

    API that was used independently of the execution time and in a non-blocking way, which was possible with the servers (Netty for example) that consolidated themselves in the asynchronous and non-blocking operation. @kamilah_santos
  60. Another reason is that WebFlux makes it easier to understand

    and use functional / reactive programming concepts. With the addition of functional features from Java 8 and Flow API in Java 9 that allowed Spring WebFlux to have functional endpoints and annotated controllers in the applications. @kamilah_santos
  61. How requests works in the servlet model? @kamilah_santos

  62. This model, depending on the volume of requests and the

    way it was developed, can cause slowness to your application and even an Out Of Memory error (this type of error usually occurs when we keep objects for a long time or try to process a lot of data at once) @kamilah_santos
  63. @kamilah_santos

  64. With this traditional API design model, we do not support

    Backpressure, the writing of the API is imperative and as has been said before, it works in a synchronous and blocking way @kamilah_santos
  65. @kamilah_santos

  66. @kamilah_santos

  67. And in Spring WebFlux? @kamilah_santos

  68. In this request model, for each item of this Flux

    that is read and returned from the database, an onNext () is called and when it reaches the last one it receives an “signal” from onComplete () or if an error occurs, it will receive an onError (). @kamilah_santos
  69. @kamilah_santos

  70. The requests triggered by a client, are received by Netty,

    which is our non-blocking server, which will be received by the event loop, which will receive this event and dispatch it, the reactive adapter (reactor-netty), will pass this on to the dispacther handler who is in charge of the endpoint to pass this information back to the client, this occurs asynchronously and not blocking. @kamilah_santos
  71. @kamilah_santos

  72. The reactive adapter is usually provided by a library,here will

    cover the Reactor project. @kamilah_santos
  73. Project Reactor @kamilah_santos

  74. It is a library based on Reactive Streams Specifications, it

    is totally non-blocking and interacts directly with the functional Java API (Stream, Duration and Completable Future), for composing elements using Flux and Mono and suitable (and widely used) in microservices architectures, offering ready backpressure mechanisms for TCP, UDP and HTTP (including web sockets). @kamilah_santos
  75. Its operators and schedulers can support a large transfer volume

    (up to 10 million requests per second, according to Reactor documentation https://projectreactor.io/), it was also the first reactive library to implement some points suggested by reactive streams commons (https://github.com/reactor/reactive-streams-commons), which were later also implemented by RxJava2. @kamilah_santos
  76. Its modules are interoperable and abstract reactive streams to facilitate

    their development, being able to be used with: - Spring Frameworks - Drivers and Clients (for example CloudFoundry Java Client https://github.com/cloudfoundry/cf-java-client) - in protocols / contracts like R2DBC (https://r2dbc.io/) and RSocket (https://rsocket.io/), for example. @kamilah_santos
  77. Reactor Core is the main part of this library, the

    other modules are dependent on it, it provides reactive types that implement a Publisher that provides Flux and Mono @kamilah_santos
  78. Reactor Netty is the server of our application is a

    non-blocking input and output structure (NIO), used for the development of highly scalable servers. @kamilah_santos
  79. Reactor Test is responsible for supporting reactive testing and assertions

    @kamilah_santos
  80. Netty it’s possible to work at the socket level and

    create your own communication protocols @kamilah_santos
  81. Netty For these NIO server configurations it is good to

    have knowledge of threads, event loop, buffers and memory management @kamilah_santos
  82. @kamilah_santos

  83. Show me the code!! @kamilah_santos

  84. Benefits @kamilah_santos

  85. - non-blocking, which generates a certain performance gain. - fewer

    threads, less memory used / spent - clearer view of functional features - processes different forms of request asynchronously @kamilah_santos
  86. - follows the principles of the reactive manifest: responsive, resilient,

    elastic and message-driven applications. - Backpressure - Using Reactor we have: greater readability of the code, a wide variety of operators to manipulate the data and a high level of abstraction. @kamilah_santos
  87. Problems @kamilah_santos

  88. - A different way of programming (declarative programming) - Difficult

    to debug (stack trace more complicated to understand). - Not all database drivers are fully ready for reactive programming. @kamilah_santos
  89. When use @kamilah_santos

  90. - If you have fast producers (faster emission of information),

    and low consumers (slow and blocking consumers), without backpressure support. - Variable traffic - Constant calls to the database and that database already has a reactive driver, the switch to webflux can decrease latency time. - Many streams, events in the application. - When this service is consumed via mobile and has a high volume of traffic. @kamilah_santos
  91. When not use @kamilah_santos

  92. - if your application does not have a very high

    traffic volume, it does not have multiple request sources - If there is no accumulation of requests, it occurs due to blocking processes. - If the dependencies already used in your services are blocking @kamilah_santos
  93. Thanks!! My contacts Example @kamilah_santos

  94. Thanks!! https://tech.io/playgrounds/929/reactive-programming-with-reactor-3/transform https://www.callicoder.com/reactive-rest-apis-spring-webflux-reactive-mongo/ http://reactivex.io/languages.html https://www.journaldev.com/20723/java-9-reactive-streams https://projectreactor.io/ http://www.trieu.xyz/2019/04/netty-cookbook.html https://dzone.com/articles/build-a-simple-netty-application-with-and-without https://www.baeldung.com/netty https://developer.okta.com/blog/2018/09/21/reactive-programming-with-spring

    https://speakerdeck.com/olehdokuka/get-reactive-with-project-reactor-and-spring-5 https://speakerdeck.com/kamilahsantos/2020-d0013e50-afdf-4e9c-b411-7f22d2f3d64c https://speakerdeck.com/kamilahsantos/tdc-floripa-melhorando-a-performance-e-legibilidade-de-aplicacoes-java-com-spri ng-web-flux https://www.baeldung.com/spring-webflux https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html https://docs.spring.io/spring-framework/docs/5.0.0.BUILD-SNAPSHOT/spring-framework-reference/html/web-reactive.html @kamilah_santos