couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Hartung <wi...@mirthcorp.com>
Subject Couch as an App Server
Date Fri, 24 Jul 2009 00:45:56 GMT
I've written and restarted this email at least 4 times now :-)

Sometimes, some of the old content carries forward, but mostly not.

I wanted to comment on some of the distinctions the I see between an
App Server and a DB server. This was prompted by a chat in IRC.

After much rumination, and typing, I think I've formalized it down to
a single point.

The key difference between an Application Server and a Database Server
is that the App Server has control over the services that it
publishes, whereas a DB server does not.

Simply, App Servers create and publish application specific APIs,
whereas DB Server publish DB Server APIs.

This is modulo any administration APIs the App Server may publish that
are "out of control" of the developer.

If Couch were to become an App Server, then, naively, it would publish
both DB server APIs as well as the Application APIs.

In the Application Server space, I think a Couch developer would need
to be able have full control over whether the DB APIs are published.

When someone publishes both the DB API and the Application API, again,
naively, it's like publishing a OOP Class with all of the internal
variables public. There is the potential for a client of the server to
"route around" the Application API and work with the internal data
directly. Not necessary a bad thing, but most probably not a good
thing.

Simple example.

Back in the day, there was a proliferation of "Client/Server" "fat
apps" that would run on client machines and were connected directly to
backend databases. At a minimum, those C/S applications had embedded
SQL code within them.

If someone were to create a Javascript, browser based "fat app", using
standard XHR techniques, pretty much anyone would consider it "insane"
to have embedded SQL within the Javascript, implying that the server
is actually accepting raw SQL strings from the client and executing
them. To quote Linus Van Pelt: "Tooo dangerous".

This would be similar to what would happen if you put a couch DB
"live" on the web.

How to work around it?

The simplest case is to limit access to the DB API through security,
providing separate security setups for Applicaton  APIs, and DB APIs.

But, IMHO, that's quite limiting. I think folks will want to be able
to publish Couch databases directly on to the web for use by Ajax
clients.

At the same time, I don't think they will necessarily want enable the
entire database to be available to client. You may want to publish you
blog content in Couch, as well as comments, and perhaps "private
messages" in the same DB. A single _all_docs and those messages are no
longer particularly private.

That implies there needs to be some finer granularity.

Perhaps we could selectively enable views to be readable, and that
works fine as long as _doc_ids aren't "fishable" so folks can get docs
outside of views. But with the common meme about incremental ids, that
casts a bit of a shadow on that.

What I think really needs to happen, though, is being able to
intercept the requests going in to and out of the Database.

In the Java world, you would implement a Servlet Filter.

With a filter, combined with user credentials, you could deny requests
for specific id patterns (user_*, say). Or, on return, you could
introspect JSON payloads heading back and strip out sensitive
information (delete payload['password']).

The concept is simple, but it's a very powerful enabler.

Later, as common use cases come up, (granular ACLs, or whatever),
those could be made more "first class" within the Couch API, but until
then, this mechanism is, I think, a great placeholder.

It could even be placed on views, etc.

To me, it's the "simplest thing" that works that can make Couch an
acceptable App Server while still providing "native" DB functionality.

Curious about your thoughts.

Regards,

Will Hartung

Mime
View raw message