Single Page Applications offer many opportunities to increase performance and availability while reducing hosting costs. Unfortunately, it comes with some compromises and potential threats.
What is a Single Page Application?
An increasingly more popular, but not necessarily new, paradigm for web application development is the single page application (SPA). Sometimes this is also referred to as a “fat client.” It’s called this because of the way application resources are delivered to the consuming device, whether it be a desktop browser, a mobile phone, or television set-top-box device.
In traditional web applications, all processing is done on the server to fetch data, run business rules, render html output, and so on before the content is sent to the browsing device. The device then displays it. Each time an action is taken, the process begins again. Some resources are cached between actions, but often times all new must be downloaded again.
To clarify, a single page application is not actually an application with only one page. It simply means browsing device only pulls the initial resources once, and then navigates between view states without refreshing the page.
Strengths of Single Page Applications
Because the application isn’t going back to the server between page changes, the transitions are a lot smoother and nearly instantaneous. This makes the application feel more like a desktop app in how responsive it is.
Additionally, because of the way resources are packaged, the total resource download is considerably less. This reduces bandwidth consumption, both for the end user and the server.
Not to mention that the bundling puts all the static resources in the initial download for the device. This permits the end-user to conduct some operations while offline or without having to return to the server.
Weaknesses of Single Page Applications
Another common issue is that when a script fails hard, it can crash or hang the entire application. After this happens, no buttons or links will respond on the page. In a multi-page app, code is more compartmentalized. So an error in one discrete section of the app would not affect other portions.
Lastly, we have to acknowledge that this structure adds complexity to the software framework stack. Any time you do that, you make the system more costly to develop and maintain because it involves more labor. More moving parts also means more things could go wrong.
Opportunities of Single Page Applications
The single page application structure almost completely divorces client-side logic from server-side logic. Because of this, client-side resources can be served from a low-cost, low-latency, high-availability content delivery network (CDN) that leverages distributed caching (served from multiple cities around the world). Amazon’s CloudFront is a prime example of such a service that we frequently employ for our clients. This removes burden from your application server, which permits the same resources to serve more end-users and ultimately reducing hosting costs.
More to the point, this structure moves processing from the centralized server to the distributed client. So each end user picks up their share of the processing, also leaving the server infrastructure to assist more users with fewer resources.
Single Page Apps typically communicate with the server through a JSON based RESTful interface. What this means is that you could exchange either component of the system so long as it still complies with the same interface. Say for example, you write a JSON interface in ASP.Net, but later discover you need to deploy on a Linux server. You could replace the server-side logic with PHP or Node.js without refactoring the entire system.
Threats of Single Page Applications
How Smart Software Approaches Single Page Apps
However, we jump at the opportunity to develop fat client applications for those seeking high performance, high availability, highly interactive, highly responsive, distributed cloud solutions. Several of our clients are actively using such systems and are reaping extraordinary benefits.
As of late, our preferred front-end framework has been AngularJS; having made the shift from Prototype and JQuery exclusively. We also leverage Bootstrap frequently, or other Jquery components for rich UI elements.