Epic: Eventing Framework in .NET 9 #53219
Comments
captainsafia
added
the
Epic
ghost
added
the
needs-area-label
captainsafia
removed
the
needs-area-label
mkArtakMSFT
added
the
area-minimal
captainsafia
removed
the
area-minimal
|
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:
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 :) |
|
Isn´t this exactly what you already tried with WCF when it came out? What will you do differently this time around to prevent the mess that WCF was for, especially for one-way messaging? |
|
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 |
|
Why not support existing OSS tools like Wolverine or MediatR or smth else instead of building smth from scratch in-house? |
|
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? |
|
This is interesting. Some thoughts from experience with existing libraries in the space.
|
|
With outbox feature, please. |
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. |
Imo, that's exactly against the spirit and nature of OSS. Tools are not designed to promote developers(while this might be a good side effect). Those tools are built to solve problems, and people collaborate together to solve them. Now, MS looks at the existing ecosystem selects popular areas, and develops tools that essentially replace existing OSS alternatives. So what happens next? Use of those tools will obviously drop, and eventually, they will disappear. Why maintain some OSS tool when you can just sit, wait, and hope MS will be kind enough to develop the thing that solves your problem? This is not OSS. |
|
Just as a point of clarification, MediatR is NOT comparable to this feature set, nor would plug in to a common event bus interface. MediatR is strictly in-process and in-memory. Not for durable async message queues. And also evidently MediatR exists solely to promote myself. I like this idea though. It should be easier to adopt event-driven architectures. It would be nice if it were like DI, logging, even EF Core where there is some default implementation but you can add your own 3rd party implementation. |
|
The risk is that, similar to what happened with DI, the "common interface" effectively defines the implementation and stifles innovation. There was a great thread many moons ago where the author of Simple Injector was trying to explain why the DI interface was hostile to the fundamental premise of Simple Injector. IIRC the conclusion was ~"this is a solved problem that doesn't need innovation" which was off base considering Simple Injector was a reasonably popular project that was taking a different tack that wasn't achievable with the "common interface". Not sure how that all finally resolved in the end. My desire would be to always be able to opt out and also to be able to rebuild whatever is given from smaller bits of the framework. |
FWIW, there's a company behind Wolverine (JasperFx), with similar commercial support offerings behind NServiceBus, MassTransit, and Rebus to name a few others. That argument doesn't really fly. Even Wolverine as the newest kid on the block has technical roots going back a decade. NServiceBus and MassTransit are ~15 years old at least. |
|
Worth noting if you find this exciting, that we already offer all the features described in Brighter (and more @voroninp we have your outbox and inbox already): https://github.com/BrighterCommand/Brighter So if you are looking to work with a mature messaging framework, battle-tested at scale, (that also supports .NET Framework) feel free to check us out and start using events today instead of waiting. We have been doing this for 10+ years, so our offering comes with a wealth of experience. |
|
But to the larger point. The .NET space is perhaps more richly served than any other ecosystem with messaging tools, both commercial, commercial support and solely OSS. Competition amongst those projects has created a strength in offerings that other languages don't have. When MS enters the space that diversity and competition will be crushed, leading to less innovation and choice. There is no argument that MS needed to enter this space, .NET developers were more richly served than any other ecosystem. Instead this is just the usual MS playbook - crush successful OSS - own all the things. When I spoke about a .NET Renaissance many years ago I was clear that MS had a duty of care as the 500lbs gorilla in the room not to do this. But whilst previous flattening of .NET OSS could be seen as ignorance or lack of care, they know well enough by now, that this can only be seen as malice. |
|
FWIW, I'm voting hard against any set of common abstractions for the entry point to messaging, and even more so to any kind of standardized interface signature for message handlers. That's a recipe for a mediocre developer experience that won't make .NET "the best platform for cloud native applications". This isn't a place for a "Conforming Container" kind of approach. |
|
Please, No. We are thankfully blessed with a lot of good libraries at various layers for event-ish type stuff:
Again, all of the above are extremely useful in the context of eventing or event driven systems. I don't see how one could make a sane abstraction however, since many of them are context dependent yet cannot be easily simplified. They mostly have enough different but unique semantics to where a common abstraction could easily be either of little utility or just dangerous. My apologies for any firmness here, I have concerns that another 'conforming container' across all of these paradigms would risk turning the story of event driven systems in .NET into a cautionary tale about good intentions stifling innovation and flexibility, potentially at the benefit of specific vendors despite the unique opportunities each of the above mentioned cases would handle. I hope the community does not decide to add a 'conforming container, but for events', especially if it happens to conform best to a brand new system without clear benefit compared to existing ones aside from 'being first party' or 'well you need it anyway because ASPNETCORE'. If we wanted to fix eventing at a better level, I would suggest:
Points One and Three, I think are fairly easy, it's just a matter of putting them where people can get to them. That middle point, It actually solves a lot of other problems in the .NET space... More Importantly, It helps the authors of all of the above things give better results to the community, as they have done for so long. If you -do- choose to go down the route of a common abstraction, I would hope that it is a public process and you involve the above mentioned parties as well as others. |
|
Just keeping an eye on this as a maintainer / co-creator of https://github.com/FoundatioFx/Foundatio. I just hope this doesn't follow the path of IDistributedCacheClient that I've seen used by very few. Please engage early and often with leaders who have been in this space a long time. |
That is definitely an interesting one. Brighter uses a reactor/proactive model (depending on whether you use async) and has a single threaded message pump to preserve ordering (which you scale out). This also means we don't run into problems with thread pool exhaustion, or blocking on semaphores trying to limit work in flight at high scale. We use a custom SerializationContext based on an article by Stephen Toub to have async callbacks use that thread. But is a little gnarly and a framework solution to that problem would have re-usable value. |
I love foundatio ❤️❤️❤️ |
|
Maybe one could compare the amount of money & effort that would be needed to develop a de novo fit-for-use eventing platform against the money & effort needed to create a set of template projects? For Event Driven Architectures, having the right set of templates may be 80% of the developer win. |
|
If this does move forward, please also add:
With some solutions, it can be hard to even figure out what the DLQ is named... |
|
Also, Kafka should be considered as it greatly impacts design. |
This proposal is about message queues. Kafka is not a queue, I don't think it should be considered. |
Respectfully, This kind of makes my comments above more salient, I believe. |
|
If it wasn’t clear, there’s no eventing framework coming in .NET 10. |
|
For those of you worrying about Mass Transit, there are many other FOSS options. Brighter, which I am working on, is just one. |
|
Fantastic Iancooper, but excuse my honesty it's still a one man show where you will get tired at some point or like many other event frameworks you want to build a customer base and then charge a lot. We really need a foundation from .NET that doesn't need to cover everything in any way. so please, find something positive for all of us who wish Microsoft would create a foundation that can be worked with. The alternative that they absolutely should not create anything is not positive for us, the large group of developers. |
|
@Cygor6 Absolutely true. However, my take on @iancooper 's post is that there are alternatives in the interim, should you be using any of the solutions that are now going commercial. To a large extent a lot of it comes down to standardization, rather than complexity (although that could also be a thing). If one considers logging functionality then there isn't anything much simpler. The dotnet implementation does not attempt to cover all logging requirements, but it does provide the abstraction... which is great. I imagine changing from MassTransit to another service bus shouldn't be too much work, but it is work. Similarly, once Microsoft provides the requisite abstractions it is going to be another round of refactoring to the Microsoft implementations, or just a matter of continuing to use what you already decided on as that solution may very well support the abstractions. It would depend on whether Microsoft covers everything you need. For logging I now use Serilog since Microsoft does not have a solution that provides the functionality that I get from Serilog; unless I've missed something along the way, in which case I can update my code at my leisure, or continue with Serilog. |
Whilst I broke ground on Brighter, it's not a one-man show. Folks come and go, some have done a lot, some a little. Right now there are about six active maintainers. I try not to let it drop below three maintainers. That is enough to keep us going for an extended period of time. If we lack, it's usually that at a given time we might not have anyone using a particular transport that the community wants. We like to support our transports with teams who are actively using them over theoretical use cases. To our credit, we have outlasted MS's commitment to most of its libraries. On evidence, we would have been a safer bet. |
|
@davidfowl Is there anything we can do to help ensure this makes it into the v11 (based on my understanding we can't get this in v10)? It's clear that a lot of people want this from Microsoft, and those who don't can simply choose not to use it. But we need to act now to give it a real chance of being included. Based on your experience and understanding of how these decisions are made, what can those of us who support this feature do to draw attention to it and build a solid business case? Thanks in advance 🤗 |
|
I think the sentiment has already been stated but, I would love to see an abstraction built for an Eventing Framework similar to what was done for logging with the |
|
Echoing @KaydenMiller's point and doubtless others, many of us have been burnt with the seemingly recent trend of common open-source libraries going commercial (FluentAssertions, MassTransit to name but two). I think this is why you might see some reluctance on the part of many commenters above to switch to Brighter @iancooper - I'm sure your implementation is excellent, but it is your world-view of how these things should look (albeit based on good architectural principles) and also its future cannot be guaranteed (despite your track record). To extend the analogy, I sense we'd all be happier there was a messaging equivalent of Food for thought @davidfowl ? |
|
Here is the trade-off, though, @stevecwilkinson. If MS enters this space, it will crush the variety of non-commercial options you have today, such as Brighter, Wolverine, etc. It will also kill commercial options like Mass Transit and NSB. That monoculture will have less innovation, as there will be no competition to drive it. Today, .NET has one of the best messaging ecosystems, but tomorrow, it won't. At some point, FOSS maintainers in the .NET space will walk away from building anything for .NET. Build something, and MS will just kill it, so what is the point? As the .NET team does not have infinite resources, that means .NET will often be waiting behind other ecosystems to support new developments like MCP or A2A. Without an ecosystem to help them, .NET will be too slow to react. They had an MCP server fast, because the community wrote one. At that point, .NET is dead. So be careful what you wish for. |
|
@iancooper We are evaluating .NET messaging libraries at the moment and yeah, dotnet has a lot of them. But we also have node, python, php, delphi, java, etc. backends and the .NET messaging frameworks are mostly very opinionated and don't support CloudEvents, which make most of them completelly unusable for us. My hope would be, that either MS or some of the other frameworks put more effort into interoperabillity and standards. |
Just playing devil’s advocate here—“variety” often comes at the cost of vendor lock-in. As someone who has used IdentityServer, MassTransit, and MediatR professionally before they went commercial, I’ve found myself tied to specific patterns like IdV token endpoints, saga state machines, and request pipelines. These dependencies sometimes make switching to other frameworks a non-starter and, in turn, can stifle innovation. There might be a sweet spot, though—perhaps an MVP from Microsoft that acts as a baseline to promote portability across ecosystems. |
|
@iancooper I don't have a dog in this Eventing race, but we all do have a dog in the OSS/Monoculture race.
Honest question and not trolling -> did this happen when MS added ILogger abstraction? For me I use MS Logger everywhere except the host (aka. literally program.cs) which I then declare to use Serilog. Which I thought was a nice win for the .NET space:
So now I can (for example) make a nuget that has no tight coupling on a specific logging product. You use FancyPants nuget and tie it to whatever logging product you like. So with this Eventing mega-uber-thread .. maybe if MS takes that option and does a nice common abstraction (as mentioned above), we could get a win for everyone? Now my ignorance is showing here -> i'm not an Eventing pro at all. So when i say "common" i'm hoping there's something there. Standards and conventions in the space, agnostic to languages. And then Brighter, MT, etc are still very valuable and can have a place? Again - not trolling. Honest question. |
|
It is a good question. It worked for logging, but that was a problem everyone was trying to solve because the dependency needed to flow across libraries. IMO, it didn't work for OWIN. The issue here involves various approaches. In Brighter, we like to "lean on the type system," so we prefer interfaces for concepts like a handler. Other folks don't like that and want to use convention instead. So, how would we standardize? And we have not delved into the hard stuff, such as how Outbox support works, or how you incorporate resilience libraries like Polly, or even if you do. I suspect Aspire may have an impact. Right now, the Aspire clients don't work as we would want them to, so Brighter will likely ship its own later this year. But once library authors integrate more with Aspire, I suspect we will find that some of the pain around configuration drops away. That may make it easier to move between libraries in the future. |
|
HybridCache is a good example in .NET as an effective caching strategy while fostering ongoing engagement with the open-source community from a Microsoft perspective. Initially, I incorporated HybridCache into my application and was impressed by its seamless performance. However, after discovering FusionCache, I ultimately made the transition, as it supports the unified API for both in-memory and distributed caching in .NET. Moreover, FusionCache provides additional enhanced features absent from the standard implementation. This shift significantly reduced the risk of vendor disengagement or unexpected license changes, while still allowing me to revert to the standard implementation if needed—though with fewer advanced capabilities. |
Why would youwant to standardize the way how configuration is acquired instead of standardizing the common part of configuration itself? |
|
@PureKrome There's a vast difference in scope between logging and the asynchronous messaging frameworks. It made perfect sense to have a common abstraction into the entry point for logging. A huge part of messaging frameworks would be how they interact with your application code. If you standardized that somehow with a least common denominator approach, most of Wolverine's value would be gone. You could standardize around the edges maybe. Message header naming and the like. I don't see any "abstraction" being the slightest bit valuable in this space though. |
|
@jeremydmiller I can see where you are coming from, and recognise that there is tons of value-add in the various implementations, but if all you want is some basic way to do pub/sub that is abstracted away from NSB, RabbitMQ or Azure Service Bus (to name but a few), then there is a lot of value in that (akin to ILogger). We used Mass Transit for that reason alone, and frankly disregarded all the bells and whistles it provides. Obviously it's back to the drawing board now it's gone commercial (with punitive pricing, frankly, justified presumably by all the things it does that we don't need). I guess I am saying that there is a place for least-common-denominator solutions. To your point @iancooper about monoculture, I completely agree this is a risk. Although it's not a fair analogy, the fact we have EF Core doesn't mean there is no place for PostgreSQL, for example. But I guess what's being asked for is the EF Core of messaging, which I sense you believe would be the end of things like Brighter and Wolverine. I definitely don't want that, but having been burned once, I am going to be very careful about adopting another OSS offering's interface that could so easily go the same way. |
|
@stevecwilkinson The fact that we have EF Core killed NHibernate and we're stuck in a world where there's only one ORM with much less innovation as an ecosystem. Also, if you try to build a single abstraction for messaging, it's likely to be massively complex. The key difference though will be in how the eventing framework calls into your code. If you scroll up to see what the MS concept was for this tool in the first place, I defy you to tell me how you'd get an effective middleware strategy or how you'd write testable application code using their approach. And these tools are far, far more than merely being an abstraction layer over Rabbit MQ or Azure Service Bus, and the MassTransit pricing is a pittance compared to the value a tool like that brings. And at the end of the day, I don't believe that MS can actually build a truly great application framework and especially not in a field where they have no real experience. |
|
Very strange reasoning, one moment it is said that Microsoft as a whole is not able to deliver something that we don't even know what they are supposed to deliver. The next second it is said that if they deliver something, the entire "market" for event handling will die, or even worse, .NET is a dead as a product if they deliver something. And all this for a group that is afraid that their life's work will become obsolete because there are alternatives. It's a bit like saying that if Masstransit exists, the remaining alternatives will die. Now Masstransit happens to exist in both its current license and a future commercial variant, several alternatives in other words. In our company we use nhibernate, dapper, ef and will still use them all for many years and all of them is used for good reasons. Aspire is a good example of something amazing that wouldn't have happened if you screamed loud enough that there are better alternatives and Microsoft can't deliver anything good, or for that matter the entire market will die if they create this solution. |
With Brighter, support is possible in V9; it will be easier in V10. In V9, in your MessageMapper code, if you want binary, then just add the relevant headers for Cloud Events. If you want structured (most likely Cloud Events JSON format), create a class with the relevant fields and serialize it into the body. See: https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/formats/json-format.md In V10, we will offer you the ability to do this automatically if you want. |
|
@Cygor6 I completely agree with all of the arguments above. I especially want to highlight this idea:
It seems to me that the last 150 comments, if not more, in this thread are no longer a discussion about potential implementations of a mechanism that, in my opinion, is necessary for the ecosystem and could significantly contribute to building a strong project. Instead, they have turned into largely unproductive conversations that are unlikely to lead to any tangible outcome. Moreover, with all due respect to @iancooper — and I express that sincerely — it appears to me that he is genuinely concerned that if Microsoft releases its own implementation, his project might become obsolete. Personally, I don’t find that conclusion obvious at all. Others have already mentioned examples like With So why am I writing all of this? Because I genuinely don’t understand why, instead of discussing possible implementations, the majority of the conversation revolves around reasons not to do it. Moreover, most of those comments come from people who already have their own implementations and, as it seems to me, are trying to use this issue as a platform to promote their projects. |
|
( I'd just like to say I'm very grateful for people who have done thousands of hours of unpaid work on robust software that I have used and can use for free and imho they are very welcome to do what little they can to both earn something and promote their work) But yes you are quite right — let us leave the subject of 'reasons not to do it' and other negatives behind 👍 |
|
I agree discussion from devs and authors alike should focus on the
interfaces (types or conventions) contributors have proposed and their
specific deficiencies in order to generate constructive feedback.
The epic and its clarification from David seems to state that the scope is
limited to consuming events, not producing, persisting or orchestrating
them (despite mention of serialization) - it seems to only come close to
the power of Wolverine/Brighter deployed to Azure durable functions
platform - perhaps there are other platforms that can run this stuff in
WASI, but right now it's either cloud-vendor-specific or vapourware. I am
convinced by Ian and Jeremy's arguments that pleas for another ILogger (or
IServiceCollection that suffers quadratic performance or an AsyncState that
doesn't work with IAsyncEnumerable!) risk, besides hot air, either being
too complex for direct use or too simple for third-party extensibility
beyond what MS provide as the reference implementation.
As for avoiding reinventing the wheel, I only proposed JasperFX to "win the
contract" (acquisitions tend to become de-facto) because of Wolverine's
already having a commercial support option and its stated goal to be a good
.NET citizen, not because it succeeds. Types are good where they help
consumers rather than hinder library authors, so I'm not fully convinced
convention should be considered harmful - I suspect assembly scanning is
(and code generators are still single phase). If Wolverine and Brighter
both already have non-convention based APIs, do they recommend those for
/consumption-only/ scenarios, or could they offer specific API design
lessons to avoid this "WebJobs v2" being not just inferior but incompatible
with a pubsub abstraction?
I'm from a company without the means to repay whatever tech debt we take on
in framework choice, OSS or otherwise, and my time to choose is now a
couple of months instead of quarters. I understand the concerns of devs
here - @PureKrome constructively proposed what MS could recommend in docs
for the "lowest common denomonator" use cases - using a basic abstraction
and converting at the edge. I don't want to have to abstract event
processing to avoid committing to an OSS choice I love but that is hard to
recommend to my company, because this stuff is silver-bullet category tech
and no matter how much work has gone into them, support may be necessary to
convince corporate plebs to leverage that!
I'm not sure if it's already earlier in the thread, but like to hear more
from Jeremy (or Ian) about how the proposals aren't good for middleware and
testability, both of which I find surprising extrapolations from David's
sketch, where the much-hyped Minimal APIs-style hasn't stopped
FastEndpoints gaining traction. It would make sense for Microsoft to heed
this criticism when the API comes up for review.
KR to all
…On Fri, 11 Apr 2025, 18:46 Roman Vorontsov, ***@***.***> wrote:
@Cygor6 <https://github.com/Cygor6> I completely agree with all of the
arguments above. I especially want to highlight this idea:
And all this for a group that is afraid that their life's work will become
obsolete because there are alternatives.
It seems to me that the last 150 comments, if not more, in this thread are
no longer a discussion about potential implementations of a mechanism that,
in my opinion, is necessary for the ecosystem and could significantly
contribute to building a strong project. Instead, they have turned into
largely unproductive conversations that are unlikely to lead to any
tangible outcome.
Moreover, with all due respect to @iancooper
<https://github.com/iancooper> — and I express that sincerely — it
appears to me that he is genuinely concerned that if Microsoft releases its
own implementation, his project might become obsolete. Personally, I don’t
find that conclusion obvious at all.
Others have already mentioned examples like ILogger and Entity Framework.
Everything is publicly available — just search the web. When these
technologies were first introduced, people were loudly proclaiming, “this
will kill our projects.” So what happened? Even log4net is still alive
and actively maintained — and it’s practically a dinosaur at this point.
With EF, the situation is quite similar. Yes, NHibernate didn’t withstand
the competition, but many still prefer to use its fork, which continues to
be developed internally within some organizations. And a lot of developers
use Dapper as their ORM of choice. But that’s not the main point! When EF
was first released, there were countless concerns that Microsoft would make
it work only with SQLServer. And where are we now? Just look at how many
database providers EF supports today.
So why am I writing all of this? Because I genuinely don’t understand why,
instead of discussing possible implementations, the majority of the
conversation revolves around reasons not to do it. Moreover, most of those
comments come from people who already have their own implementations and,
as it seems to me, are trying to use this issue as a platform to promote
their projects.
Are there really no topics for discussion in this issue other than the
fear of a potential competitive defeat from Microsoft's implementation?
—
Reply to this email directly, view it on GitHub
<#53219 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACL552UR7OGI3FQZILNCQWT2Y75VRAVCNFSM6AAAAABBR66QL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJXGYZTAOJVGE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
*Zodt* left a comment (dotnet/aspnetcore#53219)
<#53219 (comment)>
@Cygor6 <https://github.com/Cygor6> I completely agree with all of the
arguments above. I especially want to highlight this idea:
And all this for a group that is afraid that their life's work will become
obsolete because there are alternatives.
It seems to me that the last 150 comments, if not more, in this thread are
no longer a discussion about potential implementations of a mechanism that,
in my opinion, is necessary for the ecosystem and could significantly
contribute to building a strong project. Instead, they have turned into
largely unproductive conversations that are unlikely to lead to any
tangible outcome.
Moreover, with all due respect to @iancooper
<https://github.com/iancooper> — and I express that sincerely — it
appears to me that he is genuinely concerned that if Microsoft releases its
own implementation, his project might become obsolete. Personally, I don’t
find that conclusion obvious at all.
Others have already mentioned examples like ILogger and Entity Framework.
Everything is publicly available — just search the web. When these
technologies were first introduced, people were loudly proclaiming, “this
will kill our projects.” So what happened? Even log4net is still alive
and actively maintained — and it’s practically a dinosaur at this point.
With EF, the situation is quite similar. Yes, NHibernate didn’t withstand
the competition, but many still prefer to use its fork, which continues to
be developed internally within some organizations. And a lot of developers
use Dapper as their ORM of choice. But that’s not the main point! When EF
was first released, there were countless concerns that Microsoft would make
it work only with SQLServer. And where are we now? Just look at how many
database providers EF supports today.
So why am I writing all of this? Because I genuinely don’t understand why,
instead of discussing possible implementations, the majority of the
conversation revolves around reasons not to do it. Moreover, most of those
comments come from people who already have their own implementations and,
as it seems to me, are trying to use this issue as a platform to promote
their projects.
Are there really no topics for discussion in this issue other than the
fear of a potential competitive defeat from Microsoft's implementation?
—
Reply to this email directly, view it on GitHub
<#53219 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACL552UR7OGI3FQZILNCQWT2Y75VRAVCNFSM6AAAAABBR66QL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJXGYZTAOJVGE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
A question I have about the potential implementation of such a system would be what is intended to be supported by such a framework. Is it going to support I guess the question I have is where is the line to be drawn for an Eventing Framework or what is the goal? Does it want to be more like EF where it manages everything and has very structured implementations for each database implementation and you need to follow specific patterns to configure it? Should it only handle the contracts but no implementation, where does it become too abstract to not be useful to each of us and not worth building vs being so heavy-handed that it gets in the way of extending it? Maybe these are the wrong questions but I figure they are some that I have and it might help refocus the conversation. |
|
Personally I like Fowler's prior demonstration looks good, simple and clean way to setup the rules. Hopefully the first drop of code could be focus on some simple config for any Azure event/message solution. Could be good if the API make it easy to create creativity for the community, then the framework itself will not need to be able to cover all scenarios Simple, clean and beautiful is the key |
|
I think this is timely. I'm a HUGE fan of Mass Transit, but as it transitions to a for-pay service (and that's fine, I've heard the creator's reasoning, and it seems to make sense), even the cheap license of $400/month is really high for one-man or small-shop solutions -- prices out the startup I work for, for example, and we could really use it. At the same time this happens, message based architectures are becoming more and relevant. It would be nice to have a built-in in .net we could rely on always being there. |
|
I'm conscious that there are a lot of different perspectives on this subject and it is unlikely there will be a single outcome that will satisfy all parties. But I am going to assume that there are a set of people affected by the Mass Transit decision, and that their primary motivation for using MT was to isolate themselves from a particular messaging transport implementation. And that amongst that population, there are a significant number that that are in the same boat as @jsmarsch as detailed above. I'd like to propose the following. As Microsoft don't currently have the appetite to tackle this space at this time, I propose we start some sort of open standardization working group with the express purpose of defining a simple, common programming interface for messaging, potentially with a set of reference implementations for C#/.NET. To use an over-used metaphor, the equivalent of Let me say at the outset that I am in no way knocking any of the open-source or newly commercialised initiatives for messaging out there, I don't doubt they solve very specific problems. But as so many have said, none of us want to find ourselves backed into the MT corner again (with the deepest of respect to what is no question an excellent piece of software). If you think this proposal has any merit and would consider participating, then a simple thumbs up here will do. But obviously feel to comment/propose a better approach/criticise constructively, etc. Just please don't hit me over the head with a "why re-invent the wheel when open-source solution XYZ already has this and more?" If there is sufficient interest (half a dozen thumbs up will do), then I will open a new repo and move the discussion there. MTIA. |
|
This thread has been around for quite a while and i like many people would like to see some progress being made. However as mentioned very early on this is a big undertaking especially if you look at the original stated objectives. I feel that we are almost at a point where we should consider splitting the topic into smaller epics for instance:
That way it is less of a beast. The key thing for any SIG is getting the right stakeholders involved. |
Announcing the Standard Messaging initiative...As of this writing, there were 14 up votes, 3 down votes and 2 rockets (I had to look that up, they are like up votes but stronger) to my earlier post. I feel like I may be about to tread on a landmine, or even taken delivery of a high-powered footgun, but here goes... Apologies for the delay; finally I have set up a repo for this initiative here: https://github.com/standard-messaging/standard-messaging (If you don't like the name, feel free to suggest something better, but for the moment, this will do.) It's with all due humility I'm starting this project; I am all too aware of my own limited knowledge in the field and look for contributions from those much wiser and more experienced than I. I hope this repo can be a place of knowledge sharing, idea generation, constructive criticism and eventually some output that benefits the industry. It seems one of those times when it is better to "die trying" than to sit back and hope someone else will fix the problem. Let's use GitHub issues to kick off the discussion - I'll do my best to curate/moderate - if there are others that would like to help on that front, just say. One more thing. I know there are a lot of people here that think this is a really bad idea. To those people I say, please feel to leave your comments (I set up a specific issue for this) - the only thing I ask is that all participants treat each other with respect. MTIA. |
and others
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:
More details here:
#53219 (comment)
The text was updated successfully, but these errors were encountered: