One of the topics I plan to blog about is SPAs. SPA stands for Single Page Application and is when a web app is built from a single page served from the web server. A SPA doesn’t mean there is only a single screen within the app but it does mean we don’t get lots of fully rendered screens from the server.

How it works

The diagram below shows example steps in a SPA pipeline - all SPAs don’t follow these steps but this is a good example. As you can see, there is a lot of work going off in the browser in comparison with a traditional server driven web app.

Login

In this example, the login page is a traditional server driven page. I have found it easier to secure the app in ASP.NET by using a server page because you can use the inbuilt authentication and authorisation in ASP.NET.

Initialisation

Once the user has correctly logged in, the single server page in the app will be downloaded. In some SPAs all the resources for the app will be downloaded at this point, such as all the HTML/CSS views along with all the JavaScript. However, for large apps I prefer to get stuff on demand, so that the time to the first screen in the app isn’t too slow. In the example above, we are downloading the HTML/CSS for the app shell and home view which will be in the mark up for the single page. We are also downloading the core JavaScript for things like view rendering, navigation and data access.

Navigation

This is where we start to see the differences between the traditional server driven approach. All the screen navigation is done in the browser. In the app start up process, the user may have requested a particular screen within the app (rather than the home screen) through the URL. If this is the case, the app initialisation process will hand over to the navigation process to route to the appropriate screen. In this process we may get a HTML template from the server for the screen if it hasn’t been downloaded in the initialisation process.

View Rendering

The view is rendered in the app shell from the HTML template. The template will likely include data binding expressions which will trigger the data access service to kick in and retrieve data from the web server.

UI Behaviour

This is things like showing a section of the screen when a user selects a value from a drop down input or disabling a section of the screen when a user selects a radio button. It will also cover client side validation. All this logic is executed in the browser, making the app nice and responsive.

Data Writing

If the view was a data entry screen, the data access service will push the data to the web server to save that data in the database.

Examples

The obvious examples are Google apps such as Gmail and Docs. Another really nice example is the azure portal.