[distracteddev90]

how is this different from https://github.com/wprl/baucis?

Also, whenever I've tried to use something like this for an actual product I end up quickly outgrowing the simple CRUD model since you usually need to implement additional features ontop of the CRUD logic.

[sergiotapia]

Wow I didn't know this idea was popular at all. Makes sense though.

I was trying my hand at building something similar using Go because with you can just build a binary and plop that anywhere. API-in-a-can was my end-goal.

http://github.com/sergiotapia/paprika

I'm going to definitely keep working on it and iterate more.

[bbrennan]

That's exactly the problem I was trying to solve. I wanted to offload CRUD to the library, but use middleware when I need features that aren't as simple as CRUD operations.

Check out the middleware and extended usage sections for examples of how it can be extended to do things like access control and regex search.

Baucis looks neat, I'll have to dig into the docs some more.

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