Single Page Application, popularly called as
Characteristics of SPA
- Gives an impression of single page in the browser. Pages never gets re-drawn on interactions. Clicking on a link in the page changes the state of the app and shows the different content.
- Url structure containing hash location (often – Google’s hash-bang model) that drives the state of the applications.
- Single fully compliant HTML page which is the initial page (often called as layout template) that gets loaded. Rest of them are HTML fragments or just JSON.
- HTML/JS – Either all of the required artefacts get loaded on initial load or obtained from server on demand.
SPA – Architecture
Usually a thin server serving static resources (HTML, CSS, JS, Images, etc.) and providing data APIs. If cloud infrastructures are leveraged, it could even be a serverless architecture where static FE resources are hosted in object bins and data APIs (RESTful) are modelled as cloud functions (remember function as a service – FAAS. Example, AWS lambda or Google functions).
Client is thicker than usual backed by JS frameworks such as Angular(JS), React, Vue, Ember, CycleJs, Aurelia or Backbone. Client architecture is mostly dictated by the framework used. These frameworks are often opinionated. Across the spectrum – there would be views which are often modelled as template with data bound to models (one way or two way binding). These framework and their allies usually provide the necessary mechanisms to deal with variety of requirements such as managing application state, routing, watching, connecting to REST APIs, etc.
SPA – Good side
- Single tab browsing provides native application experience and hence persumably enhanced usability.
- Performance – Since most of the FE artefacts required are loaded on initial load, subsequent interactions are faster. The on-demand load of data or HTML fragments are lighter in terms of network footprint.
- Allows code re-use. With cross platform enabling technology such as Apache cardova, ionic framework, the code can be reused to build hybrid or cross-platform mobile applications.
SPA – Dark side
- Increased initial load time – FE resources with JS code need to be loaded and executed on first hit which increases the DOM ready time. Often lazy load (client side) and caching at CDN (server side) strategies employed to reduce it.
- Dealing with back and forward buttons in browser. As browsers are traditionally not built for SPAs, dealing with such browser behaviours are often a challenge. Dealing with scroll position is another challenge in this line.
- Performance – Due to heavy JS, chances of JS issues, browser memory leaks esp. on mobile devices are high.
- Analytics – Traditional analytics metrics gets measured on page load. SPAs need alternate strategy for analytics.
- Security – Certain security credentials (example, for integrations) and presentation logic have to be made available in browser for JS execution. This has be carefully crafted to avoid security vulnerabilities.