There's no shortage of software initiatives that aim to revolutionize Web application design, and one with a lot of credibility is that of the single-page application (SPA). Such applications promise more modular development, easier adapting of applications to multiple devices, better application lifecycle management -- nearly everything a software architect could want.
The problem is that there are competing visions of what drives SPA development. Is it a vision of a new architecture or is it the needs of specific applications? Architects can harmonize the diverse issues by:
- Taking a circular view of Web application development
- Framing a consistent SPA graphical user interface (GUI) and model
- Taking SPA principles back into the server
- Focusing early SPA development on the right applications
Single-page applications have emerged from the Web 2.0 revolution of more dynamic page content. The old hyperlink model of page navigation produces a jarring experience for the user, and Web 2.0 principles allow for data-driven events to be created within a page and for page content to be updated as needed. This means an application appears to run smoother, to the point where it can emulate a desktop interface to local resources.
Architectural model perspective on single-page applications
Arguably the difference in perspective between the architecture view of SPA evolution and the application view emerges from the fact that some companies have seen the SPA model as a means of improving application stability and development practices, while others have focused on the experience itself. Because there should never be a technology evolution driven by factors with inconsistent goals, it's critical to start an SPA consideration by circling between the two visions of SPA at a high level.
Single-page applications are about scripting or webpage programming, not about back-end applications.
There are many discussions about the architectural framework behind the SPA initiative. In brief, they propose a Web application structure that harmonizes an object model representing the user's view of the application with one representing the relationship between that view and the underlying application resources.
The coupling of these models is sometimes represented as a functional element -- a controller -- and sometimes as the product of state- or event-based interactions between the user of the SPA (via Web 2.0-type events) and the application, stored in another model or data structure. It's this process of model-coupling that lets a single page be treated as a single application.
The architecture model of SPA focuses on insuring that pages can be treated as components in the traditional software sense. It's a key requirement that all of the code used (scripts, in particular) are local and don't generate or contribute to global namespaces that have to be resolved every time two pages are combined to create an application GUI. So-called componentization, then, is the driver of the architectural vision of SPAs, just as it drives software architecture in general. Componentization can be a technical value apart from any gains in user experience, of course.
Application model view of a single-page application
The application model of SPA focuses on creating a better user experience through a reduction in page-shifts during application execution. Traditional Web 2.0 applications could often still use multiple pages, and a single page could still map to a number of application components. Most businesses report their interest in SPAs evolved from a desire to support more browser-based, multidevice GUIs.
The starting point in SPA harmonization is to recognize that SPAs are about scripting or webpage programming, not about back-end applications. The primary goal of an SPA is to restructure Web applications around Web 2.0 page-event-interactive principles so the experience can be translated easily to multiple devices and is productive for users. That means designing the user interaction first, with the goal of supporting one logical activity with a single page and a single set of scripts, loaded at one time and run until the activity completes. Remember that optimum use of SPAs may mean structuring the high-level application dialog in a different way to maximize value by minimizing the number of SPAs needed.
When the user interaction has been designed, the next step is to frame a local state or event model that will describe the page processing interactions with the user and any back-end application interactions. While it is not impossible, it is more difficult to build an SPA that interacts with multiple components of server-side functions.
More on Web applications
3 Lessons from Web application testing
Intro to Web application threat modeling
How to avoid Web application vulnerabilities
This will generate an incentive to restructure application servers to support SPAs on a 1:1 basis. To the greatest extent possible, this model should keep its own variables and namespace local, and interact with other SPAs through the server side of the application. This is to reduce the need to preserve state across multiple SPAs using a local SPA controller or model.
This set of recommendations will, if applied fully, result in a high-level user-to-application interaction that consists of a small number of SPAs supporting highly page-interactive processes. The number of SPAs and the nature of the SPA-to-server interaction will then determine how back-end processes should be optimized to support the new structure.
The final point in SPA harmonization between architecture and application issues is targeting the right applications. Some applications are inherently multi-step, where each step represents a full page of information and supports a single current back-end transaction.
Application steps that seem logically separate don't gain anything from being combined, using SPAs or any other technique. It's also not likely this kind of application will benefit from having its pages composed in various ways. The steps are the only logical way to approach the application. Remember that being able to compose apps and turn them into components should be supported at the technical level only if the apps are valuable at the business level.
Single-page applications are already being misused. Many present too complex a set of script interactions to be properly handled and maintained as a single page, and componentization benefits are diluted if the SPAs are too large. Balancing the application and business side with the technology drivers is the best way to come up with the optimum SPA model for a business.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
This was first published in January 2014