Closed xbdxllxhi2 closed 5 months ago
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.
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.
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:
Do you think this approach could be a viable solution? I'd appreciate any feedback or suggestions you might have.
Technically, it's possible to add dynamic matching for middlewares to the PipelinR, but I'd rather avoid it, because:
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.
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.
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).
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.
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