I immediately when I was done with this video installed this nuget into a personal project and replaced MediatR. While performance wasn't a major impact for me. I wanted to be 100% certain I could switch it out without an gotchas Nick may have missed but so far everything is working flawless. Giving this repo a star for sure.
I was using this today, on a project I am working on, had some problems, mainly because DbContext is Scoped and the Handlers are Singletons. But this was easily fixed by adding the options of the AddMediator() method and changing ServiceLifetime to Scoped. Just in case someone has the same issue. Also note that in the non-pre-release version the options method was not available inside Program.cs. I did not attempt the alternate way. Great Video, and as always great advice.
@Tanglesites from where you change the ServiceLifetime to Scoped? No overlaod for method "AddMediator" taskes 1 arguments for "Mediator.Abstractions" Version="1.0.5"
The creators of the package can make this deviation between MediatR and Mediator a bit more obvious! Only stating that: "MediatR (...) does transient service registration by default, which leads to a lot of allocations. (...) IMediator and ServiceFactory services are registered as transient (not configurable)." is a bit quick! There is a big reason why Jimmy does it they way he does and having a scoped DbContext, or any scoped/transient dependency, makes it clear why Singleton is not the best options. Of course it is faster. Btw. the options is now in the final version (but yeah 9 monhts later 😅)
I will check it in private projects but I'm not sure I would dare to implement it in my employee's projects because of maintenance of the new Mediator. Nevertheless kudos for the author and all the participants ;)
This is exactly what I've been waiting for in terms of the Mediator approach. I think I've seen this library before but just assumed it was a typo-squatting thing haha.
I add ONE comment about how I like MediatR and you hit me with this... now I have to decide whether to continue to use MediatR or switch to Mediator. Thanks Nick 🤔🤔🤔
I would love to see a video from you about source generators. I don't plan on implementing my own any time soon but I would like to know how they work such that I can debug better. Edit: I found two of your source generator videos.
Hi Nick. You talked at one point about mediatr "you like to use it, when it does made sense". Do you have a video about when to use it or not? Or do you mention it in one of your courses. Thx for your great content!
It is a great video and a great aspect! However, I would rather still use MediatR as a well-known and good-maintained package in customer projects. These micro-performance approaches do not play a big role in my opinion. I happened to use a well-known NuGet Package that contains a bug which I discovered after using it for 2 Months I had to refactor my code and report the bug and it wasn't easy. So, I'd rather stay on the safe side but it is still worth mentioning as another option and I might use it in my private code as well.
I just replicated this solution in .NET 8, while using transient instances of the 'new' mediator. While I saw slight improvements in execution time and memory allocation, it was marginal compared to what you are showing. Maybe it's time to revisit this topic? Also it would be awesome if you could share the code of the examples you make in your videos. Cheers!
Please anybody, could you explain what problem MediatR solves? Are there opensource real world project with MediatR? I would like to see how it looks in complecated projects.
I mesured MediatR bottlenecks in our project and for long running services, the problems are more by gc pressure and less by reflection, because almost all reflecrion is done at startup and not in hotpaths (in request handlers in http servers) Sometimes, object pooling solves most problems.
I never said that the problem is reflection. It is the function resolvers that generate the handlers for the requests that cause the problem (though memory pressure and gc pauses)
@@nickchapsas thank you for the good video and the reply, I am sorry if I misanderstood. But what I understand is that source generators cleans the reflections and the dictionary lookup, the first is only startup and the second will be very low impact inside an api service. Even with code generation transient and scoped handlers must be allocated and garbage collected. Using factory di methods its possible to ease GC pressure and still have most mediatr features. I asume pooling can be used with this Source generated package to have even better performance. Thanks for the great videos and streams
Not sure which version of MS Dependency Injection are you using, but there is an error with 6 + when you try to register Mediator, looks like the AddMediator extension exists in both MS and Mediator.SourceGenerator and throws an error "ambiguous method"
I did a few benchmarks using scoped handlers and got some surprising results: the original MediatR was actually better! The source gen mediator caches DI resolved handlers for faster lookups and defaults to using singleton lifetimes. This is great, but in reality we all use scoped handlers with scoped dependencies (so we can be context aware) and hit the mediator exactly once per request\scope - there is no benefit to caching DI results in this scenario and in-fact the caching seems to add some substantial overhead. In these benchmarks MediatR comes out on top at almost half the time and two-thirds the memory allocation. Be careful everyone!
Why is this not a pull request on MediatR ? How long it will be maintained as a parallel project ? Considering both are opensource (MIT) ?? Especially since it even decided to use the same name , i feel like it would have fit more for a great pull request that can be merged into MediatR
This seems solid. I'll admit that at first I felt hesitant due to 3 contributors and nothing done since Aug 12... but then I thought that it seems like it would be a relative painless procedure to swap in the old MediatR if this goes stale, so why not go for the more performant version? Time will tell I guess. :)
Considering that MediatR itself is a pretty stale project because it’s feature complete, I wouldn’t worry about the commits, since there is feature parity already
The problem I often see with packages such as MediatR is that it's often used in more monolithic application as a separation between application layers, which makes sociable tests (using real collaborators) a pain. I do see benefit using this at the edges of an application though, as the interface is pretty simple to mock or fake when you want to hide external API's in your test.
It's not just performance complaints that people have about mediator. It's the dependency hiding that it introduces everywhere in your code. If you use traditional service architecture you can see clean dependency tree with all your services
@@nickchapsas I'm not sure OP was saying the source generated MediatR solved this problem. It certainly makes it *better* since you can step into without having to locate the actual source file and get a good idea of what's going on. But there's still no direct line you can draw between the point the Send function is called and the source code that runs when you call it, and the amount of work is elevated from "right click --> view implementation" to "set breakpoint --> run --> step into --> note class name --> stop debugging --> solution search name --> identify and open file." This is a HUGE process problem being introduced into the application, and most people honestly get very little tangible benefit, so it's a net loss for most. The way people get around this, that I've seen, is putting the requests and the handlers in the same source file so you can view implementation on the request and do just fine. And that can work if you keep stuff simple, but I've seen people get inheritance involved and it was a nightmare lol
@@andrewshirley9240 just like there is a way to step into the generated code, there is a way to write your generated code to file system on build. That would give you ability to navigate to implementation.
@@andrewshirley9240 I'm not sure how other people use mediator. Where I work, all handlers have a command object of type IRequest, which will be a one-to-one with the handler, and the handler is IRequestHandler. When calling Send we create a new command, pass in any args (or an empty object if there are no args). So if we go to the controller we can CTRL + click on the command to go to command file. To simplify matters further, we combine the command and handler in the same file, since the command is useless without the handler. That gives us quick access to the handler from the controller. No breakpoints required to figure out what is getting executed.
Whenever a scenario is changed from run-time to compile-time source generators, the speed and allocations go down but the binary size goes up. whenever you have benchmarks comparing old vs. new approaches, it would be helpful to also compare relative binary size
@@MiningForPies application startup time can be different since we give more work to JIT. But it''s important in a very few cases, generally ahead of time > reflelction
I’ve been using this library for a while. You can see I’m the last issue on it. It’s a good library, the creator is very responsive, and if you have have concerns, your welcome to make pull requests also
I have an application in clean architecture. I wanted to switch from Mediatr to Mediator for performance reasons. But there is a problem here. The problem is that Mediator forces our objects to be in the same project as the Library. Will there be a solution for this?
There aren't any downsides in this particular scenario. Jimmy makes packages for him and he happens to open source them so I assume it's because he himself, doesn't need to.
@@edvardpitka3902 yeah it's used for CQRS. What I meant was in Java when learning about CQRS they always uses event sourcing. An ex, is with Axon server. But was jus wondering if there is the mediator alternative for Java without having to use their controller, service, repository patterns. I don't even know why they try to have "thin" controller in Java when their services class is huge.
You mention a switch statement is faster than a dictionary... but from what I understand a dictionary is typically faster than a switch statement but would potentially allocate more memory (depending on the number of cases in the switch statement), also the compiler might decide to use a dictionary in the output IL code rather than creating if else statements again depending on the number of cases.
No it's not and no the compiler won't decide to use a dictionary to the IL if you use a switch. You are making a lot of false assumptions there. I've covered all this in a video on improving the performance of enums in C#
@@nickchapsas I have already watched that video back when you released it, since I do enjoy your videos 😁, but that video doesn't talk about how the compiler compiles switch statements, I would link to (admittedly old) sources which show the compiler will compile the switch to different IL depending on case numbers etc. But TH-cam doesn't like that, it may be old and not be true anymore since the dotnet compiler is always getting better.
I could only make the new Mediator work using singleton and had to add my other service with addSinglelton as well, or else I get - Some services are not able to be constructed error
Great video as always I just wonder about the debugging experience - with auto generated code it seems to me that you should be able to step in (I should check it)
"Good" reflection is only done once at start-up and all results are cached for fast lookup during the life of the application. "Bad" reflection is done every time something is needed, slowing down the application.
I implemented same in my project and after doing all necessary changes, the source generated file by mediator is giving error stating that :- Error CS8120 The switch case is unreachable. It has already been handled by a previous case or it is impossible to match. I searched in generated file there are 3 switch case for one handler. and this is happening for every handler in my project approx. Why it is happening ? Am I missing something ? Please help me into this. My project is web api .Net7 version and I have installed both packages. Please help me asap...
@@nickchapsas Good to hear. At some point maybe you take a look at Actor models with message queues and maybe contrast with the mediator pattern, especially in CQRS context.
I hand roll my Mediator/Decorator stuff. Succinct code and does all that I need (basically the same as MediatR sans the Publish notification feature). Why? It removes a dependency that I just don't need.
@@nickchapsas I know the nice thing with MediatR is its "pretty much" automatic integration with FluentValidation if you're using the proper dependency. Here I feel like I have to change to pipelines so it's not really plug & play anymore 😅
@@kabal911 correct after going back to my code, I see that the MediatR.Extensions.FluentValidation does just that... weirdly though when I code it myself using Mediator, it does not validate so I'm missing something somewhere 🙂
I like this, so much. But, is too similar to MediatR approach that I feel bad about use it (But, I'll). If this happens to be a PR, I'll use it without any complaint
I think that using MediatR's API is a very smart choice by the creator. You basically get a drop in replacement which would be the biggest migration complaint.
@@nickchapsas Exactly, it is! Is by far the smartest idea I ever see. But, I don't know... I just feel bad about use it, is like said "I'm using your evil twin now" to MediatR Leaving aside the moral issue, I'll see it. I have a framework that uses MediatR approach, and this can be a pretty usefull upgrade for performance and memory use
Highly unlikely especially considering that this has been possible for a long time and the package existed for a long time too. I haven't seen Jimmy try to merge source generated Automapper implementations either which would arguably benefit way more from something like this
I like the way how this library is implemented but I have a concern, It uses ValueTask and as I know ValueTask should used only on hot-paths, It is really messing my mind sometimes and I'm not sure when to use ValueTask correctly, if you know more about ValueTask can you please make a video, like can we use Task inside a method that return ValueTask like this Mediator Package and around. I know that you also have a video with ValueTask but it explains that we should use it only on hot-paths. Thank you!
@@nickchapsas I mentioned that I know it, and It describes to use on hot-path same description as the inventor of ValueTask did, but I want to know more about it. Ex: other cases like EFCore that uses it also when is not hot-path there. Thank you.
I have yet to see a project that benefited from MediatoR and likes. On the other hand I've seen plenty, that got very hard to support because of it (speed is not the main problem)
I have used MediatR in production at scale. It provides no actual value except for • hurting performance • breaking static analysis • turning compile-time errors into runtime errors • making it impossible to just read the code to see how it flows from one method to the next introducing new classes of bugs such as running the action handler before the validation handler because they were registered in the wrong order and new package seems to be no different
I really like the idea though there's no way I can put this on production code at its current state. only 10k downloads... I will never get approval for this. on personal projects, sure.
But what's wrong with MediatR performance? Is it bad for stress-testing or with high amount of user requests? For me it seems like we created a problem and then we created a solution for a problem we created 😆
As you can see in the video MediatR has a high memory footprint per request. When you're working with 100s or 1000s of requests per second, you build up memory pressure that needs to be garbage collected, leading to micro pauses. This can have a big effect in performance and I've shown a video in the past on how the MediatR version is slower than the non-MediatR version in real world scenariors.
@@nickchapsas yep, I saw that video. But I'm just wondering whether we really need to use MediatR all over the place because it's handy and popular, or we could use it for the real problem solving?
@@nanvlad this is what I was wondering lately, usually MediatR is used just to separate controller from its action handling code, you could easily add "businessProvider" class for each action in controller and into the constructor and call its handling method in their action, you would get same thing like with MediatR if you don't use anything more from MediatR like automatic command/query validation or other middleware stuff. Using MediatR in every project makes you "cool" even if the project rly doesn't need it :)
@@lordicemaniac for us, using mediator has nothing to do with “being cool” and everything to do with having simple, consistent patterns that are easy to understand. Sure, you can implement your own way of doing things, but if it’s not based on generics, then you probably end up with lots of dependencies injected into your controller, or you have some sort of “wrapper” dependency that has the other dependencies injected into it. So to do it nicely, your probably end up implementing mediator, just a worse version. Funny how no one has a problem using controllers/actions, which IS the mediator pattern.
Hi Nick, thank you for this as always. Is there a way to access HttpContext from a request handler? I added a filter to my (minimal API) endpoint to validate the API key, coming from the request headers. Upon successful validation I need the value to Generate JWT for subsequent requests. Is there a workaround to this? Need a code sample.
Interesting. But as most developers, I try to cut down on 3rd party lib's in my core, MediatR is already one of the only 3rd party lib's I have. I see no reason why this should not be a default feature in MediatR. I hope it will become.. because I am not using this random lib in my production environment
I don't understand the obsession with cutting down your 3rd party libs. I've heard the reasons but I find them silly or maybe more valid for the .NET Framework times. I would be very surprised if Jimmy changes MediatR to be source generated, especially considering that he hasn't done that with Automapper which is a way more obvious and fitting migration.
@@nickchapsas I don't understand the obsession with 3rd party as well. The worst-case scenario is something being completely abandoned but the alternative is to either implement it yourself or skip it altogether. What is the point of not using libraries if they are available? I've heard the reasoning for it, I just never had any issues in my 10 years working as developer. The only problems I had were with library encapsulation, which to me usually means "adding bugs that wouldn't exist otherwise" and "adding complexity and maintainability issues that you wouldn't have."
@@nickchapsas You of all people should understand. 3rd party is unauthorized code, you don't want that in your core. You don't wanna stumble upon a bug you don't have control over, because it resides inside a 3rd party lib. It's not an obsession, it's just logical common sense and widespread knowledge among experienced developers.
@@codex4048 You decide for yourself, it's your responsibility your code works right. MediatR has 86M downloads and 60+ contributors. It's well known in the programming community. Well tested. I think MediatR qualifies as "not random", but dude, you decide what is random for you.
I don't like code generation and I don't have any projects which require a thousandth of a millisecond improvement on an operation. I won't use it currently. Memory allocation might be considerable though but it needs deeper analysis.
Thank you. It is good video you have made. I have implemented in single api with out clean architecture. It works well. but after I implemented in clean architecture it throws exception like the following. Error: Internal Server Error Mediator.MissingMessageHandlerException: No handler registered for message type: Application.Business.Categories.Queries.GetCategory at Mediator.Mediator.ThrowInvalidMessage(Object msg) in Domain/Mediator.SourceGenerator.Roslyn40/Mediator.SourceGenerator.IncrementalMediatorGenerator/Mediator.g
I encountered the same problem. I think the reason for the problem is that the objects (mediator) and packages (mediator dll's) are not in the same project.
![[ ออกกอง ] วัยหนุ่ม 2544 โลกหลังลูกกรง..ทัวร์กองถ่ายหนังใน "คุกของจริง" | JUSTดูIT.](http://i.ytimg.com/vi/vB--aOkZCpw/mqdefault.jpg)
I immediately when I was done with this video installed this nuget into a personal project and replaced MediatR. While performance wasn't a major impact for me. I wanted to be 100% certain I could switch it out without an gotchas Nick may have missed but so far everything is working flawless. Giving this repo a star for sure.
This is becoming my favorite youtube channel real quick! I usually have your videos running in the background while working.
I was using this today, on a project I am working on, had some problems, mainly because DbContext is Scoped and the Handlers are Singletons. But this was easily fixed by adding the options of the AddMediator() method and changing ServiceLifetime to Scoped. Just in case someone has the same issue. Also note that in the non-pre-release version the options method was not available inside Program.cs. I did not attempt the alternate way. Great Video, and as always great advice.
@Tanglesites from where you change the ServiceLifetime to Scoped?
No overlaod for method "AddMediator" taskes 1 arguments for "Mediator.Abstractions" Version="1.0.5"
@@abdullahghadawi6847 inside the AddMediator( options => ... ) extension method. Like Nick said, use the prerelease version.
The creators of the package can make this deviation between MediatR and Mediator a bit more obvious! Only stating that: "MediatR (...) does transient service registration by default, which leads to a lot of allocations. (...) IMediator and ServiceFactory services are registered as transient (not configurable)." is a bit quick! There is a big reason why Jimmy does it they way he does and having a scoped DbContext, or any scoped/transient dependency, makes it clear why Singleton is not the best options. Of course it is faster.
Btw. the options is now in the final version (but yeah 9 monhts later 😅)
You saved my day ♥
I will check it in private projects but I'm not sure I would dare to implement it in my employee's projects because of maintenance of the new Mediator. Nevertheless kudos for the author and all the participants ;)
That's my worries exactly. This doesn't seem production ready in an Enterprise environment
This is exactly what I've been waiting for in terms of the Mediator approach. I think I've seen this library before but just assumed it was a typo-squatting thing haha.
Source Code generation all the way. Anything you can fix at compile time will help you at runtime.
I wonder how this affects when doing the k6 testings. Thank you Nick!
That's amazing Nick thanks for sharing
I add ONE comment about how I like MediatR and you hit me with this... now I have to decide whether to continue to use MediatR or switch to Mediator. Thanks Nick 🤔🤔🤔
I would love to see a video from you about source generators. I don't plan on implementing my own any time soon but I would like to know how they work such that I can debug better.
Edit: I found two of your source generator videos.
Hi Nick. You talked at one point about mediatr "you like to use it, when it does made sense". Do you have a video about when to use it or not? Or do you mention it in one of your courses. Thx for your great content!
Id like this too. There's so many things out there but I never understand when I should be implementing them
It is a great video and a great aspect! However, I would rather still use MediatR as a well-known and good-maintained package in customer projects. These micro-performance approaches do not play a big role in my opinion. I happened to use a well-known NuGet Package that contains a bug which I discovered after using it for 2 Months I had to refactor my code and report the bug and it wasn't easy. So, I'd rather stay on the safe side but it is still worth mentioning as another option and I might use it in my private code as well.
I just replicated this solution in .NET 8, while using transient instances of the 'new' mediator. While I saw slight improvements in execution time and memory allocation, it was marginal compared to what you are showing. Maybe it's time to revisit this topic? Also it would be awesome if you could share the code of the examples you make in your videos. Cheers!
Great video about performance "compaints"! 😄
I like how I checked it before I published it too
That was fixed fast 😄
Please anybody, could you explain what problem MediatR solves?
Are there opensource real world project with MediatR?
I would like to see how it looks in complecated projects.
Biggest win is that it forces you to have a pattern and be organized.
@@Pcatalin66 I think you can do that even without mediatr
can you review sqlkata query builder, compare to dapper in term of performance?
I really like this library. It's trully a game changer!
Have you ever compared the memory and performance per request of MediatR to MassTransit.Mediator?
I mesured MediatR bottlenecks in our project and for long running services, the problems are more by gc pressure and less by reflection, because almost all reflecrion is done at startup and not in hotpaths (in request handlers in http servers)
Sometimes, object pooling solves most problems.
I must add that personaly I dislike the service locator pattern
I never said that the problem is reflection. It is the function resolvers that generate the handlers for the requests that cause the problem (though memory pressure and gc pauses)
@@nickchapsas thank you for the good video and the reply, I am sorry if I misanderstood. But what I understand is that source generators cleans the reflections and the dictionary lookup, the first is only startup and the second will be very low impact inside an api service.
Even with code generation transient and scoped handlers must be allocated and garbage collected.
Using factory di methods its possible to ease GC pressure and still have most mediatr features.
I asume pooling can be used with this Source generated package to have even better performance.
Thanks for the great videos and streams
Not sure which version of MS Dependency Injection are you using, but there is an error with 6 + when you try to register Mediator, looks like the AddMediator extension exists in both MS and Mediator.SourceGenerator and throws an error "ambiguous method"
did you find a solution for this issue? I'm facing the same issue
@@mohamedelbasmy5160 not, I gave up and used the old mediator, I haven't tried recently
I did a few benchmarks using scoped handlers and got some surprising results: the original MediatR was actually better! The source gen mediator caches DI resolved handlers for faster lookups and defaults to using singleton lifetimes. This is great, but in reality we all use scoped handlers with scoped dependencies (so we can be context aware) and hit the mediator exactly once per request\scope - there is no benefit to caching DI results in this scenario and in-fact the caching seems to add some substantial overhead. In these benchmarks MediatR comes out on top at almost half the time and two-thirds the memory allocation. Be careful everyone!
Can you do more mediatr content? Like pre and post processors. Good tips and such
You are a game changer!
1st brother, all your tuts are great 👍
Why is this not a pull request on MediatR ? How long it will be maintained as a parallel project ? Considering both are opensource (MIT) ?? Especially since it even decided to use the same name , i feel like it would have fit more for a great pull request that can be merged into MediatR
I ask to MediatR mainteiner abouth accept a PR in a discussion in his repository and he said "No, sorry, that's not code I want to maintain."
Nick benchmark test video 09:41 weather_old calling faster mediator and weather_New method calling old mediator, I think there is conflict :)
No it doesn't Old uses old MediatR and new uses the new source gen
What about the maintainability of the new project? I'm not convinced yet to use it in Enterprise environment.
This seems solid. I'll admit that at first I felt hesitant due to 3 contributors and nothing done since Aug 12... but then I thought that it seems like it would be a relative painless procedure to swap in the old MediatR if this goes stale, so why not go for the more performant version? Time will tell I guess. :)
Considering that MediatR itself is a pretty stale project because it’s feature complete, I wouldn’t worry about the commits, since there is feature parity already
The problem I often see with packages such as MediatR is that it's often used in more monolithic application as a separation between application layers, which makes sociable tests (using real collaborators) a pain.
I do see benefit using this at the edges of an application though, as the interface is pretty simple to mock or fake when you want to hide external API's in your test.
It's not just performance complaints that people have about mediator. It's the dependency hiding that it introduces everywhere in your code. If you use traditional service architecture you can see clean dependency tree with all your services
Or the ability to use Mediator with the new NativeAOT capabilities which is also pretty sweet.
@@nickchapsas I'm not sure OP was saying the source generated MediatR solved this problem. It certainly makes it *better* since you can step into without having to locate the actual source file and get a good idea of what's going on. But there's still no direct line you can draw between the point the Send function is called and the source code that runs when you call it, and the amount of work is elevated from "right click --> view implementation" to "set breakpoint --> run --> step into --> note class name --> stop debugging --> solution search name --> identify and open file." This is a HUGE process problem being introduced into the application, and most people honestly get very little tangible benefit, so it's a net loss for most.
The way people get around this, that I've seen, is putting the requests and the handlers in the same source file so you can view implementation on the request and do just fine. And that can work if you keep stuff simple, but I've seen people get inheritance involved and it was a nightmare lol
@@andrewshirley9240 just like there is a way to step into the generated code, there is a way to write your generated code to file system on build. That would give you ability to navigate to implementation.
@@andrewshirley9240 I'm not sure how other people use mediator. Where I work, all handlers have a command object of type IRequest, which will be a one-to-one with the handler, and the handler is IRequestHandler. When calling Send we create a new command, pass in any args (or an empty object if there are no args). So if we go to the controller we can CTRL + click on the command to go to command file. To simplify matters further, we combine the command and handler in the same file, since the command is useless without the handler. That gives us quick access to the handler from the controller. No breakpoints required to figure out what is getting executed.
@@andrewshirley9240 Exactly one of the reasons we removed it from our project after playing with it little bit.
Why do you used record instead of class for the Request?
Whenever a scenario is changed from run-time to compile-time source generators, the speed and allocations go down but the binary size goes up. whenever you have benchmarks comparing old vs. new approaches, it would be helpful to also compare relative binary size
@@MiningForPies application startup time can be different since we give more work to JIT. But it''s important in a very few cases, generally ahead of time > reflelction
Runtime operations have way longer times than compile-time ones, even if you include the JIT
Curious how actively this new Mediator is going to be maintained. I see the repository hasn't been committed to since August 14th
That’s because of the feature parity with current MediatR. MediatR itself is pretty in active because it’s effectively feature complete.
@@nickchapsas that's good to know, thanks!
I’ve been using this library for a while. You can see I’m the last issue on it. It’s a good library, the creator is very responsive, and if you have have concerns, your welcome to make pull requests also
I have an application in clean architecture. I wanted to switch from Mediatr to Mediator for performance reasons. But there is a problem here. The problem is that Mediator forces our objects to be in the same project as the Library. Will there be a solution for this?
What are the downsides to this approach? Why hasn't Jimmy rolled these changes into the base MediatR?
There aren't any downsides in this particular scenario. Jimmy makes packages for him and he happens to open source them so I assume it's because he himself, doesn't need to.
It’s worth to have a discussion up there. I’d love to see these merged and just an option in MediatR
Isn't the code base larger with the source code generation? (Not that really is a relevant disadvantage)
@@jasdefer which? MediatR or the application? The source generator would be at compile time and not committed
@@DanielAWhite27 thanks, I thought that the application would be slightly larger, because of the code (switch statements) generated.
From your time working with Java, is there a mediator for it? Without the whole event sourcing.
The Java world is obsessed with differeny patterns. Mediator is mainly a .NET ecosystem thing
Mediator has nothing to do with event sourcing just fyi
@@edvardpitka3902 yeah it's used for CQRS.
What I meant was in Java when learning about CQRS they always uses event sourcing. An ex, is with Axon server. But was jus wondering if there is the mediator alternative for Java without having to use their controller, service, repository patterns. I don't even know why they try to have "thin" controller in Java when their services class is huge.
You mention a switch statement is faster than a dictionary... but from what I understand a dictionary is typically faster than a switch statement but would potentially allocate more memory (depending on the number of cases in the switch statement), also the compiler might decide to use a dictionary in the output IL code rather than creating if else statements again depending on the number of cases.
No it's not and no the compiler won't decide to use a dictionary to the IL if you use a switch. You are making a lot of false assumptions there. I've covered all this in a video on improving the performance of enums in C#
@@nickchapsas I have already watched that video back when you released it, since I do enjoy your videos 😁, but that video doesn't talk about how the compiler compiles switch statements, I would link to (admittedly old) sources which show the compiler will compile the switch to different IL depending on case numbers etc. But TH-cam doesn't like that, it may be old and not be true anymore since the dotnet compiler is always getting better.
at this point, is there any reason to use the old mediatr?
I need to discuss it with Jimmy 😅
I could only make the new Mediator work using singleton and had to add my other service with addSinglelton as well, or else I get - Some services are not able to be constructed error
Great video as always
I just wonder about the debugging experience - with auto generated code it seems to me that you should be able to step in (I should check it)
You can step in, as long as you've configured the debugger to step in the code
3:07 Define "good" and "bad" reflection, please?
I have touched on this on many videos but I might make one dedicated to this topic so I can link to it.
"Good" reflection is only done once at start-up and all results are cached for fast lookup during the life of the application. "Bad" reflection is done every time something is needed, slowing down the application.
I implemented same in my project and after doing all necessary changes, the source generated file by mediator is giving error stating that :-
Error CS8120 The switch case is unreachable. It has already been handled by a previous case or it is impossible to match.
I searched in generated file there are 3 switch case for one handler. and this is happening for every handler in my project approx. Why it is happening ? Am I missing something ? Please help me into this.
My project is web api .Net7 version and I have installed both packages.
Please help me asap...
What are the drawbacks to this approach?
Not any real drawbacks. The only thing I can think of is that you assemble all be bigger due to source generation but it’s not really a “drawback”
@@nickchapsas Good to hear. At some point maybe you take a look at Actor models with message queues and maybe contrast with the mediator pattern, especially in CQRS context.
I hand roll my Mediator/Decorator stuff. Succinct code and does all that I need (basically the same as MediatR sans the Publish notification feature). Why? It removes a dependency that I just don't need.
Nice library, but any chance to make it work with FluentValidation?
Why wouldn't you?
@@nickchapsas I know the nice thing with MediatR is its "pretty much" automatic integration with FluentValidation if you're using the proper dependency. Here I feel like I have to change to pipelines so it's not really plug & play anymore 😅
@@bugsoli You'd have to write the pre-pipeline which is literally 10 lines of code
@@bugsoli you still need to implement a BehaviorPipeline for fluentvalidations with MediatR
@@kabal911 correct after going back to my code, I see that the MediatR.Extensions.FluentValidation does just that... weirdly though when I code it myself using Mediator, it does not validate so I'm missing something somewhere 🙂
I like this, so much. But, is too similar to MediatR approach that I feel bad about use it (But, I'll).
If this happens to be a PR, I'll use it without any complaint
I think that using MediatR's API is a very smart choice by the creator. You basically get a drop in replacement which would be the biggest migration complaint.
@@nickchapsas
Exactly, it is! Is by far the smartest idea I ever see. But, I don't know... I just feel bad about use it, is like said "I'm using your evil twin now" to MediatR
Leaving aside the moral issue, I'll see it. I have a framework that uses MediatR approach, and this can be a pretty usefull upgrade for performance and memory use
will this be merged into the main project? or maybe some of the changes like ValueTask?
Highly unlikely especially considering that this has been possible for a long time and the package existed for a long time too. I haven't seen Jimmy try to merge source generated Automapper implementations either which would arguably benefit way more from something like this
I like the way how this library is implemented but I have a concern, It uses ValueTask and as I know ValueTask should used only on hot-paths, It is really messing my mind sometimes and I'm not sure when to use ValueTask correctly, if you know more about ValueTask can you please make a video, like can we use Task inside a method that return ValueTask like this Mediator Package and around. I know that you also have a video with ValueTask but it explains that we should use it only on hot-paths. Thank you!
Here you go: th-cam.com/video/mEhkelf0K6g/w-d-xo.html
@@nickchapsas I mentioned that I know it, and It describes to use on hot-path same description as the inventor of ValueTask did, but I want to know more about it. Ex: other cases like EFCore that uses it also when is not hot-path there. Thank you.
Bravo.
Have you ever tried Mediatr-ts?
I hope the original developers "buy" the new one. And just do source generation in a future version.
Isn't Jimmy thinking on migrating to a source generator version, too?
Is he? Has he talked about this publicly?
One important qustion how maintainable is the new "mediator" ? and again a great video nick 👌👌
What do you mean by “maintainable”?
I have yet to see a project that benefited from MediatoR and likes. On the other hand I've seen plenty, that got very hard to support because of it (speed is not the main problem)
I have used MediatR in production at scale. It provides no actual value except for
• hurting performance
• breaking static analysis
• turning compile-time errors into runtime errors
• making it impossible to just read the code to see how it flows from one method to the next
introducing new classes of bugs such as running the action handler before the validation handler because they were registered in the wrong order and new package seems to be no different
I really like the idea though there's no way I can put this on production code at its current state.
only 10k downloads... I will never get approval for this. on personal projects, sure.
But what's wrong with MediatR performance? Is it bad for stress-testing or with high amount of user requests? For me it seems like we created a problem and then we created a solution for a problem we created 😆
As you can see in the video MediatR has a high memory footprint per request. When you're working with 100s or 1000s of requests per second, you build up memory pressure that needs to be garbage collected, leading to micro pauses. This can have a big effect in performance and I've shown a video in the past on how the MediatR version is slower than the non-MediatR version in real world scenariors.
@@nickchapsas yep, I saw that video. But I'm just wondering whether we really need to use MediatR all over the place because it's handy and popular, or we could use it for the real problem solving?
@@nanvlad this is what I was wondering lately, usually MediatR is used just to separate controller from its action handling code, you could easily add "businessProvider" class for each action in controller and into the constructor and call its handling method in their action, you would get same thing like with MediatR if you don't use anything more from MediatR like automatic command/query validation or other middleware stuff. Using MediatR in every project makes you "cool" even if the project rly doesn't need it :)
@@lordicemaniac for us, using mediator has nothing to do with “being cool” and everything to do with having simple, consistent patterns that are easy to understand.
Sure, you can implement your own way of doing things, but if it’s not based on generics, then you probably end up with lots of dependencies injected into your controller, or you have some sort of “wrapper” dependency that has the other dependencies injected into it. So to do it nicely, your probably end up implementing mediator, just a worse version.
Funny how no one has a problem using controllers/actions, which IS the mediator pattern.
Hi Nick, thank you for this as always.
Is there a way to access HttpContext from a request handler?
I added a filter to my (minimal API) endpoint to validate the API key, coming from the request headers. Upon successful validation I need the value to Generate JWT for subsequent requests.
Is there a workaround to this? Need a code sample.
Interesting. But as most developers, I try to cut down on 3rd party lib's in my core, MediatR is already one of the only 3rd party lib's I have.
I see no reason why this should not be a default feature in MediatR. I hope it will become.. because I am not using this random lib in my production environment
I don't understand the obsession with cutting down your 3rd party libs. I've heard the reasons but I find them silly or maybe more valid for the .NET Framework times. I would be very surprised if Jimmy changes MediatR to be source generated, especially considering that he hasn't done that with Automapper which is a way more obvious and fitting migration.
When is a random lib not a random lib anymore?
@@nickchapsas I don't understand the obsession with 3rd party as well. The worst-case scenario is something being completely abandoned but the alternative is to either implement it yourself or skip it altogether. What is the point of not using libraries if they are available? I've heard the reasoning for it, I just never had any issues in my 10 years working as developer. The only problems I had were with library encapsulation, which to me usually means "adding bugs that wouldn't exist otherwise" and "adding complexity and maintainability issues that you wouldn't have."
@@nickchapsas You of all people should understand. 3rd party is unauthorized code, you don't want that in your core. You don't wanna stumble upon a bug you don't have control over, because it resides inside a 3rd party lib. It's not an obsession, it's just logical common sense and widespread knowledge among experienced developers.
@@codex4048 You decide for yourself, it's your responsibility your code works right.
MediatR has 86M downloads and 60+ contributors. It's well known in the programming community. Well tested. I think MediatR qualifies as "not random", but dude, you decide what is random for you.
ABP is the worst framework!!!! real programmers won't use it! don't ADVERTISE them!!
I don't like code generation and I don't have any projects which require a thousandth of a millisecond improvement on an operation. I won't use it currently.
Memory allocation might be considerable though but it needs deeper analysis.
Thank you. It is good video you have made. I have implemented in single api with out clean architecture. It works well. but after I implemented in clean architecture it throws exception like the following.
Error: Internal Server Error
Mediator.MissingMessageHandlerException: No handler registered for message type: Application.Business.Categories.Queries.GetCategory
at Mediator.Mediator.ThrowInvalidMessage(Object msg) in Domain/Mediator.SourceGenerator.Roslyn40/Mediator.SourceGenerator.IncrementalMediatorGenerator/Mediator.g
I encountered the same problem.
I think the reason for the problem is that the objects (mediator) and packages (mediator dll's) are not in the same project.
Thank you I will try it.