Remove router
Closed this issue · 50 comments
in the 2.x it will most likely be gone, nearly every edit made to this is express specific, so it really belongs in express, it's becoming less and less general each time
Sad news. I use connect & connect router a lot, but don't use express at all. I'll have to maintain the router middleware separately from connect :-(
I agree with dready92. This is one of the main features that I use with connect. Seems like a better way to go would be to encourage express to maintain their own router and revert the connect router to something generic and fast. Just my 2 cents. :-)
its not slow, and neither is express, it's just doesn't make sense to maintain within connect. Connect was never meant to be used directly, it exists to support frameworks like Express
It's one thing to use connect to set up a small file server or something but if you are using the router, you might as well be using express
I'm sorry, I didn't mean to imply that anything was slow. :) I just want to understand your point of view: So, if I create my own framework that uses Connect then I should maintain my own router middleware? That's fine with me, I'll just use the current version from connect. I just don't understand why remove a generic feature that could be used by other frameworks who don't have the specific routing needs of Express.
In all honesty, this doesn't really matter to me as I already have the code for it and I'll be able to make my end work without difficulty. And looking at your amount of of commits to Express, I imagine that you are the better judge here. :)
Someone can create/mantain a repo with a router middleware. It will just don't belong to the core.
TJ will probably maintain his own router middleware on express.
yeah, it's really sloppy so I'll be rewriting it for express. When we wrote connect it had merit but im not so sure anymore
but like @masylum said, there is no reason third-party routers could not be used, if anything removing it from core just enforces the fact that connect is a utility framework
The main problem I have with express is that it automagically parses POST & PUT bodies, and my application (that allows audio uploading & pipe it to different processing tools) have to access the "data" & "end" events.
Perhaps you can tell me how we tell to express "when having a POST/PUT to this URI don't pre-parse body and let me deal with "data"/"end" events" ?
@dready92 no it doesn't.. people just use bodyParser if they wish, otherwise it is no different than using node only
Ah ok so I missed up with my early tests of express... Will reconsider using it when I got some time. Thanks for the info.
@visionmedia Why not just take out all of the middleware and make them separate modules? I'm a big fan of small frameworks anyway, and using only what I need is why I use ender on the client instead of jQuery or the like.
If it's an issue of needing access to functions inside connect, then the API should be opened up a little more. I've found myself wanting access to some of the functions there anyway.
@beatgammit the core mods are lazy-loaded via getters so there's little reason to do that as far as performance goes but I think it's nice to have a reasonable core set of modules. The questionable ones for me are compiler and router
@visionmedia Yeah, I don't understand why compiler is in connect, but I really do like router. If I were the one making the decisions, I'd either keep router or strip out all of the middleware.
Even if they were all loaded at server start, the memory usage is negligable. it just seems easier to maintain separate middleware.
If I like one version of a single middleware better than the current one, then I can load that one. I can't do that if they're all part of a framework. I'll have to separate out the middleware I like, publish it, then include it. It just seems simpler to strip everything off and make connect more into a platform than a full framework.
In this regard, connect would be more like ender for the server than a full framework.
@beatgammit yeah that's the main concern. The middleware that do not have a very distinct and specific functionality are likely to change dramatically so they are not great candidates for core. Compiler scratched an itch but yeah I shouldn't have had it in core, it works fine for basic stuff like sass/less but for more complicated configurations like stylus needs it isn't great.
@beatgammit, something like stack might be what you're looking for...
Well, not everybody uses sass/less. It just seems like more of a headache to keep it in than to keep trying to fix it.
So far I'm loving the middleware, and I hardly use any 'third-party' modules, so to that extent connect is great for me. It just seems to me that router is such a core feature that it should be considered standard. If express needs something else, let it do it's own thing. But for me, all I need is a simple resource router. Maybe router could be simplified and just support regular strings and regex? (take out the Sinatra support for example)
@TooTallNate Yeah, I've seen it, but I'm not ready to ditch connect just yet. I may play with it in the future though.
@beatgammit exactly, I'm not disagreeing with that at all, though some fundamentals have a good home in core IMO, such as session, basicAuth, logger, etc, these are things that with the exception of performance tweaks etc will not be changing much at all. Perhaps I could revert to an older version of the router before I started adding more Express specifics, but again there are sooooo many different ways to deal with routing.
@visionmedia Right, like there are soooo many different ways to deal with auth, but there's a basicAuth middleware. Why not have a basic router middleware?
I like the idea of taking everything out except what is necessary for a basic, functional server (like basic SSL and static file handling) and open the API more. Those two don't change. Everything else is just "nice to have", so they would make more sense as separate modules anyway.
@beatgammit yes... but basic auth is definitive, other methods like digest belong here as well, we just need small, common, maintainable and crucial portions in core, routing is much more opinionated.
If the router is to remain in the core, it should be completely decoupled from Express. It should be generic, fast, and simple, leaving room for more robust 3rd party routers focused on more specific use cases.
I use Connect and I'm extremely grateful for all the functionality it offers, and I don't have the prerogative to speak on Connect's direction as a project but IMHO, Connect's greatest contribution is the idea of server middleware. I think the project should be focused on extending and perfecting the middleware API and encouraging 3rd parties to develop and maintain the bulkier modules like the router.
@dreamdust yeah, that's the issue, it was getting very Express specific, it has been moved to Express and extended, so the one remaining should either be removed entirely or dumbed down for simple use. Even then I'm not a huge fan because it promotes less modular middleware, I'd like to remove it but I wanted to see if any of the auth middleware use it first
We need a generic Router standalone package that can be reused across projects.
For example in Rails land the generic router part was extracted into Rack-mount https://github.com/josh/rack-mount .
It would also be nice to be able to generates a route condition from identifiers or significant keys (as in urlFor, the reverse of routing, in rack-mount it's called #generate). I'm pondering on how to do that for my (future) sugar_cube framework:
https://github.com/clyfe/tweet_express/blob/master/lib/sugar_cube/router.coffee#L71
trying to steal from Rack-mount but the code is pretty complicated parsing regexes and such.
Hey All,
If someone else isn't creating a standalone router, then I'm probably going to take it on. Placeholder project created here and I'm going to do some work on it tonight.
https://github.com/DamonOehlman/connectables
I haven't come from a Ruby background so it may not be a perfect likeness of Ruby Rack middleware, but I'll do my best and given I've used the router in both connect and express I think it should go close. Plus I don't
If someone else is already working on something, then I'd love to know sooner rather than later...
Cheers,
Damon.
Hey, I'm struggling for about 2 weeks to write some extensions to the Express router, namly related to url generation (that is create a url string given some segmens).
I have gathered here: https://github.com/clyfe/tweet_express/wiki/TODO some projects that already do this (but not sure how "good" they do it), and some nice articles. Not sure how close our goals are, but I'll try to help.
Thanks for the link to that page - having a look over it now. My intended approach was to use Sinatra routing as the basis for what I did and work from there.
I would say that there are many routers more or less Sinatra-like https://github.com/joyent/node/wiki/modules#wiki-web-frameworks-routers . What's missing is the equivalent of ruby's rack-mount https://github.com/josh/rack-mount
Cool, thanks again for the info. From having a quick look I'd say escort goes close to being a reasonable replacement, but uses slightly different syntax.
I'll try and get an understanding of the way rack-mount behaves. I think I get the overall gist of it, which I have to admit would be useful in things I have been doing with connect (i.e. dynamically generating routes post initial configuration).
IMO url generation can be as simple as adding helpers:
exports.user_url = function(id){ return '/users/' + id }
not something I personally like to over-complicate. I usually dont use them at all, unless you don't design your urls well and plan on changing them often, certainly not worth making routes more difficult to read
There's https://github.com/caolan/dispatch. Maybe you can get in touch with the author and take it over, seems like it was abandoned.
I'm building a framework leveraging Connect, Socket.IO, and jQuery, and my router is very similar to rack-mount. It's just another piece of middleware, so maybe I'll spin that off and put it up here.
I had a look at dispatch, and while I liked the general approach, I have become quite accustomed to the way the connect router works, so I guess I'm keen to preserve that syntax.
At any rate, I've made a few final tweaks to the first cut of my replacement router this morning and pushed the code up:
https://github.com/DamonOehlman/connectables/blob/master/lib/router.js
I'm sure there are lots of things it doesn't do but its a start for what I need. I'll go about putting together a readme for the repo now...
How'd I miss this? Too bad... the elegantly simple router was one of the primary reasons we use Connect for our API endpoint. Express is too much, all we're doing is routing requests to our backend services. Time to look for something else I guess.
Agreed. Basically, I was hunting through the master repo wanting to investigate the internals of the router and well couldn't find it. Then searched for issues and found this...
@DamonOehlman I like where you're going with connectables, but we need most of what the Connect router provided (optional params as well). Is there any reason you couldn't start with the old Connect router code and go from there? If we can't find a good replacement, we'll probably just split our own project off based on that, as I don't see any good alternatives.
@kainosnoema Optional params should work, I'm definitely using them. Maybe raise an issue against the connectables repo for your specific case and I'll take a look. The readme doesn't have an example, but they do work. I'll add an example now.
The only reason that I didn't spin off the connect router (which I did have a look at) was due to @visionmedia 's own comments pointing to the fact that he felt it should be re-written. I'm all for using existing code, but if the author reckons it needs a redo, I generally won't use it...
@DamonOehlman gotcha. Sorry, just took a glance at the Readme and it mentioned optional params were still in the works. I'll move this conversation over there now. Thanks!
Cool :) Also, I've updated the readme to include the optional parameters example...
If you're doing routing like that, use Express, there's little reason not to, it's not slower, it's not more complex than the old connect router, because it used to use the old router haha, very very naive comments...
@visionmedia I will definitely have a more in depth look at Express. I'm not sure though that I'm quite ready to add express in as a dependency for my project. While it may seem naive, there are definitely some of us who feel more comfortable with connect as a dependency than express.
I will admit once you dive into the dependencies though you aren't talking about a lot of difference so I can understand your perspective.
yeah I mean if the argument is having less deps, then you might as well bundle everything into node core and call it a day. Being comfortable with something sure, but that doesn't mean it's the "right" tool for the job, Connect is an abstraction layer, most of which originated in Express anyway, so they co-exist quite well and Express is much nicer for web services, without adding a lot of complexity.
Connect is for building frameworks, not apps. Much like you could write an app with Rack directly, you never (very rarely) would. The new Express router evolved from what was in Connect (which ported from Express to Connect originally haha..), the functionality is very similar, though it's written in a maintainable way now, and provides additional functionality that connect.router did not.
Connect may have evolved into a tool for building frameworks, which makes a lot of sense (definitely well suited for it), but I don't think it was originally "advertised" as such? What drew us to it was its simplicity, and it fit our use case perfectly. Sorry to sound naive, but I think you misunderstood my comments. I wasn't implying that the Express router was in any way slower or more complex than Connect's, just that we didn't need Express—we've got an extremely lightweight network service (just a couple pieces of middleware) that mostly just proxies to other backend services (neither "framework" or "app" really). Back when it included the Express router, Connect was definitely the right tool for the job.
At this point, it doesn't really matter whether we switch to Express or use a separate router, its not a big deal really. I just wasn't expecting to see it dropped from Connect. Again though, I understand the motivation for a clear separation of focus between the two projects. It makes a lot of sense. They're both really great projects, and we'll still be using them!
I think it might be a little arrogant to assume everybody wants to use Express. Just my opinion.
I think it might be a little arrogant to assume everybody wants to use Express. Just my opinion.
That doesn't strike me as arrogant, seeing as they're already using connect, which is developed by the same people/person.
Anyway, if that's you're opinion, you should be happy that this change happened: maybe not everyone wants to use the express router and instead wants to build their own library on top of connect, using whatever router they want to design.
@chjj - My point being that not everyone wants to use ALL of Express. I don't use Express so I'm probably talking out of my ass right now but it seems a little strange to remove functionality people clearly use and tell them to use something else
That was the original point of Connect yes, I've been with it since day one.
Yeah exactly what @chjj said, people seem happy enough to use the Express router, and yet they fear the "large and massive" Express haha, even though it's essentially just slightly larger tool with more sugar to make common things less of a PITA.
@contra I'm not saying you have to use Express, I'm saying if you're building a web app, or even a web service there's almsot no reason not to. The fact is the routing doesn't belong in Connect core because there are 100+ different ways you can approach routing, and it only existed to support Express in the first place. "All" of express is less code than Connect, but if you prefer to write 4 lines instead of res.redirect(url), or several lines instead of res.json(obj), if you dislike streaming files, http cookies etc then by all means dont use it
@kainosnoema sure, for things like proxies it's definitely fine, but you most likely wouldn't need a larger opinionated router, so for something like that I think it's fine, but it's still simple enough to switch on a pathname or write a tiny ~50 line router
I am so sorry to hear that.My LADY GAGA....
Probably want to remove the router examples in mount.js and vhost.js. Was a bit confused until I checked the change log and saw it was removed. :-)
Please update the examples.
For those wanting to use router with connect, I recommend having a look at this npm module: https://github.com/baryshev/connect-route