SPAs (single page applications) are all the rage these days. Here at Wombat, we’ve got at least four in active development among different teams. Each of these SPAs is the user-facing portion of a subset of the functionality in our integrated SAAS solution. I would propose that a single SPA solution for the entire feature set should be our ultimate goal for the user interface. However, I understand that there are significant challenges to doing this well. In this series of blog posts, I’d like to discuss how we can arrive at an architecture for SPAs that meets three very important goals:

  • provide a consistent (and consistently excellent) user experience
  • stay DRY at the solution level by avoiding writing code for the same functionality across multiple SPAs
  • allow for agile development inside each “product” team, including the de-coupling of deployment

I plan the following additional installments in the series:

  • why a single SPA?
  • challenges in the single SPA approach in a multi-product, multi-team solution
  • loose coupling in a single SPA
  • suggested architecture for a single SPA solution

For now, though, I’d like to spend a little time talking about why we even make single page applications. Before we get into specifics, I need to point out that of course any benefits of a SPA are dependent upon good architecture and sound implementation. It’s much easier to write bad code than it is to write good code. It’s especially easy to write bad JavaScript.

Better separation of concerns

To me this is the primary benefit of a SPA, and it is a driver for many of the other benefits. Simply put, a SPA is the ultimate separation of your user interface layer from your business and data layers. It forces you to provide a full API into your application, which can come in handy in a number of situations.

For example, once you have a SPA in place, you can in theory completely rewrite it without changing a thing in your business and data layers. You can write a native iPhone app and have it use the same backend API. You can utilize the API to provide connectivity from partner applications or additional sources of data. You can quickly provide a data feed to anything that needs it. You can use this full API to do extensive unit testing in a headless manner, or to set up user interface tests.

Increased performance

This benefit is perhaps most highly reliant upon implementation. You can of course create a SPA that is less performant than a traditional web application. However, if you do it right, you can realize some significant performance increases.

First, understand that a SPA offloads a lot of your computation to the client. Rather than running a templating engine on the server side, we run the templating engine on the client side. This can be a significant savings in overall computational requirements.

Second, a SPA done correctly puts less of a throughput load on your server-side application framework. Rather than having your server-side application stack composite a bunch of templates into a page, the templates (in minified and concatenated form) can be cached using a CDN - only the actual application data needs to be run through the server-side application stack, not the associated markup.

Finally, a SPA can quickly redraw parts of the page, using either data already available on the client or data retreived via a small AJAX request. This can improve the perceived performance of the web application, and allows for a user experience design that more closely mimics a traditional desktop or mobile application.

Improved user experience

As stated just above, users continue to expect an experience that is quick, richly interactive, and intuitive. Many of the techniques for providing such an experience, like predictive search auto-complete or real-time notifications, already require AJAX because a full page reload is just too disruptive to be of any use in those scenarios.