Mastering Event Sourcing in Rails Simplified

Host

Welcome back to the Boring Rails Podcast! I'm your host, and today we're diving into the intriguing world of event sourcing. Now, I know what you're thinking—it sounds overly complicated and filled with jargon. But fear not! We're joined by an expert who’s here to break it down into simple terms. So, let’s welcome our guest!

Expert

Thanks for having me! I’m excited to discuss event sourcing, especially because I believe it can be made accessible to everyone, even those who might feel overwhelmed by the terminology.

Host

Absolutely! So, to start us off, could you explain what event sourcing actually is?

Expert

Sure! At its core, event sourcing is a way of storing the state of your application as a series of events. Instead of just saving the current state, you keep a log of all the actions that led to that state. Think of it like a diary for your app, where each entry details what happened and when.

Host

That makes it sound much more manageable! But why would developers want to use event sourcing in their apps?

Expert

Great question! One of the key benefits is that it allows for better tracking of changes over time. For instance, if a user updates their profile, rather than just saving the new profile directly, you'd record an event that says, 'Profile was updated.' This way, you can easily audit changes or even undo actions if needed.

Host

Interesting! So, it’s like having a backup of all user actions? But I've heard event sourcing can get pretty complex.

Expert

Yes, it often comes with terms like 'aggregate root' and 'projections' that can confuse people. However, I've been experimenting with a simplified version that I like to call 'event sourcing for smooth brains.' You can implement it using just ActiveRecord and basic Rails callbacks.

Host

That sounds more approachable! Can you share an example of how this works in a Rails app?

Expert

Absolutely! Let’s say you have a simple blog application. When a user creates a post, instead of just saving the post, you’d trigger a callback that logs an 'PostCreated' event. This event can be stored in an events table. Later, if you want to show a timeline of posts or revert changes, you can simply look at the events rather than the current state.

Host

I love how practical that sounds! It seems like it could simplify some really complex features.

Expert

Exactly! The beauty of this approach is that it allows developers to work within the Rails framework they're already familiar with while embracing the benefits of event sourcing without the steep learning curve.

Host

This has been such an enlightening discussion! For our listeners who want to dive deeper into this topic, what resources would you recommend?

Expert

I’d suggest checking out my article on event sourcing for smooth brains, where I dive into the implementation details and provide some code snippets. It’s a good starting point for anyone interested!

Host

Fantastic! We’ll link that in the show notes. Thank you so much for joining us today and demystifying event sourcing!

Expert

Thank you for having me! Stay boring!