51–60 of 77 posts
Here is a comparison table with Parse, Firebase, CouchDB and others for easy reference: http://kinto.readthedocs.org/en/latest/overview.html#compari...
CouchDB is so underrated in this space. 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.…
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.
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.)
CouchDB is so underrated in this space. 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.…
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.
At this point, Parse is open source, too. Why an open source clone if you can have the original?
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 develope…
Earlier quoted context omitted.
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 met…
Yes, it is great for prototyping, but it is bad for production.
Earlier quoted context omitted.
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 met…
> Major security alert as 40,000 MongoDB databases left unsecured on the internet http://www.information-age.com/technology/security/123459001... Yes, it is great for prototyping, but it is bad for production.
Earlier quoted context omitted.
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. Info on the mobile clients http://developer.couchbase.com/mobile
What's the Couch ecosystem look like these days? I poked around with CouchDB over the Christmas holiday but it seemed kinda dead. Is Couchbase still going strong?
Earlier quoted context omitted.
What's the Couch ecosystem look like these days? I poked around with CouchDB over the Christmas holiday but it seemed kinda dead. Is Couchbase still going strong?
It's quite active, though most development is going into the 2.0 release (which adds things like clustering). Here's the alpha if you're interested. https://couchdb-ci.s3-eu-west-1.amazonaws.com/release-candid...
I remember not being able to find much of a roadmap when I was doing this evaluation, but that's probably just my fault.
CouchDB is so underrated in this space. 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.…
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).
Earlier quoted context omitted.
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.
The access control limitations in Apache CouchDB are a big part of what we addressed in Couchbase Sync Gateway. Info about our Sync Function API http://developer.couchbase.com/documentation/mobile/1.1.0/ge...