[distracteddev90]

True, but once you start adding middleware for business logic that conditionally runs for different routes, you end up with requests that get routed in a very non-linear fashion.

My experience regarding building route logic into middleware is that it starts to break down as you add more complicated logic (Real-time support, webhooks, integration with a taskqueue, etc). This is mainly because the middleware pattern works best when it performs an atomic piece of common logic for a large number of routes.

However, when you start using middleware and binding it to a specific route, for a specific collection, you quickly end up with a situation where for any given route, you can no longer look at a single function and parse the flow of logic.

Also, I find these libraries deceptively simple. They may be great for your private weekend blog, but fail to address the major pain points of API implementation in a production setting:

    - Configurable and flexible access control on a per-document basis. 

    - Rate limiting API requests

    - Mutli-node deployments

    - Proper, semantic, backwards-compatible API versioning

    - Realtime support (Websockets, browserchannel, long-polling, w/e you prefer)

Now I'm not saying your library needs to cover all of these pain points, but I challenge you to address all of them using a middleware-based architecture while still maintaining your sanity :)

Just my2c. The project looks great and hope you keep going with it and that I've provided some helpful feedback.

Cheers!

[bbrennan]

I'm hoping to implement per-document access control as middleware (you can see a first pass in 'extended usage'). Rate-limiting could be achieved through middelware like express-brute I think.

I'm also very interested in supporting websockets, but I'm not yet sure what that'd look like.

Thanks for the feedback!