CuouchDB will probably get there as far as simple data access control is concerned. (Who’s allowed to read/create/update/delete a document).

However, for all but the simplest of apps, more granular user authorization will be required.

Example: User “A” cannot create an order document where the total cost exceeds $5000; User “B” is limited to $10000.

These types of edits must be enforced in a locked room behind a firewall running in a secured user account. They cannot be done on the end-users browser.

I suspect the good people of the CouchDB community will try to add these types of business predicates, just as SQL-98 did with the ASSERT declaration (and I suspect they will be no better received).

One key to the scalability is to get good caching for hot data that’s continuously re-read in order to keep hotspots in your object store from crippling performance in the application. If your app has hot spots of data, then you’ll want to work right at the object store (in the REST part of your NEW diagram) to allow efficient insertion of a cache (CDN, etc.) between the client and the application for reads, or integration with a distributed memory cache like memcached. Ideally your object store (CouchDB in your setup) has sort of functionality built in, rather than relying on disk reads (or even page cached reads) per request on a storage given node.

I prefer to have a CDN between the client application and the data store in order to reduce the RTT (latency) of fetching frequently accessed data that’s common between multiple end-users of the application. This is particularly important if you have a globally distributed user base. If you use a good CDN that works well for small files, then you can achieve a cache that’s closer to your end-users than your object store, driving better performance, and a higher degree of efficiency and interactivity.

Making this work right means that you need full RFC2616 support in your REST layer so that If-Match (section 14.24) capability is fully supported, you set Cache-Control headers properly to suit your application (needs vary here, no single solution fits all).

Now you might argue that data should be de-normalized in the object store so that you don’t have hotspots. Perhaps that you should pepper replicas of frequently accessed data all over the object store so that all nodes get equal shares of work. That’s fine, but that model is not as efficient as having a high performance distributed cache. It just spreads out the work. You get horizontal scale, but no real efficiency boost.

http://www.slideshare.net/secret/EcxO2A5MZia1q4

— MV

–

Great article.

Re Crawling: CouchDB has built in transformation functions that can turn any JSON into static HTML for google to crawl.

Re Security: Even if CouchDB’s auth model will go all the way eventually, the main use case for it is having an instance on each personal device (laptop, desktop, set top, mobile, whatever) with all a user’s local data (and maybe a a copy of her peer’s data). Security is less an issue here with a centralised server system. CouchDB replication is used to sync all these devices and auth & replication filters already can ensure that a user can only replicate the date she is allowed to. With that data, and the application itself, she can do what she want.

Cheers
Jan
–

Powerbuilder in Javascript should rock. Many congratulations on the awesomeness.