defining the interface of the Event Manager is the easy part, handling well both synchronous and asynchronous messages and allowing different persistence mechanisms is the hard/tedious part
Well, I think you can leave synchronicity to the user? As written above, the work happens on the thread that triggers it, but both attach and trigger have the option to forkIO or send the job to a worker.
Re persistence, I’m honestly not sure what you’re looking for (or why).
When I write asynchronous, I mean it could be done hours later. That means that it needs to be kept/persisted somewhere in the meanwhile. The burden of handling this should not be on the end user, but the library should provide some configuration/helper to say something like handle this job asynchronously using Postgresql/Kafka/… as a persistence mechanism
Hmmm, that’s a pretty involved ask.Though I feel it’s also kind of something that we made at our company, so I definitely understand the want for it.
I guess this is indeed something useful that would be great if added to the ecosystem in a way that’s modular and easy to use by different people in different circumstances