rethinkdbdash vs thinky about dendritic

[kaievns]

@davidbanham , @nwinch any opinion on this one? i built projects in both, and i feel like thinky is a bit more humane option

[nwinch]

I can't answer specifically why the choice was made for this project, but I can give an opinion on ORM's and our experience with them thus far. The rest of the team may give a different one!

We've been bitten a couple of times on projects by ORM's that didn't scale well - I'm looking at you Mongoose - and imposed limitations that we could've exceeded if they weren't already deeply dug in to the code**. Often the abstraction between your code and the native driver is a gulf too wide, and your left battling with performance issues and odd syntax choices set by the ORM. Getting as up close and personal to the original syntax as possible is advantageous.

That said I did have a pleasant experience with nano when working with CouchDB.

So I think there is some hesitancy when it comes to using some ORM's because we've experienced real world pains with them before.

Thinky looks good though. I definitely don't want to tar and feather it based on other ORM's failings.

As an aside, I do think we need to address some structuring issues we have with the current implementation anyway. Feels like we have a lot of repetitive code, and as a reasonable newcomer to RethinkDB, it can feel a little overwhelming to learn the ins and outs of the syntax to do some of the basics. Some well trodden paths could be welcome in this regard.

** This is not so much a problem with ORM, but a negative side effect of it's usage. It's all too easy to start peppering it everywhere and then it's a real smack upside the head if you need to stop the spread or switch DB's at any point.

[kaievns]

so, basically "i've been burned before on this". ok, i can hear that.

thinky can have a few quirks of its own, but it is fairly transparent in this regard, it falls back to the rethinkdb interface in some cases. and it also gives you access to the lower level driver at any time (it uses rethinkdbhash btw)

what thinky gives you on top of it though is this:

1. promises based API
2. automatic relationships handling
3. automatic indexes sync
4. simplified syntax for CRUD operations

it was a bit of a pain to do aggregation calls with thinky as it throws you to the lower level driver for that, but you're doing it anyways, so i figured that won't be an issue

[davidbanham]

Wot Nath Said, with a couple extra bits:

I think ORMs in dynamic languages are usually a silly idea. The great thing about an ORM is that it maps your database structures into your type system for you. That's ace!

The crappy thing about ORMs is that they take the query language your database vendor worked really hard on and replaces it with some half-baked DSL. That's lame.

It's often worth trading the latter for the former. In a dynamic language, though, the former isn't a thing. So why would you bother with the latter?

REQL is a really, really nice API to use in Javascript. If we were using a different language that made it awkward to use the native language I'd be on board, but we aren't, so I'm not.

[kaievns]

resolved in the thinky branch