Neos.EventSourcing

Neos.EventSourcing copied to clipboard

We need Middleware in two differents area:

• EventStore (for upcasting, monitoring, ...)
• EventBus (for event/metadata enrichments, complex routing, react on event metadata after publishing, monitoring, ...)

The implement must be as lean as possible and explicit. So no AOP in the area, and personnaly I don't want to use the Signal/Slot, I don't see Signal/Slot as a nice way to change object state.

Fully convention based, so no configuration. Create a class, implement an interface and you should be good.

Just a few notes on the use cases for EventBus middleware:

• "for event/metadata enrichments" - that should happen pre commit (EventStore), else this enriched metadata is only transient
• "complex routing" - shouldn't (complex) routing rather be handled by a specific EventBus implementation?
• "react on event metadata after publishing" - for only reacting one should use an EventListener, the middleware is mainly used for actually changing the events/metadata and IMO changing them after publishing is a bit strange, no?

Sorry for being the skeptical voice once again, but I feel that a generic middleware approach is over-sophisticated here. Obviously I agree to the scenarios you mention and IMO we should create tickets for these rather than for the implementation, e.g.: Event Upcasting (#94) and Metadata enrichment (#88).

Both could be addressed with a very simple solution, for upcasting we might not even need custom support (see ticket).

Re metadata enrichment: After thinking about it again and talking with @robertlemke I realized that we only need to enrich it just before it is added to the EventStore and that could be done via Signal/Slot (btw: the version should not be part of the metadata).

I'm working on a PR to see if that works out and as base for further discussion

In our use case, maybe it's edge case, but it's real life ;)

We handle most event locally (sync) but all local events are forwarded to Nats to be available for external service (basically fire and forget) and infrastructure needs (external archiving by ex.). In our current implementation it's hard to listen to all events, and event listener need to be attached to a specific event.

So the middleware around the event bus make sense to offer this kind of flexibility.

It's what I call "advanced routing". We also need to select the subject where the event are published based on the metadata (to select some priority queue, by ex)

If the metadata enrichement work fine based on #88 I'm fine to remove the middleware support around the event store, but for the event bus, I see use case for more flexibility that we have currently.