Use Waterline for database interface

[TimMikeladze]

@gadicc What are your thoughts on using Waterline for our database code? This would allow us to forgo writing individual database adaptor packages like we had planned. Instead defining a model for our accounts data and relying on the end user to install the necessary waterline adaptor package for their database.

On the flip side, this would be putting all our eggs in one basket.

I'm leaning towards our original approach.

[gadicc]

Hey, this is pretty cool, I hadn't come across it before.

I think probably my only gripe is that - as best I can tell from a quick lookthrough - it seems to favor SQL like storage. NoSQL database users will most likely prefer e.g. emails & service data to be stored as part of the user object (as arrays & dictionaries, respectively). Our current approach allows for each db connector to be responsible for how the data is stored, which is quite nice. It looks like they have embeddable documents on their roadmap.

We could possibly enjoy the best of both worlds. My thinking is:

1. We have 3 adaptors done already with all the API we need, let's avoid unnecessary short term work.
2. We could actually do a "waterline adaptor" to cover cases where we don't offer an "optimized" adaptor but waterline has one. Might be a good idea to do this for the next DB we want if the waterline adaptor is a good fit.
3. For DBs that waterline doesn't have (like RethinkDB, despite what's happening there now), it's a lot easier to implement the few functions we need than implement a waterline adaptor for it.

So let's keep things as is but leave this open?

[TimMikeladze]

Sounds good.