4 ms·
Even worse in my case, we are using event sourcing, but the client reads the Eventstore streams indirectly. It's terribly uncomfortable being the only one on a
by cuddlecake 7y ago
Even worse in my case, we are using event sourcing, but the client reads the Eventstore streams indirectly. It's terribly uncomfortable being the only one on a team of 7 who thinks this is terrible.
- pgwhalen 7y agoCan you describe what you mean by indirectly?
- Nimelrian 7y agoNot the person you're responding to, but I was on a team which probably did the same thing. Instead of listening directly to the event store for events you have another non-abstracting layer on top and listen to that. A sensible architecture would have that layer be an abstraction layer for business use cases, so instead of listening to "user-created", "user-edited" and "user-deleted" events and rebuilding the user state in the consumer every time an event is fired, you'd have that layer expose a single user state stream. The rebuilding is handled entirely within the layer. Many people skip that and just re-expose the "primitive" streams of the event store, because they read "don't expose your persistence layer" and skipped the important ", expose the business state layer instead" which usually comes right after that.
- cuddlecake 7y agoBy indirectly I mean that we have a WebSocket API that does nothing more than expose the primitive streams. Our frontend client basically reads any stream it needs. And the main problem is, if you have to handle 40+ streams (and that is not even 30% of what's to come), it gets more and more difficult to provide a good user experience. Thankfully, after much discussion we agreed to do it better... Soon ish.
- cuddlecake 7y agoWe have an API that lets clients read streams from beginning to end. They do not read the streams directly, but the API is thin enough that one might go "eh, just give them the lib"