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:
- The increasing power of browsers in handling more complex logic, and new APIs (for runtime, data, semantics, and display) provided by HTML5
- The imminent demise of IE 6 (let’s hope) and increasingly tiny market share of other older and less capable browsers
- The continued improvement of solid web client-side development frameworks, like GWT and SproutCore.
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. 🙂