RFC: 2.1 and beyond

[gsserge]

Now that 2.0 is released, I think it's useful to discuss plans for future development.

I think that the project is in a good shape and we've got the basics covered pretty well. This might be a good time to start thinking about convenience. What typical operations can be added to RequestExt (query string and cookies have been mentioned before), what config parameters can be added to RouterBuilder (keep alive, maximum body size, something else?), new useful middleware (logging, metrics, sessions maybe?), TLS management.

Now, I do understand the desire to keep the core compact and offload as much as possible to middleware. But if the same functionality is needed again and again, then maybe it's ok to make it readily available in the core.

Anyway, here's what I've been thinking about moving forward.

Chores.

We need to make sure that all middleware under this org is functional and updated for 2.0.

Convenience methods.

• Option to specify regex as path to match a request (Option to specify regex as path to match a request #7).
• Query string parsing without middleware (Query string parsing without middleware #65 ).
• Working with cookies (Add some more utility methods to RequestExt #13).

More thinking required.

• Size limit of the request body (Option to specify a size limit to the request body #14) is a good example. The draft PR Maximum Request Size Feature Proposal #56 has some interesting discussions regarding the implementation. Specifically, given that the error type is specified as a type parameter E and that it must be the same for the router, handlers and middleware, how can we support flexible external middleware that can fail. If we were to implement size limiting as middleware, how can we make it available to users with custom error types.

[ta3pks]

I believe we also should provide an easier way to initialize the server.
Currently the user has to import and call hyper methods by one self however, it would be so much faster and nicer to have something like Router::serve(SocketAddr) so one can just start building things as in every other web framework.
I believe we should hide as much complexity as possible.
compared to something like tide our getting started takes too much effort

[rousan]

... nicer to have something like Router::serve(SocketAddr) so one can just start building things as in every other web framework.

At the beginning, the Routerify was designed as an extension to hyper.rs, not as a whole web framework. But, as the project has improved a lot, we can now add layer to make it more like a web framework like Rocket.rs etc.
What do you guys think?

[ta3pks]

@rousan I think this is the main thing what keeps people away from routerify. I believe we can have a very thin layer over hyper and have a very nice ux without sacrificing performance

[UndefinedBHVR]

@rousan

... nicer to have something like Router::serve(SocketAddr) so one can just start building things as in every other web framework.

At the beginning, the Routerify was designed as an extension to hyper.rs, not as a whole web framework. But, as the project has improved a lot, we can now add layer to make it more like a web framework like Rocket.rs etc.
What do you guys think?

I'd almost say that we could potentially build an actual framework over the core of routerify as its own crate. Allowing backend systems who don't need all the features of a full framework able to rely on the speed of routerify without dealing with the bloat of unnecessary features.

@NikosEfthias @gsserge Thoughts on the matter?

--Also on a semi-related note, I feel like we should improve the Routerify discord

[ta3pks]

There was a performance comparison to warp on a bug report recently. I think we can optimize things a lot by sacrificing configurability that very small amount of people might actually use. So If we crate another project I dont think I should use routerify as a base It can share a lot of code with routerify but in the end of the day it can be more than just a wrapper around routerify with a lot of positive improvements @UndefinedBHVR

[amitavaghosh1]

I think the API of routerify is pretty good. as compared to some other libraries. where the router has to have a State and datastores inside the State to even get any real world work done.

I like the middleware interface a lot, compared to the other ones out there.

Like, actix-web has a very lengthy middleware setup. While tide has a okay-ish middleware setup (given that they type definition is mostly boilerplate) but then the routers has to be a certain way, makes a mvc-ish pattern almost undoable without put database's in state.
Rocket has a lot of magic. It's good but its way too much for building a simple api.

So each router has like it's own shortcomings on very basic functionalities.

I would like to see routerify address them, and provide some express-ish thing for rust.