If you’re just joining this column, it is one aspect of a response to the gap between how development and how operations view technology and measure their success – it is wholly possible for development and operations to be individually successful, but for the organization to fail. So what can we do to better align development and operations so that they can speak the same language and work towards the success of the organization as a whole? This article series attempts to address a portion of this problem by presenting operation teams insight into how specific architecture and development decisions affect the day-to-day operational requirements of an application.
This article introduces a new topic: Single Page Applications (SPAs). It introduces SPAs, compares and contrasts them with traditional request/request web applications, and reviews the usage patterns that can affect the management of SPAs by DevOps.
Introduction to Single Page Applications
The term Single Page Application, or SPA, might be new to your ears. I know when I heard the term SPA that I had absolutely no idea what the web team was talking about. And when they told me that a SPA meant that the entire web application was either a single page or broken into small applications that consisted of single pages, it did not help much.
In short, a SPA is a different design approach to building web sites. Rather than following the traditional request-response paradigm, a SPA loads the structure of a web page and then makes service calls to load the data to present in that web page. When the user navigates to, what was once a different web page, a SPA application loads an HTML fragment for the new page, makes service calls to load the data for that new page, and then manipulates the browser’s Document Object Model (DOM) to show the new content inside the exist page. The result is closer to a traditional thick application client that is more responsive and feels more like an application you would run on your desktop.
To fully appreciate this paradigm shift, let’s review traditional web applications and see how this model evolved. Figure 1 shows the request-response model in a typical web application.
The browser requests a page from the web server so the web server loads data from either a database, one or more web services, a legacy system, or from the file system, constructs a full HTML document that contains that data, and returns the full HTML document back to the browser. The HTML document has links on it that reference other pages, so when the user clicks on one of those links the whole process starts over again. This is the model that we have become familiar with and the delays between page loads are expected.
In this scenario, the browser is little more than a thin client that displays or renders the HTML page. Furthermore, the browser does not know anything about the user: when the user follows a link, the browser makes a page request and includes any cookies that the server has previously returned. This means that the web server maintains the user’s state. This should remind you of the old mainframe days in which we used green text-based terminals to connect into our applications, only now our green terminals are rich multimedia engines!
And along came AJAX
Today’s web browsers, and even today’s mobile web clients, probably have more power in them than the old mainframes that we connected to decades ago, so why do we continue to use them as dumb clients? This is one of the motivations that inspired SPAs: the browser is more than capable of hosting full applications, so how do we build full applications that run inside of a web browser?
In this model, pages became more interactive and feature rich, but we were still building web applications as a collection of different pages. And again, all state was maintained on the web server. Years of AJAX adoption passed and companies started building SPA-like applications, but it would be a while before we started seeing frameworks specifically targeting SPAs.
Since then, however, we have seen a host of SPA frameworks emerge. Here is a brief sampling, but there are many more:
The core features of SPA-based frameworks address the following concerns:
- Views: support for switching views as the user navigates through the site
- URL-routing: how does the framework route URLs to both services and HTML fragments?
- Search Engine Optimization (SEO): how does the framework handle search engine analysis? This was particularly problematic when SPAs first came on the scene because search engines looked for links and followed links to discover a site, but SPAs don’t follow links, instead they load data from the server when they need it. There are different strategies – one thing to help SPAs was that Google added support for following URLs that started hash fragments (#!)
- Browser History: because SPAs load data and render pages dynamically, how can you add bookmarks and how do you manage browser history?
- Analytics: because analytic frameworks rely so heavily on page changes, how does the framework still enable to application to report their “page views” to an analytics solution
- Initial Page Load: because SPAs tend to be heavy in that the initial page load contains the majority of the HTML for the application, how does the framework manage performance and subsequent page load to reduce the initial page load cost?
In forthcoming articles we will review some of the more popular SPA frameworks and show how they affect the infrastructure you’ve been tasked with managing.