5 ms·

I find it an ongoing mystery how many of these tools and services pop up that aren't based on Couch/PouchDB, don't reference Couch/PouchDB, aren't compatible wi

by Lazare 11y ago

I find it an ongoing mystery how many of these tools and services pop up that aren't based on Couch/PouchDB, don't reference Couch/PouchDB, aren't compatible with the Couch sync protocol, and don't even seem aware the Couch/PouchDB exist. I'm 100% waiting to be sold on "here's a new tool that does what CouchDB does, but is better in these specific ways", but if your sales pitch is just "we're working on writing an exact clone of CouchDB because we didn't realise CouchDB existed" it doesn't really sell me. (Nothing wrong with a dose of Not Invented Here Syndrome; a lot of progress comes from reinventing the wheel. What gets me is the No Idea What's Been Invented Syndrome.)

daleharvey 11y ago
I am a little confused at why PouchDB isnt listed on the comparisons page, I am fairly certain they sent a comparison listing and asked me to review it at some point but in all fairness they did investigate and give reasons to not use PouchDB, this post is linked http://www.servicedenuages.fr/en/generic-storage-ecosystem http://www.servicedenuages.fr/en/generic-storage-ecosystem In my extremely biased position (as the maintainer of PouchDB) I would really have liked to still see this based on the CouchDB protocol / PouchDB codebase, it is true that neither Couch or PouchDB have particularly expressive and powerful permission systems (which is what the main downside looks to be) however I have been very aware of that building PouchDB and have made a lot of effort to ensure a powerful and flexible permissions system can be built on top of it (for example https://github.com/thaliproject/node_acl_pouchdb https://github.com/thaliproject/node_acl_pouchdb) I do think that when you are tasked with providing cloud services for existing Mozilla products that there is a lot more risk involved in leveraging an existing established ecosystem like Couch / PouchDB however so its fairly likely that for Mozilla services this was the best choice (the same in reverse is true however also when looking at this as a generic library). As for a disclaimer, I am a maintainer of PouchDB and a Mozilla developer. I have worked / talked to this team about Kinto, work on some features that use it and they are doing awesome stuff, some of which Pouch may possibly look to do as well.
- tarekmoz 11y ago
  Yeah our doc is incomplete, I did add a bug about this the other day. We should compare products (pouchdb vs kinto.js) and separately deployments (kinto server vs couchdb)
- ametaireau 11y ago
  The comparison with Couch and other solutions actually exists in our documentation: check out http://kinto.readthedocs.org/en/latest/overview.html#comparison http://kinto.readthedocs.org/en/latest/overview.html#compari...
skrebbel 11y ago
As a Firebase customer and former CouchDB user, I can tell you that the use cases are really not as similar as you apparently think they are. Until very recently, Couch/Pouch would only sync entire databases, and recommended a "One database per user" approach. This is improving now, but it's still very coarse-grained. Last time I checked, anything that has data that you couldn't shard easily is basically unfit for Couch/Pouch - e.g. any messaging app or a Twitter clone. How would you select which data goes to which user? Or do you just want to put all tweets, globally, on everybody's phone? All of this is absolutely peanuts on Firebase.
- david-given 11y ago
  Personally, I'm looking for a database with: - strong consistency (cross-node transactions!) - strong access controls (don't want clients to see data they're not allowed to!) - the ability to seamlessly replicate a view from the server to a web client without me having to think about it (although only read-only) So far none of the web nosql databases I've looked at support these. Strong consistency seems to be unfashionable, presumably because it's hard to shard. I was really surprised to discover that CouchDB apparently doesn't support access controls, though --- if a client has access to the database endpoint, it can see everything. Aren't access controls part of the core competency of a multi-user database?
  - Lazare 11y ago
    > I was really surprised to discover that CouchDB apparently doesn't support access controls, though --- if a client has access to the database endpoint, it can see everything. Not sure what you mean; CouchDB has strong access controls, although they are at what in SQL terms we'd call the table level, rather than the row level. But it's not really any different than, eg, MySQL? Or MongoDB, if you want to compare NoSQL to NoSQL. If you have data in a table that a client shouldn't see, don't give that client access to that table.
  - jchrisa 11y ago
    The Couchbase Mobile Sync Gateway tackles fine grained access control head on. Basically you write a function that stripes your data into channels, and manages access on a per channel basis. There are a few things that are challenging to model this way, but for 80% of use cases it's the right simplification. Intro documentation: http://developer.couchbase.com/documentation/mobile/current/develop/guides/sync-gateway/sync-function-api-guide/validation/index.html http://developer.couchbase.com/documentation/mobile/current/...

by Lazare 11y ago

daleharvey 11y ago

I am a little confused at why PouchDB isnt listed on the comparisons page, I am fairly certain they sent a comparison listing and asked me to review it at some point but in all fairness they did investigate and give reasons to not use PouchDB, this post is linked http://www.servicedenuages.fr/en/generic-storage-ecosystem http://www.servicedenuages.fr/en/generic-storage-ecosystem In my extremely biased position (as the maintainer of PouchDB) I would really have liked to still see this based on the CouchDB protocol / PouchDB codebase, it is true that neither Couch or PouchDB have particularly expressive and powerful permission systems (which is what the main downside looks to be) however I have been very aware of that building PouchDB and have made a lot of effort to ensure a powerful and flexible permissions system can be built on top of it (for example https://github.com/thaliproject/node_acl_pouchdb https://github.com/thaliproject/node_acl_pouchdb) I do think that when you are tasked with providing cloud services for existing Mozilla products that there is a lot more risk involved in leveraging an existing established ecosystem like Couch / PouchDB however so its fairly likely that for Mozilla services this was the best choice (the same in reverse is true however also when looking at this as a generic library). As for a disclaimer, I am a maintainer of PouchDB and a Mozilla developer. I have worked / talked to this team about Kinto, work on some features that use it and they are doing awesome stuff, some of which Pouch may possibly look to do as well.

tarekmoz 11y ago
Yeah our doc is incomplete, I did add a bug about this the other day. We should compare products (pouchdb vs kinto.js) and separately deployments (kinto server vs couchdb)
ametaireau 11y ago
The comparison with Couch and other solutions actually exists in our documentation: check out http://kinto.readthedocs.org/en/latest/overview.html#comparison http://kinto.readthedocs.org/en/latest/overview.html#compari...

skrebbel 11y ago

As a Firebase customer and former CouchDB user, I can tell you that the use cases are really not as similar as you apparently think they are. Until very recently, Couch/Pouch would only sync entire databases, and recommended a "One database per user" approach. This is improving now, but it's still very coarse-grained. Last time I checked, anything that has data that you couldn't shard easily is basically unfit for Couch/Pouch - e.g. any messaging app or a Twitter clone. How would you select which data goes to which user? Or do you just want to put all tweets, globally, on everybody's phone? All of this is absolutely peanuts on Firebase.

david-given 11y ago
Personally, I'm looking for a database with: - strong consistency (cross-node transactions!) - strong access controls (don't want clients to see data they're not allowed to!) - the ability to seamlessly replicate a view from the server to a web client without me having to think about it (although only read-only) So far none of the web nosql databases I've looked at support these. Strong consistency seems to be unfashionable, presumably because it's hard to shard. I was really surprised to discover that CouchDB apparently doesn't support access controls, though --- if a client has access to the database endpoint, it can see everything. Aren't access controls part of the core competency of a multi-user database?
- Lazare 11y ago
  > I was really surprised to discover that CouchDB apparently doesn't support access controls, though --- if a client has access to the database endpoint, it can see everything. Not sure what you mean; CouchDB has strong access controls, although they are at what in SQL terms we'd call the table level, rather than the row level. But it's not really any different than, eg, MySQL? Or MongoDB, if you want to compare NoSQL to NoSQL. If you have data in a table that a client shouldn't see, don't give that client access to that table.
- jchrisa 11y ago
  The Couchbase Mobile Sync Gateway tackles fine grained access control head on. Basically you write a function that stripes your data into channels, and manages access on a per channel basis. There are a few things that are challenging to model this way, but for 80% of use cases it's the right simplification. Intro documentation: http://developer.couchbase.com/documentation/mobile/current/develop/guides/sync-gateway/sync-function-api-guide/validation/index.html http://developer.couchbase.com/documentation/mobile/current/...