medusa
                                
                                 medusa copied to clipboard
                                
                                    medusa copied to clipboard
                            
                            
                            
                        chrore(medusa): Refactor the way global middleware like await-middleware are applied
What Add a new wait to apply specific global middleware at a known position in the handler collection. e.g the await-middleware is only applied to the final handler, or the checkErrorOrContinue is applied directly before the final handler.
This approach allow us to apply some middleware automatically without having to think about applying them. Therefore it become easier and cleaner to create new endpoints.
This feature is only applied internally to the core package.
Related discussion: https://github.com/medusajs/medusa/pull/1930
⚠️ No Changeset found
Latest commit: 5dcc4238ab6f73e078d5064f3a37542df89fc9fc
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
LGTM - I am happy to include this PR as it is now, but I would like to discuss this with a wider group before we move forward.
--
This is what I like:
- it is nice that this removes some of the current verbose boilerplate.
- this will also make the await middleware apply to custom routes, improving the plugin/project development experience + you get to rely on the core error handler instead of dealing with errors yourself.
Some other thoughts:
- the fact that this is applied globally in the loader can make the behavior seem a bit magical, especially if you are familiar with express and, therefore, would have to dig around to figure out why the await middleware is automatically applied.
- IMO it would be interesting to consider a more generic handler pattern that decouples our work from express. This could, for example, be using a decorator pattern as you have previously suggested or some type of file-based routing. This could, in either case, be a separate improvement for the future, so answering this is not a blocker for including this PR if a wider group finds it relevant.
This pr was only a thought that i wanted to share in the actual code base, but mostly wanted to get feedback on it 😄 i thought about that when we added the validator middleware that required to either update the await middleware or to apply another one after the validators.
The idea was to first, centralised everything, then we can easily improve it and transform it. I would really like to propose another approach but at the moment it is not possible to go in the decorator way in an elegant fashion as all the handlers are pure function and that a decorator cannot be applied on it. Other refactoring would be necessary for that.
i can also try to come up with something that looks less magical wdyt? 😀