

Show HN: Jammin – Build Extensible APIs with Express and Mongo - bbrennan
https://github.com/lucybot/jammin

======
distracteddev90
how is this different from
[https://github.com/wprl/baucis](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.

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

------
bbrennan
Would love to hear any feedback or feature requests!

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

~~~
distracteddev90
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/](http://rethinkdb.com/docs/publish-
subscribe/javascript/)

[https://faunadb.com/](https://faunadb.com/)

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

------
tacone
Looks very nice

