Epic: Eventing Framework in .NET 9

[captainsafia]

This issue captures issues related to the "eventing framework" work area in .NET 9. Issues and categorizations are subject to change as design and prototyping is underway.

This eventing framework will allow developers to write applications that support processing messages from various queue providers in their application.

Major categories of work include:

• Exposing APIs for registering event providers for various queue implementations, including a supported default set
• Exposing APIs for registering event handlers and implementing a routing implementation to dispatch events to the appropriate handler
• Expose APIs for serializing and deserializing messages resolved from providers
• Exposing APIs for exposing framework primitives like middlewares, filters, DI support, etc.
• Add support for managing the application host and pipeline
• Add support for relevant metrics/tracing in eventing framework

More details here:

#53219 (comment)

[Blackclaws]

I'd like to chime in here a bit because I think a couple of points might be relevant to consider.

Right now there exist a couple of message handler frameworks. Some that come to mind are:

• https://github.com/jbogard/MediatR
• https://github.com/martinothamar/Mediator
• https://github.com/MassTransit/MassTransit
• https://github.com/JasperFx/wolverine

And many more exist.

Given that this is supposed to become a first party implementation of similar capabilities, is there going to be a call for usage scenarios so we can give feedback on which capabilities are used and how or is this going to be handled entirely internally?

I expect that this implementation will at least in part leverage source generation similar to how https://github.com/martinothamar/Mediator and https://github.com/JasperFx/wolverine do it. Albeit the difference between those two is that Wolverine does runtime source generation vs. Mediator using Roslyn source generators.

If it does use source generation I'd like to point out that special care should be taken looking at the integration with existing other source generators. Specifically because there still is no way to chain them together. It would be great if the capability to create MessageHandlers on the fly using Source generation would still allow them to be used from within whatever you're going to build. I'd love for the aspnetcore team to champion changes in Roslyn that lead to us being able to chain Source Generators 😉 . Given that the Razor generator already presents similar issues. Runtime code generation will likely not work that well together with AOT unless you do a two-pass system similar to how Wolverine handles it.

All in all I think having a first party implementation as something people can fall back on or that other libraries can expand on is a good thing. I'd just like it to be as usable as possible in the end :)

[rogeralsing]

Isn´t this exactly what you already tried with WCF when it came out?
A unified platform for uni and bidirectional communication.

What will you do differently this time around to prevent the mess that WCF was for, especially for one-way messaging?

[codymullins]

I would request and highly recommend that in building this you introduce a common abstraction layer that can be used by third party tools, much like the ILogger abstraction introduced in previous versions of .NET.

[Badabum]

Why not support existing OSS tools like Wolverine or MediatR or smth else instead of building smth from scratch in-house?

[smstuebe]

One question pops into my mind: How are schema registries covered?

Is "Expose APIs for serializing and deserializing messages resolved from providers" meant to support schema registries out of the box, or is is meant to provide an interface to integrate a schema registry on your own?

[oluatte]

This is interesting. Some thoughts from experience with existing libraries in the space.

• It would be great to be able to specify the "shape" of the handlers / destination e.g. route to methods on this interface. A big barrier to adoption of existing libraries is that they force you to change all your existing handlers to their custom interface & all change all your pocos to inherit from some base class. It can mean changing a lot of code. A more lightweight approach would be wonderful.

• Please support (or don't somehow exclude) databases as event sources. Many applications would be just fine with a database backed queue (hello SKIP LOCKED in postgres). And using the database has other advantages including a natural outbox implementation, dead simple local development experience and more. It's a great place to start as long as one can switch to a proper queue down the road.

[voroninp]

With outbox feature, please.

[eglauko]

Why not support existing OSS tools like Wolverine or MediatR or smth else instead of building smth from scratch in-house?

One man library. The tools are designed to promote their creators. The design and functionality depend on the owner. When someone is dissatisfied, they create another very similar tool to fulfil their needs.

Create APIs and Layers to standardise these tools seems much better to me.