Single-page applications are so called because they give users full access to their business applications via a...
Web browser and never require them to load a new page. This results in a faster, more responsive experience for them, and a more efficient use of the underlying infrastructure.
The "secret sauce" is that the page formatting information and application processing logic are downloaded upon the first hit, and the browser runs scripts to perform tasks. Web service calls are made to fetch data or otherwise interact with the back end, but no further data related to the presentation of the page is retrieved. Instead, only the affected page elements are updated, and the overall effect is that of using a "real" desktop client rather than a browser.
Technology benefits accrue because packing the browser with so many "smarts" means the load on the server is reduced, and the traffic on the network is decreased. It also (theoretically) means the application works on any Web-enabled intelligent device, and can be managed or developed accordingly.
Balance work required with expected benefits
Sounds good, you may be thinking. So, what's the catch? Only this: Depending on the application, it can take considerable effort to empower the browser suitably, and a fair amount of time to complete the initial download. A careful balance must be struck between the amount of work required to develop a single-page application and the benefits its use are likely to return -- especially in a complicated scenario like business process management (BPM).
Perhaps the simplest form of a single-page application (SPA) involves websites that appear as one long page and contain links that, when clicked, cause something functionally uncomplicated to happen within the page (e.g., open a contact form), rather than lead you to a new one. Here, the scripts being triggered are relatively straightforward, and the demands being placed on the browser are well within the latter's capabilities.
An application like BPM, on the other hand, is much more complex and requires a lot more horsepower to process the business rules and routing logic that lie at its core. It's fair to wonder, therefore, whether it's worth cramming all the required functionality into the browser.
SPA and BPM? It depends
The answer, as it so often does, boils down to "it depends": on your users' expectations, on your technology infrastructure, on your embedded skill sets, etc. Here are a few factors to consider when weighing the applicability of taking an SPA approach to all or part of your BPM application.
Nature of the use case. SPAs make the most sense when the steps in a process are well defined and closely tied. Case management is a good example of this, because the workflow steps generally are clear-cut and predictable. The "instruction sets" being fed to the browser can be defined readily and handled efficiently without risking an overload that may end up negating some of an SPA's original benefits.
Need for a consistent interface. Especially when people have been using the same basic tool for a very long time, maintaining a familiar look and feel is critical to easing the transition to an upgraded or replacement application. Using an SPA lets you keep the front-end interface largely the same even as you change things on the back end. This is especially important in process-steeped applications where great comfort is derived from "doing things the way I've always done them."
Bandwidth. Not having to load page information continually means less information needs to be moved between server and client, and this, in turn, means that less bandwidth is required to support the application. This may prove to be especially useful in places like power plant construction sites, which nearly always are initially off the grid but have many processes to execute and report upon. On the other hand, there is so much page and logic information to download at the start of a session that loading the SPA may be unacceptably slow in a low or uncertain bandwidth situation.
Need to work offline. Running all the logic on the client means that being disconnected from the server is not a showstopper. If you are supporting users who spend time in, say, airplanes or the wilderness, then an SPA may make sense because local processing can continue even if the connection doesn't. Plus, reminds Laurence Hart, lead analyst at Word of Pie, "you can't always assume the browser will properly exit, and processing in the client mitigates this."
Cloud pricing. If you're using a cloud provider and you are charged by the transaction, then fewer server calls can mean less cost -- particularly in the case of a processing-heavy application like BPM.
Requisite skills. SPA development is steeped in scripting and webpage programming, and often is accomplished using SPA frameworks like Backbone, Angular, Ember and React. Not every organization has staff familiar with these frameworks, so arrangements must be made either to invest in training or bring in people from the outside to do the work.
Single-page application not right in all situations
As you can see, a single-page application can be quite effective as a way to give users a desktop-based experience while using a browser over the Web. At the same time, SPAs can bring certain efficiencies to the back end as well, even if these aren't the SPAs' prime focus.
However, the construction of SPAs means they may not be suitable for all situations, and care must be taken to properly match the work required to the benefits expected -- especially when it comes to BPM, which can reach broadly enough to make a single-page presentation impractical.
About the author:
Steve Weissman has a 20-year track record of innovation and success in information governance and process improvement. Principal consultant at Holly Group, he uses a proven proprietary methodology to optimize clients' approach to basic planning, vendor selection, user adoption and everything in-between, ultimately positioning them to derive Maximum Total Value from their information and their information technology. He can be reached at email@example.com or 617-383-4655.
Mastering SPA development
Learn more about beat performance monitoring hurdles