middleware support #66

Open
wants to merge 3 commits into
from

8 participants

@panta

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

It includes also tests and documentation.

Cheers,
Marco

@tj
expressjs member
tj commented Sep 25, 2012

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
expressjs member
tj commented Sep 25, 2012

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
expressjs member
tj commented Sep 25, 2012

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
expressjs member
tj commented Sep 25, 2012

@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
expressjs member
tj commented Sep 25, 2012

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
expressjs member
tj commented Sep 25, 2012

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
expressjs member
tj commented Sep 25, 2012

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.

@makara makara referenced this pull request in makara/bones-rest Nov 9, 2012
Open

Really Cool #1

@joscha

What is the status on this?

@panta
@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
expressjs member
tj commented Dec 22, 2012

@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.

@tthew tthew referenced this pull request in panta/express-resource Apr 18, 2013
Closed

Express 3.x support #1

@guo-yu

nice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment