- and another stream that construct a logical relationship between ActiveRecords which have been created through events (ActiveRecord creation -> event -> N ActiveRecord creation/updates)* leads to one stream per ActiveRecord op, it's a way to link an event to an ActiveRecord :)

No worries! I made a second blogpost explaining how I used streams to create a causality graph of my ActiveRecords, and by design they shouldn't be too long:
- causality and causation streams shouldn't contain more than 5 events per stream
- user stream which should be < 200 atm

private discord with a "bluesky posts" channel for me 😅

pretty cool, is it possible to see what HTML is like? :)

Sorry, you're my rubber duck 😅 but streams will help me on 90% of the cases because I'll have a common denominator (for instance, user) but I've dived into correlation and causation and instead of creating entries in additional tables, I'll link events between them. Next blogpost!

But as my events have a relationship with my ActiveRecords, it should be redundant.

And while I'm on it, I may link events with causality and correlation at the same time I link ActiveRecords. So I can have a full graph of ActiveRecords and Events relationship.

And this is because a RailsEventStore's event will never create anotheR. But, as 95% of the ActiveRecords I instantiate are linked to an User, I could :
- publish the events to the stream "User$#{user_uuid}"
- debug the events that have been triggered for a specific user thanks to this stream

What I introduce in my additional tables is a link between those ActiveRecords, especially if there is a causation through RailsEventStore events, as seen if the graph below.
A causation between events isn't the most important information for me.

Problem is, I don't want my colleagues to bother with additional infos they should provide to the ActiveRecord creation, such as `Email.new(source_event: ...)`
But! I would like to know how that email has been triggered, which in fact is caused by an User creation

Finally watched it! Streams will help me but solely mixed with my additional tables.
Unfortunately, there's no direct link between events: I create an User instance, a handler reacts to UserCreated event, the handler may create an Email instance, and a handler reacts to EmailCreated to send an email

and what's the easiest migration, if possible?
ease the UI/UX of an app with good performances
or improve the performances of an easy-to-use app?
considering a large codebase

there's no configuration for the LLM provider right? havn't found it in the docs. not really confident about sending my codebase too, while Cursor has a very clear privacy configuration

thanks! I'll watch soon :)

Glad you liked it! I love your library and I've strongly advocated to use it in my team. Currently reading Domain-driven Rails :)

But I'll take a better look at streams!

I haven't tbh, for debugging, I manually created tables which link the model which automatically triggers the create/update event to the different models that have been created from handlers, so I can construct a graph of causation.
User <-> UserCreated <-> handler <-> created models

Great job, you're not far away from a complete events framework which seems promising. I'll inspire myself from your work to try to build an UI which relies on my API and I'll tag you once I post about it.

Thanks a lot. Yes, I'm using RailsEventStore. I would like to visualise a timeline of records ops, and those records may be created from handlers reacting to events, which are triggered after a record creation/update. I just published a blog post that you can find on my profile if you're curious