7

I'm new to CouchDb and am trying to comprehend how to properly make use of it. I'm coming from MongoDB where I would always write a web layer and put it in front of mongo so that I could allow users to access the data inside of it, etc. In fact, this is how I've used all databases for every web site that I've ever written. So, looking at Couch, I see that it's native API is HTTP and that it has built in things like OAuth support, and other features that hint to me that perhaps I should no longer have my code layer sitting in front of Couch, but instead write Views and things and just give out accounts to Couch to my users? I'm thinking in terms of like an HTTP-based API for a site of mine, or something that users would consume my data through. Opening up Couch like this seems odd to me, though. Is OAuth, in Couch's sense, meant more for remote access for software that I'd write and run internal to my own network "officially", or is it literally meant for the end users?

I know there might be things that could only be done through a code layer on top of CouchDB, like if you wanted additional non-database related things to occur during API requests, also. So thinking along those lines I think I will still need a code layer, anyway.

Jake
  • 261
  • 1
  • 17
Ryan
  • 7,733
  • 10
  • 61
  • 106

2 Answers2

4

Dealer's choice.

Nodejitsu has a great writeup on this sort of topic here.

Not knowing your application specifics I'll take a broad approach...

Back-end

If you want to prevent users from ever seeing your database then make it back-end. You can pipe everything through something like node.js and present only what the user needs to see and they'll never know anything about the database. See Resource View Presenter

Front-end

If you are not concerned about data security, you can host an entire app on CouchDB; see CouchApp. This approach has the benefit of using the replication mechanism to control publishing your site/data. The drawback here is that you will almost certainly run into some technical limitations that will require moving CouchDB closer to the backend.

Bl-end

Have the app server present the interface and the client pull the data from the database separately. This gives the most flexibility but can be a bag of hurt because even with good design this could lead to supportability and scalability issues.

My recommendation

Use CouchDB on the backend. If you need mobile clients to synchronize then use a secondary DB publicly exposed for this purpose and selectively sync this data to wherever it needs to go.

Jake
  • 261
  • 1
  • 17
  • Why cant mobile clients use an API on the website, which communicates with CouchDB on the backed? That way you control access? – Piotr Kula Apr 09 '14 at 20:24
  • You certainly can, that's the "bl-end" option. There are lots of ways to develop a SOA style API interface that exposes CouchDB data as well data from other services. – Jake Apr 10 '14 at 21:22
1

Simply put, no.

There's no way to secure Couch properly on a public facing site. There's no way to discriminate access at a fine enough granular level. If someone has access to any of the data, they have access to all of the data.

Not all data on a site is meant for public consumption, save for the most trivial of sites.

Will Hartung
  • 115,893
  • 19
  • 128
  • 203