Show HN: Jammin – Build Extensible APIs with Express and Mongo | Hacker News Reader

Show HN: Jammin – Build Extensible APIs with Express and Mongo

github.com

16 pointsbbrennan11 comments

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.

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.

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.

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!

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!

Would love to hear any feedback or feature requests!

Feature request: a durable data store, instead of just a best-effort one.

Agreed. Something like this but based on RethinkDB or FaunaDB would be nice to see. Also if you chose to leverage these newer databases, you could leverage their in-built PUB-SUB support instead of having to using long-polling or placing socket.io/redis ontop of the REST API.

http://rethinkdb.com/docs/publish-subscribe/javascript/

https://faunadb.com/

I'm definitely hoping to modularize the database. Thanks for the suggestions!

MongoDB is as durable as anything else if you aren't planning to use replica sets.

Under load it seems to have stale reads on replica sets but I believe that it is being targeted for 3.1. Even rock solid databases like Cassandra suffered from the same issue.

Looks very nice

Reply on news.ycombinator.com