vex icon indicating copy to clipboard operation
vex copied to clipboard

Modular middleware api

Open olup opened this issue 4 years ago • 3 comments

Hey, thanks for building VEX. I am falling in love with V, and coming from a Node.js background this rings bells.

Looking at the code, it seems routes and middlewares are separate concepts. I am not sure but I think with your present setup you cannot add a middleware after having registered a route (an have it execute only after the route is called). The use case here is have some routes stand before some protected middleware.

Just as well, I don't think you can have multiple middlewares on routes ; nor can you register a top path and use route adding method over it to rganize better your code (I think express calls that a router).

By modifing a bit the design we could have each route handled as a simple middleware, and allow nesting lists of middlewares for graph-like execution. so that we can add multiple routes over a single top route, and that we can add multiple middlewares on top of a single route.

I am making any sense ? If such PR's are welcome, I'd be happy to offer one once the compatibility with 0.2 is fixed.

Also, It would be good to provide some basic middlewares (cors, JWT, logs). Mirroring express, cookie parsing, body decoding, file handling could probably exist as middlewares and not in the main VEX lib.

olup avatar Dec 28 '20 10:12 olup

Small demo is here : https://github.com/olup/yael

olup avatar Jan 04 '21 10:01 olup

I'm looking for the exact same thing. I created my own server framework in hopes of building something close to express and koa but quickly found out that its impossible to have a nested tree of middlewares that can also act as routes and register an asynchronous next() based approach like in express. The main issue being that v as of right now doesn't support closures. unless i'm missing something, what you're recommending wont be possible until closures are supported.

below is a sample implementation of that exact concept. But you get the following error when attempting to dispatch the next middleware.

error: undefined ident: `m`
...
fn (mut m Middlewares) dispatch(i int){
	if i >= m.length { 
		error('next() called multiple times')
		return
	}

	mut method := m.stack[i]
	if i == m.length { return }
	// TODO: update when closures become available because `m` can't be accessed in the closure
	method(m.ctx, fn (){ m.dispatch(i + 1)})
}
fn (mut m Middlewares) combine(ctx &Context){
	m.ctx = ctx
	m.dispatch(0)
}

edgeadjei avatar Feb 09 '21 15:02 edgeadjei

Hi, thanks for dropping by and share your ideas here! I haven't replied to this thread since I haven't had a time to read and write my take on it.

The architecture of Vex isn't final yet and would be delighted to implement a real middleware API and not the one you're seeing right now once closures are fully implemented.

As for basic middlewares, we would definitely implement them in the future. We have session ha dling incoming and a whole lot of cool stuff (probably some sort of plugin mechanism for now until I can incorporate it into middlewares). Cookie, form, and body parsing are built in (see: Req.parse_cookies, Req.parse_form, and Req.parse_files) because of the nature of V unlike in JavaScript where we can modify the Express request/response data.

nedpals avatar Feb 23 '21 16:02 nedpals