Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CouchDB 3.0

blog.couchdb.org

Post reply on HN
Print view View original

71–80 of 161 posts

Re: CouchDB 3.0

#71

Post by Volundr »

yatsyk wrote: post #66
daleharvey wrote: post #62

Earlier quoted context omitted.

Your backend can be a reverse proxy that authenticates requests then passes them off to CouchDB (or PouchDB, since that also runs on the server). I have an example up @ https://github.com/daleharvey/noted . The server is 200 lines and does signup / email authentication etc.

This server can't prevent authenticated user from uploading huge document of running expensive query.

Any reverse proxy can limit the the size of a document upload. Even just plain NGINX can do that. Just set the client max body size.

As for queries, it kind of depends on your model. Mango queries are pretty limited (no joins, no arbitrary filters), so it's not necessarily as easy as you think to write one that hosed performance. A client could of course write one that doesn't use an index, which may or may not be a concern.

An easy option if it is though is just don't expose the `_find` endpoint, which effectively limits your users to the map/reduce queries you've written (unless you give them admin they don't have the ability to create their own).

Re: CouchDB 3.0

#72

Post by SahAssar »

newfeatureok wrote: post #63
yatsyk wrote: post #53

Earlier quoted context omitted.

Custom backend means no synchronisation and no advantages over postgres. Do you propose to create proxy that parses query and estimates complexity? I think this task at least as hard as implementing couchdb myself (actually harder) Is there any secure open source code with pouchdb/couchdb integrations?

There are plenty of proxies that do that with some config like nginx. Even if you were using a relational database with a backend you’d still have to solve the same problem.

nginx couldn't solve the "execute expensive query" though right, only limit max size. I guess you could do a request timeout + blacklist, but that would also be hard to do right, since at heavy load some proper clients might get blacklisted.

Re: CouchDB 3.0

#74

Post by Volundr »

agumonkey wrote: post #37

anybody acquainted with pouchdb devs ? just to know if there are plans to migrate already or not

For those who don't want to follow the link, there are no changes to the replication protocol in Couch 3.0, so PouchDB already works.

Re: CouchDB 3.0

#75

Post by Volundr »

mauflows wrote: post #27
newfeatureok wrote: post #21

Earlier quoted context omitted.

The main reason most people use CouchDB is because of the HTTP API and offline support with Couchbase Mobile and PouchDB. Doesn't CouchDB have most of those things already from 2.3?

I don't think couchbase has couchdb in mind for the mobile client anymore

Correct. The newest version of CouchBase mobile no longer supports CouchDB as a replication target. It can still be accomplish with the CouchBase Sync Gateway, but get complicated quickly.

Re: CouchDB 3.0

#76

Post by daleharvey »

Volundr wrote: post #71
yatsyk wrote: post #66

Earlier quoted context omitted.

This server can't prevent authenticated user from uploading huge document of running expensive query.

Any reverse proxy can limit the the size of a document upload. Even just plain NGINX can do that. Just set the client max body size. As for queries, it kind of depends on your model. Mango queries are pretty limited (no joins, no arbitrary filters), so it's not necessarily as easy as you think to write one that hosed performance. A client could of course write one that doesn't use an index, which may or may not be a…

A popular model is for the clients to run the queries locally, the server doesnt need to expose any query endpoints, only the ones necessary for replication.

Re: CouchDB 3.0

#77

Post by teddyc »

treis wrote: post #55
splatcollision wrote: post #23

CouchDB is awesome, full stop. While it's missing some popularity from MongoDB and having wide adoption of things like mongoose in lots of open source CMS-type projects, it wins for the (i believe) unique take on map / reduce and writing custom javascript view functions that run on every document, letting you really customize the way you can query slice and access parts of your data... Example: I'm building a documen…

>CouchDB is awesome, full stop. The problem I had with CouchDB is integrating it into a framework like Rails. CouchDB on its own does so much cool stuff. The "free" HTTP API and client replication via PouchDB are the two huge ones. But it just wasn't smooth enough to get the data out, use it where I wanted, and then save it back.

I had to write my own libs/helpers to interact and make it feel friendly to the developer when I used it with Rails in the past.

But after that, it was very nice.

Re: CouchDB 3.0

#78

Post by lhuser123 »

yatsyk wrote: post #68
newfeatureok wrote: post #63

Earlier quoted context omitted.

There are plenty of proxies that do that with some config like nginx. Even if you were using a relational database with a backend you’d still have to solve the same problem.

If I use backend I can create all validation logic in application server. But in this case no automatic synchronisation. One of the major selling point of couchdb is replication protocol for client-server data syncing. When you design product with posgress you don't allow to execute raw sql queries from clients without any application server. But looks like it is recommended way to update data in couchdb world if you…

Couchdb has options for controlling which documents are replicated. This may help depending on your use case.

Re: CouchDB 3.0

#79

Post by codetrotter »

devhead wrote: post #59
xwowsersx wrote: post #38

Earlier quoted context omitted.

it's = "it is" its = possessive form of "it" So should be "it wins for its unique..".

there's always one...as in there is always one who has to poke people for grammer. sighs.

Personally I wouldn't mind corrections on grammar. But I agree that the comments about grammar, even though in my opinion somewhat useful, still add noise to the discussion as a whole.

I've been thinking about this and, I think having a "grammar patrol" that had the ability to alter other people's comments for grammar on a site like HN or Reddit might be useful. Maybe. Of course there is potential for abuse. So you'd need a second group of people at the very least, who were given the ability to vote on the edits themselves as good or bad.

This second group would be the most difficult to establish and maintain at scale I think. Because whereas you could in theory allow anyone to volunteer as grammar patrol, you'd need to have a trusted group of people for group two. Otherwise, a group of trolls could sign up for both groups and make bad edits and then approve them.

At the end of the day it would probably require a lot more effort than what it's worth. Grammar mistakes are a bit of an eyesore but at the end of the day they usually aren't the end of the world.

Also, language is ever-evolving. So if in 50 years 80% of the population is consistently making a common set of grammar mistakes then that just means that the way to spell those words has changed.

Re: CouchDB 3.0

#80

Post by yatsyk »

Volundr wrote: post #67
yatsyk wrote: post #48

CouchDB/PouchDB looks very promising for offline first apps, but I can’t understand how to restrict bad clients. Client potentially could insert document of huge size or execute expensive query and degrade experience of other clients on the same server. Is it any way to prevent this?

A couple ways: One you implement validation functions [1] on user databases to control what kind of data can be inserted into couch. These functions can only be changed by database admins, not users, so can act as a security mechanism controlling what goes in. As mentioned by others you can also implement a proxy. This doesn't have to interfere with sync functionality, you just have to make sure you proxy all the end…

Thank you for pointing at validation, I'll check it. It's not completely clear what is it possible to limit not only particular document but database, or how to handle conflict if document changed on pouch, but rejected on couchdb server.

I'm not sure about current time but previously it was a problem that couchdb file grow until some limit on filesystem and couchdb just crashed.

Start of the envoy readme: it's not battle tested or supported in any way. Also it doesn't do any validation apart from limiting permissions for different users.

It's easier to reimplement couchdb than to create smart proxy that will estimate is this query expensive or not.

I'm not saying about rate-limiting proxy or load-balancing to different backends which could be implemented on nginx or something else.

Post reply on HN