Use alternative NoSQL databases?

[jashsayani]

MongoDB is a great NoSQL database choice, but I had a few concerns:

1. I don't want to rely on MongoLab or another Database-as-a-service. I learn from experiences.
2. I don't want to install MongoDB on a compute instance and update versions, feed it RAM

I want to use either Google Datastore or Amazon DynamoDB. Both are good NoSQL database choices.
Google: https://cloud.google.com/datastore/
Amazon: https://aws.amazon.com/dynamodb/details/

I think it would be nice to be able to interface with alternative NoSQL databases other than MongoDB.

[duergner]

Should be fairly easy to add if I'm right. You would just need to implement a DatabaseAdapter similar to https://github.com/ParsePlatform/parse-server/blob/master/ExportAdapter.js for your desired database

[gfosco]

See the wiki about ExportAdapter... There is still some work to do in modularizing the database layer, but it's part of the vision for sure.

[davidaik]

+1 I don't want to rely on MongoLab either. It'll be awesome if we have full control over the db.

[francocorreasosa]

What about RethinkDB?

thinking about adding support for Azure DocumentDB if there is interest.

[francocorreasosa]

@ryancrawcour Great

[richardkazuomiller]

Is the plan for Parse to use the ExportAdapterDatabaseAdapter class to do the migration to databases other than MongoDB? For example, if I were to implement my own ExportAdapterDatabaseAdapter for DynamoDB, will I be able to have Parse use that adapter to fill up my new DynamoDB table(s)?

If you look through the Parse code you will see that not all the Mongo code is contained within just DatabaseAdapter and ExportAdapter.

For instance, users.js has direct Mongo code.

This seems to be what @gfosco was talking about when he said that complete modularization hasn't been completed yet.

My question is how much work is required to totally modualrize datavase access?

[gfosco]

Not much (famous last words).. Turn transform.js into ExportTransformAdapter.js and create a TransformAdapter (like FilesAdapter) which defaults to it. Make Schema.js and any other module which accesses transform use the adapter class, and allow it to be injected at initialization.

[gfosco]

Of course, there's a lot more to it I'm sure. The same methods used in ExportAdapter may not always fit some other system, or other unforeseen differences..

[lacker]

Yeah honestly this part of the design is a bit wack. Ideally all the Mongo access should be contained within DatabaseAdapter and ExportAdapter but at some point we got to a tradeoff between feature completeness and modular design, and decided to move towards feature completeness. Especially around supporting some of the stranger $ operators. I'm not sure how hard it would be to make more adapters and it may or may not be tractable.

[richardkazuomiller]

I never used Parse, but I know people who did and it seems like the main of it was that they didn't have to provision and maintain their own servers. In my opinion, the stateless application layer is not so hard to maintain but going from no servers to maintaining a MongoDB replica set or even working with MongoLab is a big jump for people. I think complete support for adapters so we can use DBaaS like Google Cloud Datastore and DynamoDB should be a priority.

[jashsayani]

I think we need to:

1. Modularize/isolate the database code. The database adapter should have a small transport layer that is MondoDB. Optionally, you can write your own transport layer with a different database provider.
2. Clearly document the APIs for the database part, so its really easy to read docs/comments and implement custom transport layers.
3. Work on transport layers for Google Cloud Datastore and Amazon DynamoDB. If 1 and 2 are in place, I am sure the community will start writing these.

[richardkazuomiller]

@jashsayani sounds like a plan d(^_^)