Survival Tips on Project Reactor and Spring WebFlux

Transcript

1. Survival Tips on Project Reactor and Spring WebFlux Yuriy_Artamonov
2. Plan 1. Why do we use Reactive on JVM 2. Existing tools and resources to simplify it 3. How you can improve it for your team 2
3. Are you still here?
4. Project Reactor Reactor is a fully non-blocking reactive programming foundation for the JVM, with efficient demand management. val users: Flux<User> return users .map { it.email } .flatMap { sendEmail(it) } 4
5. Mono, an Asynchronous 0-1 Result The following image shows how a Mono transforms an item:
6. Flux, an Asynchronous Sequence of 0-N Items The following image shows how a Flux transforms items:
7. Motivation ▪ Workloads are IO-bounded ▪ Asynchronous processing ▪ Scalability 7
8. 8 We share Toolbox Enterprise knowledge
9. Tip #1 Learn Some Functional Programming 1. Java Stream / Kotlin Sequence 2. Optional 3. Try & Either 4. .map, .flatMap, .zip concepts 9
10. Tip #2 Switch to Kotlin 1. Easier to write tons of lambdas 2. Nullability under control 3. Cleaner syntax with less () and ; 4. Simpler DI and data classes 10
11. Java Controller
12. Kotlin Controller
13. Tip #3 Check Operators FAQ and Diagrams Diagrams for streams in JavaDoc: projectreactor.io/docs/core/release/reference/#which-operator 13
14. Sometimes it is hard to understand errors 14
15. Tip #4 Enable Tracebacks ▪ Reactor Debug mode ▪ Instrumentation for production Maven: io.projectreactor:reactor-tools projectreactor.io/docs/core/release/reference/#reactor-tools-debug Error has been observed at the following site(s): *________Flux.map ⇢ at guide.FakeRepository.findAllUserByName(FakeRepository.java:27) |_ Flux.map ⇢ at guide.FakeRepository.findAllUserByName(FakeRepository.java:28) |_ Flux.filter ⇢ at guide.FakeUtils1.lambda$static$1(FakeUtils1.java:29) |_ Flux.transform ⇢ at guide.GuideExtraTests.withDeepTraceback(GuideExtraTests.java:39) |_ Flux.elapsed ⇢ at guide.FakeUtils2.lambda$static$0(FakeUtils2.java:30) |_ Flux.transform ⇢ at guide.GuideDebuggingExtraTests.withDeepTraceback(GuideExtraTests.java:40) 15
16. Tip #5 Develop with reactor-debug-agent 1. Add reactor-tools to classpath 2. Enable ReactorDebugAgent in code or via IDE Settings ReactorDebugAgent.init(); 16
17. Debug with pleasure! Now check additional frames and their results. 17
18. Blocking in Reactive Systems Want to have such a nice picture in your VisualVM? Try wrk!
19. Tip #6 Avoid Blocking Calls 19
20. Guess What is Going On 1. Prints “data is :suffix” 2. Throws exception 3. Does not print anything
21. Tip #7 Always Return Publisher 1. You must always return publisher to the caller 2. But! Keep in mind Fire-and-Forget idiom 21
22. Tip #8 Do Not Subscribe Manually subscribe() call in your code is usually a code smell. 22
23. Tip #9 Do Not Throw Project Reactor will handle throws, but throw is harmfull for your system performance! 23
24. Tip #10 Squash Operators Operators in reactive world have overhead: queues, hooks, more objects. 24
25. Help Your Team! 25
26. Trap #1 Dangerous Flux.flatMap { } Get many results from database and then start network requests to a thirdparty API in parallel for all of them. What can go wrong? 26
27. Structural Search for Inspections Check code without plugin: ▪ Enable Inspections - Structured Search Inspection ▪ Setup search templates Example: @Inject $Field$ 27
28. Trap #2 Mapping Mono<Void> myService.process("a") // returns Mono<Void> .zipWith(myMethod.process("b"), combinator) .subscribe(); See: projectreactor.io/docs/core/release/reference/#faq.monoThen 28
29. FlatMap on Mono<Void> Easy to miss in Kotlin with implicit lambda parameter 29
30. Trap #3 Mysterios Mono<Mono> Refactor your code and sometimes this appears as a result: 30
31. Questions ? Twitter: @Yuriy_Artamonov
32. Recommended Talks ▪ Sergei Egorov - Do’s and Don’ts: Avoiding First-Time Reactive Programmer Mines ▪ Simon Basle - Flight of the Flux: A Look at Reactor Execution Model ▪ Phil Clay - Avoiding Reactor Meltdown