Creating Future-Proof Spring Applications with Event Sourcing by Steve Pember @ Spring I/O 2024

[@felixnjunge78]

Steve this is simply amazing. Thank you!

[@avwie132]

Man you’re voice is amazing. You should be a voice actor or have a podcast at least

[@Mrhennayo]

That's clean enough As long as there's an history requirement, then I guess that's the best pattern Also the immutability contraint makes it resistant against bugs

[@TechTalksWeekly]

Steve's talk has been featured in the last issue of Tech Talks Weekly newsletter 🎉 Congrats! 👏

[@MrJohnBBQ]

Super cool. Just curious about the demo, why the switch from kotlin to java at some point? Was there some dependency that didn’t interop nicely for some reason?

[@jesprotech]

Great presentation and great example! Loved the presentation! Great job! 👍

[@Harve6988]

What does it mean "doesn't own the data"? Does event sourcing not work for say IoT or when you are collecting data from devices like logs as you don't control the data domain? Or is it more when it is a 3rd party api?

[@carlosabreu5012]

so good. With this you dont need a recurrent select or this refresh button to see changes in the client side. you can subscribe to the eventsource with js, and dissubscribe when you change the page. spring can manage it if your clients cant close the subscription. but thats one idea! think about it... like reactivity to a crud, you can bring this to any other business logic.

[@tobyzieglerrr]

great topic and good presentation, thanks

[@avwie132]

Event sourcing is such a beautiful theoretical architecture, however in practice there are a lot of drawbacks: - GDPR requirements on data storage - event versioning is a pain - navigating a code base with multiple event handlers can be very difficult - the mental overhead is harder than you think, making it difficult to onboard or have juniors in your team

[@ZdobywcaTitanQuestIT]

+ Undoing is overrated as well, with so many side effects realistically happening in larger apps. + Bug fixing can become twice as hard compared to regular orm based stuff

[@kligris]

Awesome!!

[@avalagum7957]

What problem does the event sourcing try to solve?

[@yootoobnoob123]

It tries to solve the problem that software applications change over time. Luckily that describes most software with more than zero users 😅

[@avalagum7957]

@@yootoobnoob123 > that software applications change over time that covers more than 99.99999% of the existing software applications. So, this solution is "one size fits all"? If yes, wow 🙂

[@jesprotech]

Event sourcing allows for applications to be more reactive and thus be able to deal with more simultaneous requests. Event sourcing allows for sourcing of events, which means creating non-blocking processing for each unit of work. Each data is stored and processed later. That way more resources are released more quickly.

[@avalagum7957]

@@jesprotech Does virtual thread solve the same problem?

[@Mig440]

​@@avalagum7957 no they do not. Virtual threads only live within the jvm while event sourcing is an architectural pattern for the entire tech stack including datastores.

[@ilkou]

**new architecture added to resume**