Loved the talk. It is as good overall and even better than many of Greg Young's talks on this. I particularly appreciate the code samples in Kotlin and the considerable time spent on common questions and answers.
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
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.
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
+ 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
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?
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?
@@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 🙂
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 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.
Loved the talk. It is as good overall and even better than many of Greg Young's talks on this. I particularly appreciate the code samples in Kotlin and the considerable time spent on common questions and answers.
Steve this is simply amazing. Thank you!
Steve's talk has been featured in the last issue of Tech Talks Weekly newsletter 🎉
Congrats! 👏
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
Man you’re voice is amazing. You should be a voice actor or have a podcast at least
Great presentation and great example! Loved the presentation! Great job! 👍
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.
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
+ 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
great topic and good presentation, thanks
Awesome!!
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?
**new architecture added to resume**
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?
What problem does the event sourcing try to solve?
It tries to solve the problem that software applications change over time. Luckily that describes most software with more than zero users 😅
@@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 🙂
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.
@@jesprotech Does virtual thread solve the same problem?
@@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.