Cross-Origin Backend

By saying your app ‘has no backend’, what we really mean is that it’s using a generic backend, that is not specific to the app (and thus, not part of the app as such). One advantage of keeping backends generic and putting all app-specific code in the frontend, is that you can use a backend that is hosted somewhere else.

An example of this are Dropbox-based apps: you get an API key from Dropbox, and develop your app as a static JavaScript app, which stores all its data on the user’s Dropbox account. Thanks to CORS headers (which the Dropbox API supports), your in-browser app can make a cross-origin AJAX request directly to Dropbox, without the need to go through a proxy server.

Like Dropbox, GoogleDrive have also started supporting CORS headers on their API. You can use a client-side library like NimbusBase to make it easier to access both Dropbox and GoogleDrive, without having to write any XHR requests yourself.

Last week Dave Winer blogged about Amazon joining the cross-origin backend bandwagon, with the following words:

It doesn’t happen very often when there’s a true tech breakthrough, but this is one of those moments. If you care about Internet applications, pay attention to this one, it’s important.

We also discussed it on the unhosted web apps mailing list. Is this exaggerated, or is there a real trend here?

I think cross-origin backends are the future. Before a couple of years ago, the frontend code running in the browse could only connect to the backend server that corresponds to that application, on the same origin. There was a one-to-one mapping between frontend apps and backend servers.

If your app would connect with third-party services, then all requests would have to go via a proxy server (see Dave Winer’s post for a further explanation of this). It makes a lot of sense to separate the app’s origin (the frontend domain name, where you visit the app) from the backend’s origin (the server API domain name), and to let frontend apps develop freely without the need for proxy servers.

Dropbox, GoogleDrive, and Amazon already support this (although the real pioneers, even before Dropbox, were actually Flattr). At the remoteStorage project we are developing a common REST API for generic storage backends. It’s called simply “remote storage”, and is now an Internet Draft at the IETF.

If you want to know more about cross-origin backends and unhosted web apps, then you can come to my talk at QCon on Monday (San Francisco), or any of the upcoming unhosted web apps meetups - next one is in Portland, 16 November!