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.
CouchDB is actually my favorite "I just wanna hack something" database for the above reasons. No, I have not and do not know if I'd seriously recommend using CouchDB 1.6 in prod for something you expected to grow huge, but it's a great "get it done" platform like Parse or Firebase, and you can really trivially move to Couchbase as you scale up if you need to.
PouchDB and CouchDB are great for prototyping of apps, but access restriction in CouchDB is broken by design: it is hard to make it correct, CouchDB is open by default, user can store anything in DB it has access to, including pr0n.
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.
Lots of databases are open by default, especially in this space (Mongo, RethinkDB, Redis, Riak, and I believe Cassandra), and Fauxton has huge warnings that you've got access turned on globally if you haven't adjusted the setting, so I'm not sure I agree with you that that's an instant fail, but I get your point.
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.)
Are there any whitepapers or case studies of large-scale production applications using and maintaining a sync function? After using sync gateway with access control for a while, it became more clear to me that writing my own access control API (via node.js or something like that) on top of MongoDB would give better readability and maintainability over a sync function.
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).
I couldn't agree more here and it is sharing the same protocol with Couchbase Mobile. For me, mobile apps and offline storage with Sync is the value add. I know with Parse, push notification was the big thing for them but also it was expensive overall. This is something where you can do with Couchbase and it is all free too.
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).
That's not a very fair comparison. The table is missing almost all of the features that make parse so great. Parse is easy to use on any platform. There is a parse SDK for android, iOS, JavaScript, C... The focus of parse as a product is usability for devs.
Kinto may have parity with parse features in terms of technical details, but the usability is not even close.
It seems like you should update self-hostable for Parse. They did such a good job that one of our guys in Developer Relations put up https://cloud.google.com/nodejs/resources/frameworks/parse-s... with instructions in just a few hours (mostly writing it up).
PouchDB is missing. It is implementation of CouchDB but in javascript, for both client side (as in-browser database) and server side (as replacement for CouchDB).
PouchDB + CouchDB are great, especially with Mongo-like queries.
If you move to the Couch ecosystem, you'll also have the option to use Couchbase Lite for iOS, Android, .NET, etc. As well as Sync Gateway which has dynamic fine grained permissions. Of course the whole ecosystem is open source under the Apache license.
Yes see the other comments here and the comments on the Parse announcement. Couchbase Mobile is being used by major airlines as well as General Electric. And a bunch of start ups and other brands.
Realtime - Firebase, Meteor, GUN[0], PouchDB. People should NOT consider Kinto, RethinkDB, and Parse as realtime because you have to manually add that functionality yourself.
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.
An open source project needs active developers and maintainers in order to stay healthy and grow.
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?
Yes open source projects do, and Kinto is currently a well supported project at Mozilla. The folks who made Kinto are awesome, and do awesome things at Mozilla, but my personal experience from working at Mozilla is that Mozilla is an awesome steward of open source projects for users. The devtools team is doing a much better job of becoming stewards of tools for developers, but Mozilla has traditionally been less than ideal steward of projects for use by third parties.
It sounds like some of the more valuable aspects of the server (push notifications, dashboard, analytics) weren't open sourced. But the same caveats apply to the client side code.
This is not a feature complete replacement AFAIK. No push , no cloud code , no webhooks , no admin panel , no analytics though I'm sure people will contribute to the project and add some of these features.
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.
You are correct that there is no push currently (we are exploring some ways to make it possible) and no admin panel (we are also exploring a lite admin panel), and no analytics (you should just use something like Mixpanel).
For cloud code, it's not true that parse-server doesn't support it - you can write cloud code directly in the node server.
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.
My understanding was that Parse (the company) has open-sourced an API-compatible re-implementation of their product as an act of kindness towards everyone currently using their system.
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.)
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.
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.
> This really makes it sound like their team is inexperienced with DB design
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.
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:
CouchDB is actually my favorite "I just wanna hack something" database for the above reasons. No, I have not and do not know if I'd seriously recommend using CouchDB 1.6 in prod for something you expected to grow huge, but it's a great "get it done" platform like Parse or Firebase, and you can really trivially move to Couchbase as you scale up if you need to.