Repository navigation
Use alternative NoSQL databases? #20
Description
Activity
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
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.
+1 I don't want to rely on MongoLab either. It'll be awesome if we have full control over the db.
What about RethinkDB?
@ryancrawcour Great
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 ownExportAdapterDatabaseAdapter for DynamoDB, will I be able to have Parse use that adapter to fill up my new DynamoDB table(s)?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.
Reacted by Dielson SalesOf 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..
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.
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.
Reacted by Jérôme Gangneux, Droidment, Cleverson, Nathan Broadbent, Daniel Zhang, Matthew Chun, hamidhomapour, Dennis Liger, Swapnil Gupta, Simone Accascina and 1 moreI think we need to:
- 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.
- Clearly document the APIs for the database part, so its really easy to read docs/comments and implement custom transport layers.
- 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.
@jashsayani sounds like a plan d(^_^)
93 remaining items
The Postgres adapter lacks documentation but is covered the majority of tests. As for other database adapters, I don't believe it's the responsibility of that project to implement other of them. As always, we welcome contributions!
Reacted by Dmitri ZaitsevSometimes I wish there was a bounty system on github to help reward contributors, I simply don't have the time to contribute. I would not mind putting some $ on the line for a google datastore adapter + documentation however. Not a lot but just for the sake of providing incentives. Anyway I digress, I will personally look into using the postgres adapter. If anyone can share their experiences using it, let me know.
Sometimes I wish there was a bounty system on github to help reward contributors
Reacted by noder199 and Olivier AllouchAt the risk of sounding dumb, what would the benefit of using the Postgres adapter over MongoDB be? I am on Heroku using Mlab and I've wondered if using Heroku's built in Postgres storage would be cheaper or have some other benefit.
Reacted by Olivier AllouchThe Postgres adapter lacks documentation but is covered the majority of tests.
Does this mean that it is ready for use in production?
If it's not, I'd like to contribute to help it get there quicker. Any pointers on where I can start?
Now that we can create and manage projects on Github, it might make sense to start one for completing Postgres support. This way people like me can see what's already done and what we can work on to help out.
Anyone interested in doing a fundraiser via bountysource to help promote the creation of a Google Datastore Adapter?
@saleeh93 Why did you halt working on Google datastore adapter? Did you come across some sort of limitation?
Ah alright, hmm was there ever a dynamodb effort made by anybody? Any limitations involved with that database? Dynamo has been around for awhile so it should be more capable, but I know it sucks at storing certain data types...
Reacted by Markus Winkler and a4arpan@saleeh93
I am gonna take a look at some of your code. Would you mind telling me exactly what limitations you faced when it came to querying?
Mongodb atlas is a cheaper aternative to mlab and I am switching to that service as my database needs the extra storage. I won't be needing datastore, but I'd still welcome any effort for an adapter if google makes changes to its api.
Closing as we added support to Postgres a while ago.
MongoDB is a great NoSQL database choice, but I had a few concerns:
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.