Kinto by Mozilla – An open-source Parse alternative
github.com
github.com
I get it: CouchDB was a very early (the first real?) document-based database, and it got some things wrong, or at least weird early on (e.g. map/reduce queries, a reduce step to the map/reduce query that is actually one-to-many (on purpose! there are concrete reasons in real life you want this!), etc.).
But they also got so much right:
- The database is all HTTP, all the time. Connecting up your
choice language takes about an hour.
- Offline replication and database streaming, standardized at the
protocol level, which allows you to use various combinations of
CouchDB, Couchbase, Coucbase Lite, and PouchDB without interop
problems. Plus, it means in the early part of an app (like the 0.X
bit), I can trivially replicate the prod DB down when I'm trying
to repro something.
- You can store your HTTP assets right alongside the DB for
Firebase-like asset hosting. Throw it behind a caching service
for prod if you want.
- You can store full-blown files, which is great for lots of practical
app these days.
- Trivial replication. The scaling of CouchDB itself is honestly a
bit crappy, but Couchbase has great scaling, and since they speak
the same protocol, you can easily scale from CouchDB to Couchbase
without missing a beat.
If CouchDB will close DB by default AND it will be easy to specify politics by REST path AND it will be easy to restrict document schema by REST path, then I will use it in production.
That said, in CouchDB 2, it'll be easy to programmatically restrict document information in a similar method to Firebase. I can't find the CouchDB 2 documentation itself, but https://github.com/rcouch/rcouch/wiki/Validate-documents-on-... , from rcouch, is the current plan. Do note that CouchDB doesn't do Firebase-like OAuth workflows, so you'd still need a thin shim in prod to handle that if you don't want to have all bespoke user accounts, all the time. (There's probably a clever way to make this work using client-side OAuth workflows, but I've never actually thought about it much.)
Yes, it is great for prototyping, but it is bad for production.
(edit) specify mongodb
The formatting and modularization of your sync function code will strongly influence both it's readability and maintainability.
I've published and example of one that is well formatted and modularized. The example includes Navigation Flow, Wireframes, Data Modeling, and a Sync Function (which is the security layer).
https://github.com/waynecarter/couchbase-mobile-examples/wik...
Let me know if you have any other questions around this and I will add it to the example.
No other database I found has build-in master-to-master replications that works as well.
Another strong aspect is crash-only data storage model. Because it uses append-only file writes, I trust it to handle power loss (VM hard stops), crashes etc.
There is 2.0 coming out which will have a clustered option, so it can allow scaling a db easier (vs say making your own replicated topology + load balancer).
Kinto may have parity with parse features in terms of technical details, but the usability is not even close.
Looks like we need to start marketing better :)
Info on the mobile clients http://developer.couchbase.com/mobile
I poked around with CouchDB over the Christmas holiday but it seemed kinda dead. Is Couchbase still going strong?
I remember not being able to find much of a roadmap when I was doing this evaluation, but that's probably just my fault.
FWIW, it shouldn't be difficult to upgrade from 1.x to 2.0 as you'll be able to replicate from a single-node database to a clustered database.
> Python client
from here : http://kinto.readthedocs.org/en/latest/overview.html
Parse is much more. https://parse.com/docs/android/guide
Coming Soon:
- Web Administration
- Automatic service discovery
- Push notifications using the Push API
http://usergrid.apache.org/ or http://www.baasbox.com/
Both are open source and try to have the same functionalities like Parse.
http://blog.parse.com/announcements/moving-on/
:)
The benefit was that they would worry about scaling and caching the api to get the best performance and not have to worry about a backend.
Releasing open source JSON APIs isn't solving the real problem in my opinion.
AT least with Parse they had an iOS SDK and tutorials. With kinto or couchdb/couchbase i don't even know where to begin.
We hear you and we're working on that. A good place to start is w/ our mini-hacks. Here is an iOS one that I think could help: https://github.com/couchbaselabs/mini-hacks/tree/master/kitc...
> Second, we’re releasing the open source Parse Server, which lets you run most of the Parse API from your own Node.js server.
Would anyone here be interested in putting together a "awesome mbaas" list like awesome django [1] ?
I'm willing to setup on my github there. lmk
They have Push notifications and "Cloud Code" which most other alternatives don't have
Oh, look, here they go again.
Permissions/Auth - Firebase, Parse. The way these two services do permissions is very different than everybody else (correct me if I am wrong). Therefore others are not comparable.
Graph - GUN. I think this is an important comparison for people to think about, all the other databases are essentially document stores. Graph data allows you to do key/value, relational, document oriented data, as well as have circular references.
[0] http://github.com/amark/gun Full disclosure: I'm the author.
Parse is now open source in the sense of "here's a bunch of code we're throwing over the wall on our way out". Presumably (after the 1-year deadline) it's not going to be maintained or further developed by the original Parse team, who are now working for Facebook and will likely be reassigned to other roles.
Who is going to maintain the Parse source after that? A bunch of people that were using Parse specifically because they did not want to write their own backends to begin with?
EDIT: Hi folks, I was obviously talking about Parse, not Kinto. Kinto seems to have more features than Parse Server for now ! Looks like an awesome replacement.
For cloud code, it's not true that parse-server doesn't support it - you can write cloud code directly in the node server.
For a full rundown on what's compatible, check out the migration guide: https://parse.com/docs/server/guide#migrating
The core functionality is there, and I highly recommend trying out the official Parse open source solution first, as it will be the easiest for most apps that want to migrate.
What do you mean by "cloud code"?
Anyway yeah, we're expecting help from the community to bring what's missing :)
I may be way off base here, but there is no indication that this open source release from Parse is in any way a derivative of their commercial product... at this point whichever reimplementation of the Parse API gains the most developer mind share will survive as the winner. (Of course, Parse the company has a lot of inertia behind their own.)
It's not entirely satisfying, but that just proves we could integrate with many hosting platforms.
https://github.com/GoogleCloudPlatform/python-docs-samples/p...
If there's interest I'll try to flesh it out more.
Some of the folks here have pointed out that Parse provides more functionality than Kinto. Why does Mozilla provide resources to keep working on Parse, if Kinto is designed to be an alternative to Parse? It is open source after all. It sounds like Parse is still relevant and needs to be continued.
The phrase "lightweight" is thrown around, but the [requirements.txt](https://github.com/Kinto/kinto/blob/master/requirements.txt) is anything but lightweight and that's before you consider carrying around python itself.
It seems like compiled version would be more efficient and much smaller.
EDIT:
Their FAQ seems to make this question even more interesting
> Why did you chose to use Python rather than X?
> We love Python because it’s a concise & expressive language with powerful data structures & easy to learn, so it was an obvious choice for the development team.
> In addition, the Operations team at Mozilla is comfortable with deploying and managing Python applications in production.
> However, Python is just an implementation detail per se. Kinto is defined by an HTTP protocol that could be implemented in any language.
If your end-user is hitting a HTTP API, then Python being "easy to learn" is a non-goal. Rust (or even JS + Node) is just as "expressive". This really makes it sound like their team is inexperienced with DB design (not very confidence inspiring). I find it equally mystifying that operations would dictate python rather than whatever language the team thought would be best.
Huh, can't see any obvious relation between PL and DB design. Your comment makes it really sound you're inexperienced with constructive commenting anyway.
Because we all know new languages are silver bullets, right?