middleware support

[panta]

Hi,
I've added middleware support, based on the discussion in #8
Everything remains backward compatible.

It includes also tests and documentation.

Cheers,
Marco

[tj]

ugh :( resources are so uglyyyyy

[robdodson]

what do you recommend instead TJ? I'm really new to node and express so I thought they were a nice convenience but maybe there's a better way?

[tj]

I just use the app.VERB methods, looks way better IMO. express-resource is ok but these are all leaky abstractions really, express-namespace is gross I kinda wish I never wrote that one haha

[robdodson]

so:

app.get('/', routes.index);
app.post('/', routes.create);

etc..?

[panta]

This sounds reasonable when one is handling simple or highly specialized url/views, or when the number of views is low. But for instance when dealing with database models or many coherent, maybe automatically generated, resources, having such an abstraction is very convenient. It keeps things more DRY, and reduces the surface of the code that must be understood and maintained.
For example, express-mongoose-resource is a wrapper around express-resource that automatically generates routes and views for mongoose models, and it has spared me a lot of work already.

[tj]

you can still keep things DRY without this sort of abstraction, and being DRY is not a good choice when it means being using leaky abstractions that you can't back out of. IMO it's inferior to regular method / paths. simple > dry

[panta]

If you think about it, almost all abstractions are more or less leaky. Express itself is a leaky abstraction (it doesn't shield you completely from Connect, for example).
In general I agree, simple > dry, but sometimes striving too much for simplicity can lead to its opposite in the long term. Imho, the best thing would be having abstractions flexible enough to allow you to back out of them, even if this could mean being even more leaky...

[tbjers]

As far as leaky abstractions go, I use express-resource for APIs where I have upwards of 20-30 endpoints that in one way or another support delivering json/xml/yaml and where I have the need for supporting REST HTTP methods as well as file extension contexts.

The one thing I wish express-resource supported was middleware for authentication such as passport and passport-oauth (bearer).

[robdodson]

TJ do you organize your methods/paths into modules or do they all live in app.js? Any examples of something with lots of routes which uses the approach you're advocating?

[tj]

@panta yeah all leak for sure, to me the important part is that they're easy to back out of without coding in strange hacky work-arounds, which is what this module quickly becomes when you try to introduce the regular flexibility that you would otherwise have.

@robdodson we have our app structured in 120+ separate components, many have server portions which are just regular express apps. So for example our "login" component has app.get('/' and is later mounted to app.use('/login', login) etc. We do this same sort of thing all over

[tj]

plus even with regular routes you can do simple stuff like:

app.all('/admin*', authenticate);
app.get('/admin/stats', ...);

etc, vs a huge map of middleware which is a bit of an odd API IMO

[tbjers]

@visionmedia TJ, how do you easily handle REST methods with app.all('/admin*', authenticate); style?

[tj]

just with regular callbacks, though we don't have much CRUD, I can understand the appeal for apps with tons of it

[tbjers]

Gotcha. Yeah, in my case the API is all CRUD essentially. Most of the actual application logic resides in JavaScript in the browser and in iPhone/Android applications.

[tj]

yeah we're mostly client as well, just a very small amount of basic CRUD

[panta]

@tbjers if you want, give a look at panta/express-resource which adds middleware support. It should support your use case well.

[joscha]

What is the status on this?

[panta]

On Thursday, December 6, 2012, Joscha Feth wrote:

What is the status on this?

I've a pull request pending:

#66

In the meantime you can use my branch:

https://npmjs.org/package/express-resource-middleware

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/66#issuecomment-11075566.

Marco Pantaleoni

[joscha]

@panta I saw your fork, thank you! The question was more targeted towards @visionmedia to check what the progress is on merging this in...

[dickbrouwer]

@visionmedia, you mention "many have server portions which are just regular express apps". This makes a lot of sense; do you mind sharing some best practices (if any) on how to structure the overall project best in that case? I know it's fairly straightforward, but there are still many ways to lay out the code, config, dir structure etc. It would be awesome to have a blog post about this?

[tj]

@dikbrouwer details the structure a little bit but doesn't go into config etc http://t.co/tYsbAx6t

[dickbrouwer]

@visionmedia, that was very helpful, thanks!

[tthew]

Just wondering what the status of this PR is specifically with regard to this pull request? Thanks in advance.

[guo-yu]

nice!