Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modular middleware api #18

Open
olup opened this issue Dec 28, 2020 · 3 comments
Open

Modular middleware api #18

olup opened this issue Dec 28, 2020 · 3 comments

Comments

@olup
Copy link

olup commented Dec 28, 2020

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
Copy link
Author

olup commented Jan 4, 2021

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

@edgeadjei
Copy link

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)
}

@nedpals
Copy link
Owner

nedpals commented Feb 23, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants