Directly accessing server database via Ajax (without PHP or some other intermediate)

Question

With powerful frameworks like jQuery, it seems to be possible to build an entire app logic on the client side. It's very much analogous to building a client app as a native program.

Now suppose this client app needs to access a remote database. The usual solution seems to involve the layers Ajax/PHP/MySQL.

It seems to me that the PHP layer is no longer needed; all the logic and UI is taken care of by the browser app.

The question then is: Shouldn't there exist a (hopefully robust and secure) database server that simply takes on an HTTP request, and returns an XML result? This result can then be easily parsed by e.g. jQuery on the client side.

I can't seem to find a database or framework along these lines. Any ideas?

Answer 1

I suppose one could do that, but PHP is rather more convenient for manipulating result sets. Also, the traditional approach provides an extra level of security so that machines in the wild don't have direct access to the database, and all the usual webserver security and access controls can be used.

Answer 2

Well, the annoying part is going to be authentication.

Because code is ran completely on the client side, the client then knows all of the authentication details to access the database server.

This is rather .. err ... unsafe. Which is probably why not many people have developed a direct-access server..

If you really want to keep the PHP/Server-Side scripting to a minimum, make a fairly robust PHP proxy than properly escapes all data. Keep the configuration details in a separate protected ini file, or even the php.ini file, and you can pretty much ignore the server-side scripting after that.

Answer 3

You mean, is there a database that natively supports the HTTP protocol? Well, there are some. You have MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/XRPC/), and a NoSQL databases like CouchDB (http://couchdb.apache.org/). You also have it in more traditional rdbms-es like Oracle (Oracle Application Express relies on a built-in HTTP server, aka the APEX service http://www.oracle.com/technology/products/database/application_express/index.html) and MS SQL (Service schema object like http://msdn.microsoft.com/en-us/library/ms190332.aspx and XML views, see http://msdn.microsoft.com/en-us/library/aa286527.aspx)

But really - you should question whether this is really that useful.

I mean, there is always going to be one component that handles HTTP. You may have the feeling it is good to take out the webserver/php layer because you feel it is extra, and sits in between the app and the database. But really, the solutions I just mentioned aren't that different - they are tagged on top of the same piece of software, but the data still has to flow through that extra layer.

And you can wonder whether that is really beneficial the have it all in one piece: with a separate webserver, you can scale out the webserver layer independently of the database server. Or you can scale out the database layer independently of the webserver layer. If it's all one piece of software, you can't.

Basically, by building the http server into the database, you're burdening the db server with a task which consumes resources that could have been used for other db tasks. Now think about a common case, where you paid for a per-processor license of your db. Would you really like to spend that license on having the db handle HTTP requests, when you could have done exactly that with a free webserver like apache? Even if you're using a free soft database product, in many cases the database server is a bottleneck. Do you really want to put more tasks on it's plate by building a HTTP server into it?

There's another reason why i think it's not that good an idea. You mentioned XML as data exchange format. Goody. But what if you want JSON? Or YAML? Or perhaps plain CSV? Webserver scripting languages like PHP, ASP.NET, Perl, and even Java all have very good libraries to deal with these things. Typical database stored procedure languages do not. Of course, you can take it a step further and say, hell, why not build say Java or .NET into the database, but that is turning the problem upside down again - the database's task is to store and retrieve data, and take good care of data while it's stored. Processing data to present it to an application is not part of that. If you make it part of the db's job to take care of that, you take away an important source of flexibility and scalability of the system as a whole. You may feel it is less overhead because there's one component less (ie webserver/scripting language) to think about, but in reality, it's still there, it just hides inside your database software, and sucks up the resources that could have been used for storing and retrieving data, parsing queries etc.