Question: can the Middleware be specific to the command ?

[xbdxllxhi2]

Hello, i was wondering if a Command can have one or more Middlwares specific to it.

• The current flow : Command 1- - > Middleware - - > Handler1
  Command2 - - > Middleware - - > Handler2

• The desired flow (while being able to have the previous one): Command 1- - > Middleware1 - - > Handler1 Command2 - -> Middleware 2 - - > Handler2

[sizovs]

Hi @xbdxllxhi2

If middleware needs to vary by command, consider using multiple pipeline instances, each configured with its specific middleware set. That would be a clean and simple solution.

If this doesn't work for you, I'd love to learn about your use case.

[sizovs]

Middlewares receive a command as an argument, allowing you to include conditionals to adjust logic based on the command type. However, this approach is less preferred because it is more opaque.

[xbdxllxhi2]

Thank you for your prompt response!

I have a concern regarding this approach. In a large application with many commands, managing numerous pipeline instances might become cumbersome. Additionally, I am using Spring, and I am worried that having multiple instances could complicate dependency injection and overall configuration.

I’ve been considering an alternative approach that might address my concern about managing multiple pipeline instances. What if we use a routing mechanism within the middleware stage to dynamically match and apply the appropriate middleware based on the command type? This would essentially create a pipeline within the middleware stage.

Here's a high-level idea of how it could work:

• A single pipeline processes commands.
• A router or matcher in the middleware stage inspects the command type.
• Based on the command type, the router applies the appropriate set of middlewares.
• This way, I can maintain a single pipeline and still use different middlewares for different commands. Additionally, this should -work well with Spring IOC, allowing me to manage dependencies more effectively.

Do you think this approach could be a viable solution? I'd appreciate any feedback or suggestions you might have.

[sizovs]

Technically, it's possible to add dynamic matching for middlewares to the PipelinR, but I'd rather avoid it, because:

1. It increases cognitive load (with an extra layer of routing, to understand how the pipeline functions, simply seeing a list of middlewares won't be enough; you'll also need to look into the implementation details and conditions of each middleware)
2. It's possible to achieve the goal using existing functionality (see my points above) without introducing new concepts and moving parts. 3) I'd prefer keeping special / corner cases outside the library to make sure the library remains slim and simple.

That being said, I'd love to know more about your specific use case to ensure we find the best solution for your problem and evolve the library based on real production use cases, rather than hypothetical scenarios (which leads to accidental complexity).

P.S. you can do dynamic matching inside your Middleware (perhaps this is what you suggested?), but it's hard to say whether it's a viable solution w/o knowing the details of the use case.

[xbdxllxhi2]

Yes exactly, i aim to do the dynamic matching inside the Middleware, i understand the concerns about increasing cognitive load and introducing additional complexity and appreciate your preference for keeping the library slim and simple.

Allow me to provide more context about my use case:

In our application, we have a diverse set of commands, each requiring different pre-processing steps before reaching their respective handlers. These pre-processing steps vary significantly based on the command type and may involve validations, authorization checks, and data transformations.

Considering the complexity and variety of pre-processing logic required, maintaining multiple pipeline instances for each command type might become challenging to manage and scale effectively.

[sizovs]

Interesting. Yes, that should work. Another solution to consider (or mix with yours) is pushing some of that command-specific logic into the corresponding command handlers (you can create different abstract handlers to be reused as necessary).

[xbdxllxhi2]

That's a good idea, i will consider mixing both approaches. Thank you again for your valuable insights and willingness to collaborate on finding the best solution for our use case.