Vertical Slice Module(s): Giving developers tools to speed things up...?

[driekus77]

Hello all,

The vertical slice architecture / pattern(?) appeals to me a lot. Must admit that we at work don't use it unfortunately.
A project last year I did try to use it using MediatR but the MicroService(s) became to slow in processing. (MediatR wasn't the only one to blame).
At this point I know that there are other libs out there that (claim to be) are faster than MediatR. But this MediatR lib has some nice features. Previous week I came along the new LoggerMessage for High Performance logging. It uses delegates to "cache" the logger and its formatting.

So that was my intro now my idea's:

What
Vertical Slice Module is nothing more than a class that gets Mediator injected and cashes all the handlers inside delegates.

Why

• To speed things up.
• Introduce Vertical Slice Architecture in THE lib that supports it ;-)

How
The Mediator will need a public GetHandler<TRequest, TResponse>() in order to deliver the handler(s) to the VerticalSliceModule.
The Mediator creates the VerticalSliceModule by a new Method: mediator.GetModule()
The VerticalSliceModule needs an Interface and maybe a Base class?

Just an idea I'm having.... bear with me ;-)

If I'm talking rubbish just say it.

EDIT:
Maybe its 2 idea's in one go:

• Vertical Slice Module(s) to gather all calls
• Compiled / Prepared Handlers and/or Pipelines using delegates in order to speed things up.

I just checked the code and of course MedaitR already caches the handlers. But a cached handler still needs IoC for pipeline(s) handlers.
My experience with delegates is that it could be accomplished.... But it will be harder to grasp than the current Template Wrapper(s).

Maybe I have to sleep it over the night.
Comments are welcome.

EDIT 2:
Ok I have some testable code now and should have written that before I wrote above: Hopefully I didn't offend anyone.

The discussion I wanted to start is: Could a Precompiled Pipeline run faster and be of help for this great library?

First results using the MediatR Benchmark exe:

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.22621
Intel Core i7-8850H CPU 2.60GHz (Coffee Lake), 1 CPU, 12 logical and 6 physical cores
.NET SDK=7.0.201
  [Host]     : .NET 6.0.11 (6.0.1122.52304), X64 RyuJIT
  DefaultJob : .NET 6.0.11 (6.0.1122.52304), X64 RyuJIT


|                    Method |       Mean |     Error |    StdDev | Ratio | RatioSD |
|-------------------------- |-----------:|----------:|----------:|------:|--------:|
|           SendingRequests |         NA |        NA |        NA |     ? |       ? |
|   PublishingNotifications |   139.4 ns |   2.65 ns |   4.92 ns |  0.02 |    0.00 |
| SendingUncompiledRequests | 8,551.2 ns | 165.43 ns | 146.65 ns |  1.00 |    0.00 |
|   SendingCompiledRequests |   288.6 ns |   5.85 ns |   5.18 ns |  0.03 |    0.00 |

So the Compiled version which runs the same PreProcessor -> Handler -> PostProcessor pipeline is faster than the Uncompiled (According to my first tests).

How did I do it?
Not so great. The prototype code is a mesh and has lots of flaws. But hopefully you forgive me because I only wanted too point out that there's (maybe?) something to win with a Compiled Pipeline.

Basic idea is:

• Prepare handler/processor to Expression
• Compile it to a delegate
• Combine the delegates to a Multicast PipelineDelegate<TRequest, TResponse>()
• Use the resulting delegate as a func call

Again comments are welcome and I will provide a draft PR in a few minutes.