Downloaded 23 times
More Related Content
![[Webinar]: Working with Reactive Spring](https://cdn.slidesharecdn.com/ss_thumbnails/working-wth-reactive-spring-190607114059-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Reactive programming
Reactive programming
- 1.
- 2. Evolution of programming Past(10-15years ago) Monolith applications Run in App server Does not embrace Distributed Systems. Today • Micro services • Run it in cloud. • Embraces Distributed systems
- 3. Expectations of theApp: Scale based on the load. Use resources efficiently. Latency or Response Time should be faster.
- 4. Spring MVC Request/ResponseFlow-Type1
- 5.
- 6. Handling Concurrent Requests Managed by the below property server.tomcat.max-threads By default it can handle 200 connections Can be overridden in application.properties or application.yml file Each thread takes some memory. Common stack size is 1MB. Higher the thread pool size, Higher the memory consumption. Applications really perform poor with less memory available.
- 7. How it ishandled today ? Load is Handled today with horizontal scaling. Kubernetes or some container orchestration.
- 8. Handling concurrent Requests Limitations on handling many concurrent users. Move away from “Thread per Request Model”.
- 9. Traditional REST APIDesign Imperative Style APIs • Top-down approach
- 10. Traditional REST APIDesign
- 11. Traditional REST APIDEsign Need to make calls asynchronous, basically non blocking. Currently in Java we have: Callbacks Future Completable Future complex Returns Future instance Supports functional style API No return value Hard to compose multiple asynchronous operations. Easy to compose multiple asynchronous operations Code is hard to read and maintain. Not a great fit asynchronous call with multiple items.
- 12. Traditional REST APIDesign: • Applications crash with Out of Memory error. • Client might be overwhelmed with huge data.
- 13. Traditional REST APIDesign: How to avoid this from happening ? • Imperative Design
- 14. Summary on TraditionalREST API Design: Limit on the number of Concurrent users. Synchronous and Blocking. Imperative Style APIs No Back Pressure support.
- 15. Better API Design: Asynchronous and Non Blocking. Move away from Thread per request model. Use fewer Threads. Back pressure compatible.
- 16. Reactive Programming Newprogramming paradigm. Asynchronous and Non Blocking. Data flow as an Event/Message Driven stream. Functional Style code. Back pressure on Data Streams.
- 17. Data flow asan Event Driven stream One event or message for a every result item from Data source. Data Sources: Data base, External service, File etc. One Event or message for completion or error.
- 18. Data flow asan Event Driven stream • OnNext(item) – Data stream events • OnComplete() -> Completion/Success • OnError()->Error event
- 19. Reactive Stream Specification Specification or Rules for a Reactive Stream. Specification created by :Pivotal, Netflix, lightbend,twitter etc. https://github.com/reactive-streams/reactive-streams-jvm Publisher Subscriber Subscription Processor
- 20. Publisher Represents theData Source ( Data base, External Services etc).
- 21.
- 22.
- 23.
- 24.
- 25.
- 26. Reactive Libraries Implementationsof Reactive Streams Specification. RxJava Reactor Flow Class- JDK 9 • Project Reactor • https://projectreactor.io/
- 27. Project Reactor(reactor-core) Fluxand Mono Reactive types of project reactor Flux-Represent 0 to N elements Mono represents 0 to 1 element
- 28. Flux- 0 toN elements https://projectreactor.io/docs/core/release/api/reacto r/core/publisher/Flux.html
- 29. Mono-0 to 1elements https://projectreactor.io/docs/core/release/api/reacto r/core/publisher/Mono.html
- 30. Building Reactive RESTFULAPIs using Spring Boot/WebFlux https://spring.io/
- 31. Spring WebFlux –Non Blocking Request/response
- 32. Spring WebFlux –Request/response
- 33. Spring WebFlux vsSpring MVC
- 34. Netty - Asynchronous Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Being asynchronous – Frees us from the blocking calls. Handles large number of connections. Events in Netty Client requesting for a new connection is treated as an event. Client requesting for data is treated as an event. Client posting for data is treated as an event. Errors are treated as event.
- 35. Netty - Channel Channel- represents the connection between the client and server.
- 36. Netty – EventLoop
- 37.
- 38.
- 39. EventLoopGroup How manyEventLoopGroup are there in Netty ?
- 40.
- 41.