Other than being a great solution for some problems I wanted to highlight the fact that CouchDB has commited to SpiderMonkey (the Mozilla JS engine) since the very beginning and is one of the few projects helping to fend away the V8 monoculture.
CouchDB 3.0
81–90 of 161 posts
Re: CouchDB 3.0
#82At this point why would you use CouchDB over something like MongoDB? Seriously asking... Over the past 5 years MongoDB has gotten a great storage engine, transactions, distributed transactions, multi master replication, first class change streams and is very very solid as a foundational piece of infrastructure you can rely on while CouchDB has languished. I can’t imagine reaching for it in my tool belt when I need a…
1. MongoDB is no longer Open Source. 2. MongoDB's design has historically been terrible; and, from my current experience with clients, is still a source of 'WTF's.
[deleted]
Re: CouchDB 3.0
#83Earlier quoted context omitted.
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.
Is it any documents that describes secure couchdb architecture? Most of the articles I find are limited to authentication and basic permissions.
Re: CouchDB 3.0
#84Earlier quoted context omitted.
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 b…
I'm not clear what you mean by limiting "not only particular document but database". As far as a document changing in pouch and rejected on the server, that's one of two scenarios.
1) The client you wrote is bugged and generated bad data. This scenarios can occur just as easily using Postgres and an application server. What does your app server do if a client tries to send bad data? (Answer: Whatever you told it to do. Most likely throwing a 500 when your databases refuses the incoming data.)
As for what will happen when pouch syncs to couch the server will let everything else sync, but not the bad document. The return value from the API call will tell you what documents didn't sync.
2) Someone is intentionally trying to shove bad data into your database. In this case it's worked as advertised and rejected the bad data. What do you care if a malicious client breaks?
What kind of "expensive" query are you envisioning? Mango queries don't support joins, and only simple equality filters, so in general the worst thing someone could do is send a query that doesn't use an index, but why are you letting the client query the server in the first place? Just have the client sync and query client side. Or don't allow access the the _find endpoint and restrict them to the map/reduce view you handwrote.
If you must let them send arbitrary queries (which to me implies a relatively trusted user, but let's pretend their not), then run the query with a limit of 1 or 0, and examine the execution stats to see if they are using an index, and check their query to see if their limit is reasonable. But at this point you've now entered into a scenario that's going to be very difficult with a custom API too.
Re: CouchDB 3.0
#85Earlier quoted context omitted.
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 b…
Also as far as database size, I don't believe there is a hard limit. I think you might be thinking of when MongoDB would silently corrupt databases larger than 2GB on it's 32-bit version.
Re: CouchDB 3.0
#86One interesting thing you can do with CouchDB is that you can have a webapp where a user can specify their own database and credentials and it works over HTTP(s). That's pretty unique. I'd love to see a SaaS using CouchDB and their "on-premise" offering just means the user provides their own database. I'm not sure how payment would work though - perhaps some verification proxy? Firebase is the gold-standard for offli…
Cloudant off IBM cloud. Full disclosure; I utilized it to support the application layer on IBM cloud.
Re: CouchDB 3.0
#87I built two products on CouchDB 1.x starting in 2010 ... version three is another amazing step forward! For my more recent projects, I've replaced CouchDB with clustered PostgreSQL using JSON columns as I really enjoy the ability to write SQL queries for against the JSON and to use the built-in full-text search capabilities. I think both CouchDB and clustered PostgreSQL are amazing tools and it's nice to be able to c…
I've gotten the impression that clustered Postgres still isn't very straightforward to run. Do you mind elaborating on your ideal setup and point to some resources?
Thanks!
Re: CouchDB 3.0
#88Earlier quoted context omitted.
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 b…
I'm not clear what you mean by limiting "not only particular document but database". As far as a document changing in pouch and rejected on the server, that's one of two scenarios. 1) The client you wrote is bugged and generated bad data. This scenarios can occur just as easily using Postgres and an application server. What does your app server do if a client tries to send bad data? (Answer: Whatever you told it to d…
> I’m not clear what you mean by limiting "not only particular document but database".
I’ve limited document size to 10mb and ratelimited updates to 10 per second. Client starts to update document with random data 10 requests per second. As far as I understand couch stores all versions at least some time. This means that this one client could fill space on my server 100mb/s. There is no such issues with postgress, and no one allow clients execute raw queries on database without any application server. Document only 10mb but database is huge.
> What kind of "expensive" query are you envisioning?
I have never used couch, so I don’t know what could be expensive. May be some lookup without index or something like this.
Sorry for my ignorance, is it true that if I limit couch only to replication it will not be any not indexed lookups?
Looks like implement secure system with couch is very hard but I can’t find any best practices, mostly only authentication and basic validation.
Re: CouchDB 3.0
#89Earlier quoted context omitted.
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.
Is it any documents that describes secure couchdb architecture? Most of the articles I find are limited to authentication and basic permissions.
What kind of document are you looking for here? There is [1], but yeah, that covers access controls. As do the MongoDB [2] and Postgres [3] documents.
I feel like your thinking about Couch as exposing your entire PostgreSQL DB to the internet, whereas with couch, a common model is to have a single database per user. In the Postgres model, providing the end user with any direct access is a nightmare, because every other users data is in there and I have to keep other users from viewing/modifying it. In Couch, you give them access to their database and only their database, that's how you isolate users.
[1]https://docs.couchdb.org/en/stable/intro/security.html
Re: CouchDB 3.0
#90Earlier quoted context omitted.
>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.
Did you open source these by chance?