On Wed, Jan 16, 2013 at 8:49 PM, carlos8f <[email protected]> wrote:
> Connect is great, it can be nested as you say, but it doesn't have a > router. > This is a little ironic since connect 1.x did have a router built in, but it was pulled out so that connect would have fewer baked-in dependencies, and be less "opinionated" about how routes should be done. That is, the router was pulled out of connect partly to make connect more like what you're targeting middler to be, as I understand it. :-) In any case, that original connect router is still available as middleware: https://npmjs.org/package/connect_router so you can choose to use that, or you can choose to do routing some other way and just not include the code. > Express has a router, but gives away the embeddability. Middler aims at > giving the best of both worlds, in a slim package. > > Basically, what is different about middler is it unites what were > previously two separate development workflows: writing middleware, and > constructing an app, which uses the middleware, defines routes, and > attaches to or listens on a server. With middler, you can write your app > **as** a collection of nestable route-aware middleware, or you can write > your middleware as a miniature app, using the built-in router (but > exporting a middleware handler instead of a server). > The former is what I've been doing with connect, using nesting to create a tree of middleware that is the app. > The other perk is that middler has no dependencies, which can help > minimize your app breaking by changes introduced in upstream modules (a > fairly common occurrence with npm-deployed code). > Well, yes, but as soon as you start introducing the middleware that does the real work, you start introducing dependencies anyway, unless you're going to write all your own middleware. :-) That said, I accept that this will minimise dependencies that you won't be using. -- Martin Cooper It's also worth saying that the middleware included in connect is a great > companion to a middler-driven app, and likewise middler can be used to > build advanced middleware for use with connect. The two are not > competitors, rather, they complement each other. > > On Sunday, January 13, 2013 3:26:49 PM UTC-8, Martin Cooper wrote: >> >> >> >> On Thu, Jan 10, 2013 at 4:27 PM, carlos8f <[email protected]> wrote: >> >>> Hi, >>> >>> I'd like to announce the availability of middler, a project I started >>> last summer. >>> >>> https://github.com/carlos8f/**node-middler<https://github.com/carlos8f/node-middler> >>> >>> Basically, you might think of it as a "mini express" which allows you to >>> easily attach a middleware stack to an http server, with a chainable >>> routing interface and parameter parsing. What makes it unique is that your >>> middleware stack can be turned into a "super" middleware handler, to add to >>> another middleware stack -- this is the "embeddable" concept. >>> >> >> Perhaps I'm misunderstanding, but this isn't unique. I can do the same >> thing with connect: >> >> var nested_chain = connect() >> .use(nested_1) >> .use(nested_2); >> >> var outer = connect() >> .use(outer_1) >> .use(nested_chain) >> .use(outer_2); >> >> outer.listen(port); >> >> >> In keeping with separation of concerns, I wanted middler to **not** come >>> with batteries included - it doesn't want to create a server for you, or >>> handle configuration, or provide you with a bunch of starter middleware. >>> This makes it a great choice for writing compact modules which simply use >>> middler's API and export a middleware handler. It also performs well as a >>> leaner express if you decide to build an app around it. And of course, it's >>> compatible with existing connect/express/flatiron middleware, especially >>> using the "expres" shim: >>> https://github.com/**cpsubrian/node-expres<https://github.com/cpsubrian/node-expres> >>> >> >> I think I'm missing what really distinguishes middler from connect, since >> they look very much alike to me. Could you say some more about when it >> would benefit me to pick middler over connect? >> >> -- >> Martin Cooper >> >> >> >>> Other nice things: >>> >>> - used in production ~5 months, with great results >>> - tested on travis-ci >>> - very fast - benchmarks included >>> - no dependencies >>> - middleware stack can be manipulated at runtime >>> - supports weights, to control the order of handler execution >>> >>> Feedback welcome! >>> >>> Cheers, >>> Carlos >>> >>> -- >>> Job Board: http://jobs.nodejs.org/ >>> Posting guidelines: https://github.com/joyent/**node/wiki/Mailing-List-* >>> *Posting-Guidelines<https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines> >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To post to this group, send email to [email protected] >>> >>> To unsubscribe from this group, send email to >>> nodejs+un...@**googlegroups.com >>> >>> For more options, visit this group at >>> http://groups.google.com/**group/nodejs?hl=en?hl=en<http://groups.google.com/group/nodejs?hl=en?hl=en> >>> >> >> -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
