middleware support #66

Open
wants to merge 3 commits into
from

Conversation

Projects
None yet
8 participants
@panta

panta commented Sep 25, 2012

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

This comment has been minimized.

Show comment
Hide comment
@tj

tj Sep 25, 2012

Member

ugh :( resources are so uglyyyyy

Member

tj commented Sep 25, 2012

ugh :( resources are so uglyyyyy

@robdodson

This comment has been minimized.

Show comment
Hide comment
@robdodson

robdodson Sep 25, 2012

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?

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

This comment has been minimized.

Show comment
Hide comment
@tj

tj Sep 25, 2012

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@robdodson

robdodson Sep 25, 2012

so:

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

etc..?

so:

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

etc..?

@panta

This comment has been minimized.

Show comment
Hide comment
@panta

panta Sep 25, 2012

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.

panta commented Sep 25, 2012

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

This comment has been minimized.

Show comment
Hide comment
@tj

tj Sep 25, 2012

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@panta

panta Sep 25, 2012

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

panta commented Sep 25, 2012

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

This comment has been minimized.

Show comment
Hide comment
@tbjers

tbjers Sep 25, 2012

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

tbjers commented Sep 25, 2012

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

This comment has been minimized.

Show comment
Hide comment
@robdodson

robdodson Sep 25, 2012

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

This comment has been minimized.

Show comment
Hide comment
@tj

tj Sep 25, 2012

Member

@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

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

This comment has been minimized.

Show comment
Hide comment
@tj

tj Sep 25, 2012

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@tbjers

tbjers Sep 25, 2012

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

tbjers commented Sep 25, 2012

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

@tj

This comment has been minimized.

Show comment
Hide comment
@tj

tj Sep 25, 2012

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@tbjers

tbjers Sep 25, 2012

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.

tbjers commented Sep 25, 2012

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

This comment has been minimized.

Show comment
Hide comment
@tj

tj Sep 25, 2012

Member

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

Member

tj commented Sep 25, 2012

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

@panta

This comment has been minimized.

Show comment
Hide comment
@panta

panta Sep 25, 2012

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

panta commented Sep 25, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@joscha

joscha Dec 6, 2012

What is the status on this?

joscha commented Dec 6, 2012

What is the status on this?

@panta

This comment has been minimized.

Show comment
Hide comment
@panta

panta Dec 6, 2012

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/visionmedia/express-resource/pull/66#issuecomment-11075566.

Marco Pantaleoni

panta commented Dec 6, 2012

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/visionmedia/express-resource/pull/66#issuecomment-11075566.

Marco Pantaleoni

@joscha

This comment has been minimized.

Show comment
Hide comment
@joscha

joscha Dec 6, 2012

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

joscha commented Dec 6, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@dickbrouwer

dickbrouwer Dec 16, 2012

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

@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

This comment has been minimized.

Show comment
Hide comment
@tj

tj Dec 22, 2012

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@dickbrouwer

dickbrouwer Dec 24, 2012

@visionmedia, that was very helpful, thanks!

@visionmedia, that was very helpful, thanks!

@tthew

This comment has been minimized.

Show comment
Hide comment
@tthew

tthew Apr 18, 2013

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

tthew commented Apr 18, 2013

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

This comment has been minimized.

Show comment
Hide comment

guo-yu commented Oct 31, 2013

nice!

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