[API]: Refactor middleware logic

[NikSimDev]

Change Type

Performance improvement

Current API

No middleware
We need:

• request logging
• rate limiting
• auth guard
• body size limit
• CORS

Proposed API

app.use(cors());
app.use(jwtAuth());
app.use(requestLogger());

Rationale

Currently, CORS is a separate method in the controller, which is not very convenient. In a modern framework, middleware is a must-have.

Migration Path

No response

Backward Compatibility

Potentially full Backward Compatibility.

Usage Examples

[just1po1nt0]

I saw CORS was difficult to manage, where one had to append the function that allowed CORS at the top of everywhere a request was being processed. I agree middleware is required for that, but I do not understand whether #74 only requests changes to CORS implementation, changes to how the middleware is run behind the scenes, or a complete rewrite of the middleware logic.

I find app.use() convenient-looking, but then there would be no other mention of app.use() within the framework, outside of the .yml files, where such seem to be only a placeholder. Is it really wise to rely on app.use() instead of something like withMiddleware()?

[lev2p1]

We can try creating routes that support decorators.

[just1po1nt0]

I had a brief look at how Laravel implements middleware, and it seems like that is router-level. Middleware code is written out beforehand in an appropriate folder, which is then written in to be invoked upon route request SOMEWHERE (haven't found where exactly yet...).

I support @lev2p1's idea with relfecting our middleware onto the routes too, where they would support decorators.

[just1po1nt0]

I would recommend this is split into sub-issues like so:

• Refactor and expose middleware for use in router
• Add decoration support in router

After which this main issue could be complete with the preparations completed from the sub-issues.

@lev2p1 let me know what you think.

[lev2p1]

I propose completely changing the middleware logic. First, we will structure it as a chain of responsibility to make invocation easier. Second, we will store a pointer to the start of the chain within the route and execute it before running user code.