Allow to define source of default streams when publishing events

[swistak35]

Allow to define source of default streams when publishing events

[mostlyobvious]

Does it assume you always append one event, as in the examples? If it allows many events, does it group them by streams and executes multiple appends — one per stream?

My gut feeling is — this is fine for a framework on top of RES. And then perhaps a definition of go-to stream should be close to the definition of the event.

[swistak35]

Does it assume you always append one event, as in the examples? If it allows many events, does it group them by streams and executes multiple appends — one per stream?

I was thinking that there's no need to consider multiple events when doing StreamsNameProvider#call, but it can be interesting idea to put the grouping logic (which I can imagine, there can be more than one), into StreamsNameProvider default implementation. So actually, idd, I'd change the API to #call(events)

My gut feeling is — this is fine for a framework on top of RES.

Where is it then (that framework)? I see ourselves blocking from implementing multiple slightly opinionated aspects of event-driven library (versioning, data structure validation, this issue) because it won't fit the RES-core (so to speak), and in the meantime these will likely get reimplemented in each project. And being able to specify (any implementation of) StreamsNameProvider isn't even that opinionated 🙃

I don't see a problem in reimplementing per se (we don't owe anyone particular features), but with that we're blocking ourselves from implementing smarter RES-Browser. It won't be easy to implement some, for example, versioning functionality on the browser without at least providing some commonly agreed API on it (like "What was the previous version of that event?").

And then perhaps a definition of go-to stream should be close to the definition of the event.

That I agree, the example was just to be simple example, but #call can do anything having event object at hand

[swistak35]

As an additional highlight, if you're worried about backwards compatibility, we may mark this as experimental feature for some time: https://railseventstore.org/docs/v2/maintenance_policy/#experimental-features