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).

Primer

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?

There are a few technologies and strategies which have brought us to this point. Content has been distributed and placed closer to you through Content Delivery Networks (CDN). The format of the data being sent to your browser has been compressed and simplified allowing more data to be sent in less time. The biggest boost has come from the advantages provided by the browser itself. Javascript was created in 2002 and has been the dominant form of programming or code for browsers. Browsers continue to render HTML with very expansive content styling capabilities provided by Cascading Style Sheets (CSS) and HTML version 5 (HTML5). All these technologies have evolved to provide an unbelievably rich experience delivered over many presentation forms from mobile phones to tablets to appliances to computer browsers.

It is the revolution in Javascript which has delivered the biggest bang. Javascript is not a derivative of the Java programming language as the name infers. It is its own scripting language which ultimately fulfilled the promise of Java as a client-side application language. Javascript is interpreted at runtime by the browser allowing the browser to act as a mini operating system of computer that runs the Javascript code and interacts with you though the page in your browser. Thinking back to the past where we installed applications on our computers and connect to remote data sources, we can consider the browser to be that computer where the web site installs an application as the browser page loads. Communication to the web server is primarily only for the data interactions required to support the application running in the browser. This data is now served by Web Application Interfaces (Web APIs) installed on web servers which provide the business logic required to interact with backend files stores and databases. This method of delivering applications to users solves so many problems.

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.

Application Evolution

  • 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.

A simplified example of how a SPA works is when a user browses to a site, that site responding with an application created in a Javascript framework which is then executed in the browser conversationally interacting with data via Web APIs. As selections are made, forms completed, links and buttons selected the browser is no longer required to make a request to the server for the next page or activity. This is not to say the SPA operates disconnected from the server, data exchanges when required will continue to happen. The SPA goal is that the required page or activity is already available within the SPA and is presented to you based on the logic contained in the SPA being executed in the browser. Amazing. Now for the real benefits.

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).

With SPA architectures, application state no longer must be maintained in data passed between the browser and server (cookies). We can maintain data within the Javascript application in variables and data structures. Authentication tokens, user preferences, retrieved server data and activity state can all be locally resident in the browser and used within the SPA logic and algorithms. This allows for the local availability of encrypted authentication tokens which may be used for Web API calls saving the server from additional processing / compute cycles. Locally resident preferences will ensure dates, color schemes, favorites, history, etc. are now available without a server call. As you can see, we no longer have a requirement to request infrequently changing data from the server.

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.

In 1999, AJAX (Asynchronous Javascript and XML) was introduced to asynchronously send messages between web servers and browsers. This provided the ability for the server to notify the user of some server-side event without requiring the browser to send a HTTPS message or the user to refresh the page. From there Web Sockets were introduced as a feature in HTML 5 and implemented in popular web servers around 2012 / 2013. Web Sockets become available once a browser establishes a connection to a web server, a secondary binary connection outside of HTTPS is established allowing for on demand bidirectional communication between the browser and the server. This allows for asynchronous communication and is used in application features such as web chat or update notifications. Web sockets as a technology has become a widely used and secure technology.

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.

SPAs are usually built using modern frameworks which are “transpiled” into minified Javascript. React (2014), Angular 2+ (2016), Ember.js (2011) and Vue.js (2014) are popular frameworks to accomplish this and have extensive support from business and the developer community. Within these development frameworks a popular presentation / HTML framework is chosen based on how the developer wants the application to look and feel. Popular options include Bootstrap (2011) from Twitter, Material Design (2014) from Google and Foundation (2011) from Zurb. Each of these frameworks is based on a columnar layout approach and leverages the HTML 5 feature set. Each support multiple device sizes and presentation formats through responsive designs and components. Google’s Material Design was specifically created to be a mobile first framework and provides a rich user experience in any presentation size.

Historically, Javascript first appeared at the end of 1995 and is the default language of web browsers. Ember.js was released in 2011, followed by React and Vue.js in 2014 and Angular in 2016. Each of these frameworks supports a large library of prebuilt open-source components or packages that provide rich application features which may be used to speed development times. The number of available packages numbers in the thousands. These frameworks have proven themselves to be stable and provide features which obfuscate the underlying Javascript and data to ensure you can safely deploy SPAs.

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.

SPA Difference

  • 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.