Browsers have not been considered as a compute resource to aid in scalability and fault tolerance. Through the use of modern Java Script frameworks, the browser is now an integral part to be considered when building applications. In this article, we will discuss the evolution in the delivery of applications to users with a focus on user experience, reliability, and the value of Single Page Applications (SPA).
Today, we all expect that any application used personally or in business is available in your favorite browser, on your favorite platform. This method of application and experience delivery has enriched our connected anywhere world fulfilling the promise of ubiquitous functionality and access. Before there were web browsers, we relied upon applications installed locally on our computers. From there, we moved into local and wide area networks which allowed our installed applications to share data via file stores and databases. This was the era of client server applications, many computers sharing the resource of data. We remained in the client server world of computing and at the beginning of applications as a service via Application Service Providers (ASP) and distributed, read-only content being provided via Hypertext Markup Language (HTML) to browsers. As the connectivity of the world wide web was introduced and higher-level transport protocols such as Secure File Transfer Protocol (SFTP), Remote Secure Shell (RSH) and Secure Hypertext Transfer Protocol (HTTPS) evolved the local and wide area networks while still critical to business systems were touted as being things of the past.
Fast forward to today and we see computers with very few locally installed applications. Most of our applications now live in our browsers. As web application technology has advanced our experience with applications on the web only gets better and better. Richer content, more sophisticated user experience and so very fast. Gone are the days or waiting for new pages to load from requests made to the server. We now become annoyed when screen refreshes or page loads take longer than a second. We will tolerate a video stream spinning up. This is primarily due to our perceived understanding that video files are huge. How have we achieved these lightning-fast browser-based experiences?
The first benefit is to ensure everyone has the latest version of the program. You get the latest and greatest every time you browse to that page. Second, it protects your computer as the application running in the browser as the browser does not have direct access to the resources on your local machine. It cannot talk directly to your printer or hard disk. The web application is purpose built to run as fast as possible and provide you with the most engaging and comfortable experience. There are many strategies and technologies which help deliver applications which we will leave to another time. We will now start to focus on some of the strategic benefits of delivering web applications.
In the past, we would browse to a web site and be presented with a page. We may fill out a form. select a link or press a button. From that event, the web server would process that event and send you a new page based on the outcome of the server programming logic. Every time you did something meaningful a new page would be served. This type of experience did not provide much continuity between the pages and it felt like you may be starting over with each new page. Then shopping carts happened. Now you could select things into the cart and with every new page the cart came along and remembered the items chosen. We now had a small level of continuity in our experience. Another way to say this is, we were able to maintain the semblance of state. We were stateful by using a few ticks known as session state provided the implementation of things like cookies. A cookie is a piece of data which goes back and forth with every web request.
- Installed applications operating in isolation – time of floppy disks.
- Installed applications sharing files or databases in a central location – time of departmental servers.
- Installed applications via a local / wide area network and dial-up provided content and communications via email and chat.
- Interactive web sites via the internet enabling users to perform simple tasks – shopping and forms completion.
- Web applications with rich user experience and functionality; Single Page Applications (SPA) – replacing installed applications.
Promise of Single Page Applications
Again, fast forward to today. All of this has now evolved effectively into a modern “client server”. We are in the age of Single Page Applications (SPA). I reference “client server” not to diminish the advancements in technology, only to focus us on the similarities between browser run applications interacting with central data stores to installed applications interacting with remote databases. Single Page Applications now allow us to run true software in the browser, provide a truly stateful experience and achieve the current holy grail of application delivery. There is not a definitive date when SPAs hit the browser scene and the concept was first discussed in 2003.
Your browser is running on your device. Your device has computational resources provided by your CPU and memory along with communication resources provided by your network connection. These local resources or compute cycles off load the web server which is providing application and data support services. This means the server that resides in AWS or Azure no longer must serve pages to you with each request or execute logic necessary to provide a brilliant user experience. It is all local in the browser on your device. The more work you push to the browser, the less resources required on the server. This is a very real consideration when assessing and creating scalability in an application.
Software product companies prior to this new world would generally implement two sets of APIs. One to support their web and mobile applications and one to support external application or service integrations. With the advances in SPA capabilities, these same software companies find it easier to collapse into a single set of APIs as their web and mobile applications are happily served by the application integration API. This shift creates direct and indirect value to applications. First it reduces the development and testing effort for server APIs. Second it ensures that the application architecture and encapsulated business processes are fully realized. No more hiding undefined business logic or data comprehension in the web or mobile applications that was not available in the integration APIs.
In product designs and architectures, we attenuate to stateless applications. By removing application state-fullness several scalability options become available. We can replicate application environments behind load balancers which allow any server instance to serve the application without requiring session stickiness (when a user must use a specific server). We can separate areas of concern / services across servers and may consume them based on availability. One server becoming unavailable due to scheduled or unscheduled down time no longer impacts the availability of the application you are running. SPA provides us with a mechanism to easily maintain application state while adhering to server-side statelessness and zero affinity (any available server is a good choice).
Application volatile data such as account lists and transactions also benefit from this architecture. Retrieval of account lists requires server resources and data transmission bandwidth / time which will slow a web application if this information must be retrieved each time the user requires that information presented. We have implemented strategies such as lazy loading and staged requests in the past to ensure the user does not wait for data to show up on a page placing the bulk of the data acquisition into a background process. This type of strategy does nothing to reduce server resource / bandwidth load, it only makes the user experience better by reducing perceived latency. With an SPA, it is possible to cache these lists of volatile data and implement a strategy to only request data which has been altered since the last request. This is also known as retrieving cache deltas. By implementing this strategy, the data being presented to the user is current and the load on server resources is greatly reduced. An additional benefit is the data being transferred from the server to the SPA is greatly reduced in size which requires less compute resources in the browser as only the changes need to be merged into already sorted and filtered lists. This boost in response performance continues to enhance the user experience.
Well architected SPA applications are also able to add options for availability. The applications may be served from a fault tolerant source which is not connected to the server-side application. The SPA may be configured with internet address information which will direct the Web API calls to a specific domain or IP address. It may also be configured with multiple domain or IP addresses which may be used if the primary address is under heavy load or unavailable. Given the server-side applications are stateless, the SPA may shift to alternate network addresses seamlessly giving the user a fully contiguous experience. If the SPA has implemented an underlying stateful connection, such as web sockets it will be closed, and the SPA will need to establish a connection to the new server. For more information on fault tolerant web sockets, please see my post on SPA - Fault Isolation and Recovery.
Using execution time binding to CSS and other supporting assets, a single version of the SPA will have the ability to tailor itself to the appearance preferences of the user as in light or dark or favorite color scheme mode. Runtime selection of other assets will allow the SPA to be tailored to a specific tenant or customer if the application is delivered in a multi or all-tenant environment. Generally, most rendered assets in the SPA must be included into the application at the time the application is built. If the assets built in are part of a collection, the application will be able to choose which asset in the collection to use.
As you can see, SPA based web applications are powerful and provide the experience desired by todays users. They have paved the way for many Web API only frameworks such as Microsoft’s .Net Core a popular server-side development framework. SPAs will continue to evolve and bridge the gap between server-side data and the user experience. Any viable modern web application architecture will embrace the SPA and leverage the ability to bring the experience close to the user via the compute resources in the browser.
- On-Demand - available anywhere on any device.
- Current - always the latest version of the application.
- Fast - Small server communication footprint and local compute resources.
- Useful - stateful and posh user experience, no page refreshes.
- Resilient – always finds the “on” server.
- Safe – encrypted web traffic, modern authentication strategies and restricted device access.
- Future – SPA and web frameworks are a major focus of innovation.
For additional information on how to create scalable applications, our posts on horizontal scaling and the use of commodity hardware to control cost at scale are must reads.