the web is an app

I’ve been thinking a lot recently about what apps mean for web development, and how they intersect, and my conclusion so far is that very soon web apps will always be built… as apps.

What do I mean by this? Apps are user interfaces optimized for a particular device or screen, and they communicate with servers purely through APIs. Web servers for apps never serve HTML content directly – they expose REST APIs that render JSON (or, alternatively, XML). It used to be that for typical website development you would create a website that connected to a data source (conceptually – naturally there’s a lot more going on) to generate HTML. Inevitably, pages would end up mangling at least some amount of back-end data management (no MVC model is perfect), and the server defined what to render depending on the capabilities of the user’s browser.

Then, to create an app (typically for iPhone or Android), you would create a separate access path with APIs that would also connect to the data store. The result is two separate sets of business logic that over time become a pain to maintain, or a complex rearchitecture project that involves pulling the business logic out of the web app code so that it can be moved to a separate library or codebase that can be shared by both the APIs and the web app code.

Now, taking into account some interesting, very solid trends:

Put all of these together, and it has become perfectly feasible, and I’d say preferred, to build a web app as just another app, albeit one written entirely in JavaScript, CSS, and HTML5.

In this scenario, the “website” is really one static HTML file that initializes the JavaScript code, which dynamically decides what is the appropriate set of libraries and client code to pull from the server. Once the client is initialized, it can authenticate via OAuth or similar to the APIs, just like any other app client does, and will afterwards only talk to the server via the REST APIs.

This results in a very different front-facing architecture for websites from what we’ve gotten used to (and the change ripples out significantly to backend architecture as well). You can just load up an Apache instance or two to have comfortable static file serving capability, and the entire dynamic front end becomes a set of APIs that is shared across all devices – including PC browsers. The backend becomes simpler to build and maintain, because there’s zero display logic embedded in it. It’s just a data interface.

This has big implications for how we build websites and webservices. Designing a website as a giant API is not something common (APIs are generally bolted on later). Frameworks like Rails teach people to think in terms of pages, not function calls, which is what web requests become when the website is only an API. Libraries like Jersey and Atmosphere will become more important than Spring, since most of what you need is already there, and they’re simpler. Also affected are how we handle everything from outages to Operations, since load balancing and failure handling become different in a world where the user interface components (served as static HTML) have much, much lower probability of failure than the dynamic data components, and a lot more data can be handled statically as well.

Major services are already evolving in this direction. Google has led the way for deploying these ideas at scale, with rich web apps like Gmail or Google Reader. Unsurprisingly, GWT itself has this model as the centerpiece of how they approach software design.

This also intertwines with the topic of “hybrid apps” as I call them – apps that provide native shells that nevertheless use an embedded browser to handle a lot of common behavior (e.g. on the iOS platform, The App Store, Netflix, and other apps are really just shells for webkit) – but that’s a topic for another post. :)