From Web to Flux: Tackling the Challenges of Reactive Programming By Victor Rentea
Вставка
- Опубліковано 2 жов 2023
- Ready for a deep dive into the world's most challenging programming paradigm? Reactive programming can simplify asynchronous and event-driven applications, but without a strong understanding, it can lead to frustration, recurring patchwork, missed deadlines, and costly bugs.
In this intensive three-hour session, we'll transition a traditional Spring application to WebFlux, revealing patterns and anti-patterns when working with repositories, REST APIs, queues, and legacy libraries. You'll gain a clear understanding of often overlooked but critical aspects like subscribe signal, errors, cancellation, and signal loss. As a bonus, we'll debate the future of Reactive vs Virtual Threads, production-ready in Java 21.
This session is crucial for developers already working with reactive programming or those intending to make the leap.
VICTOR RENTEA
Victor is a Java Champion with two decades of experience, passionate about architecture, refactoring, and unit testing. He’s the founder of the world’s largest developer community on these topics: European Software Crafters. Today Victor helps companies throughout Europe raise the bar via consultancy and intense training workshops. You can find dozens of past conference talks, a blog, and his training offer on victorrentea.ro - Наука та технологія
![[VDCLUJ2023] Victor Rentea - Clean Code, Two Decades Later](/img/n.gif)
What a showman 🙌🏼 I have never had this much fun with anything related to reactive programming!
Had almost given up on reactive until this guy showed up 👏👏
The best talk about reactive programming that I had ever watched, with case by case.
Great performance and presentation style. I really enjoyed it!
Very well done presentation. Thank you.
Best video on reactive webflux
Amazing talk. It helped me grasp some of the concepts of reactive i had not understood till now. Thanks!
Does anyone know what tool he is using to all the arrows?
Edit: It's ScreenBrush app for Mac.
Love the way you teaches us!
Thanks for the awesome content and what an engaging and entertaining talk!!
Project Loom equivalent presentation would be interesting to compare 😇
Very good explanations and I really liked playing the right sounds at the right time 😂
1:39:31 i wasn't ready for it! xD
I have literally been through this whole learning curve with some folks how had not programmed in scala as I had. It was complete carnage 😂
any chance sharing the repo?
amazing!!!
1:50:50 isn't row 50 Mono too? why there is no need to add a return something there too?
delayUntil subscribes to the inner code but returns the original item, which is the saved post from line 43 in this case. You can think of it like it's a procedure which executes its body, but then returns its argument (something like "Long myProc(Long arg) { return arg }"). That's why you can map this saved post into a Long using getId and return that ID as Mono.
Reactive programming is cool for the kind of tasks you show in your presentation like CRUD operations. When it comes to projects where we have a very complex business domain, there are many different exceptions, rules, checks and so on reactive code becomes harder and harder to maintain. We have a situation where we have pipelines of 10 lines each with a Map/FlatMap for example. Not to mention how to diagnose the error in production or performance issue. I don't wish this on anyone. In summary, reactive programming is cool for easy applications, building data transfers but nothing more. Peace
how? if every function is total combining those will give a total function. To better understand performance pure functions can be compared to imperative style coding using local mutable state, ex. for-loops instead of recursion. And due to referential transparency different coding styles may be mixed as long as they stay pure and total.
If your machine cannot process data coming to it fast enough, then you use reactive to tell the data producer to slow down. Does that mean the data producer has some way to hold the data? Does that mean that instead of holding the data in our machine to gradually process it, we hold the data in the data producing machine to gradually release it? Does that mean we only move our issue from this machine to another machine?
The idea is to have an end-to-end reactive chain, where each part takes care of their responsibility, until the final publisher. So if you're using a mongodb reactive driver as the final publisher, it can take care of the "tough" job of how to handle backpressure, and the intermediate producers and consumers just have to take care of propagating it to the source. So the "issue" keeps getting propagated till it becomes mongodb's issue, which knows how to deal with it. (Disclaimer: This is a very simplistic view for the sake of a direction towards the answer.)
Ideally, the producers produce, the consumers consume. Typically there's a buffer in the middle ( databases, message queues, kafka topics, ... etc).
@@phanvanhoa if I'm getting data from a database, how can I tell the db to give me data slowly enough so that I can consume it without using reactive?
awesome
Impressive as it is, Virtual Threads make 99% of it obsolete.
Java 21, the Reactive webflux Killer?
Lord have mercy on those that have to read and maintain this kind of code, not to mention those that are new to this kind of project. Just horror and nightmares. Luckily there are other ways in the world.
I have read and maintaining such application. What are the other ways you suggest ?
Tomorrow Java 22 comes out with the 2nd preview version of “structured concurrency” where you can write blocking code with 1,000,000 virtual threads and clear stack traces. Then you can write obvious code that scales without it needing to use a reactive framework that must do complex things to juggle traditional threads.