Why Single-page Applications + REST are better than Dynamic web pages

Among the many technology stacks available for making web applications today, two major groups may be distinguished based on client architecture.

1. Stacks based on Dynamic web pages. In this approach, the system client (i.e. the web page that we view and interact with via the web browser) consists of HTML, Javascript and CSS files that are partially or entirely rendered by the server, and sent to the web browser in real-time. Noble examples of this approach include:

• ASP.Net,
• ASP.Net MVC,
• Java server pages,
• Django.

2. Stacks based on Single-page applications (or SPA in short) and a REST API. Here the client consists of a set of static HTML + CSS + Javascript files (with one “master” HTML file), that communicates with a web server using the REST architecture (usually over the HTTP protocol). While a web server may be implemented in almost any programming language out there, developers usually use special frameworks to implement the SPA on the client-side, and a REST API on the server-side. Examples include:

• REST API frameworks:
  • Express Js
  • ASP.Net Web API
  • Nancy Fx
  • Jersey
• Single-page applications frameworks
  • Angular JS
  • Ember JS
  • Ext JS

In this article, I will try to point out the advantages of the latter approach over the former one.

Case Study

The SPA + REST technology stack, while requiring more work at first, presents dramatic advantages in the long run. These include:

A free REST API

Face it, if your application succeeds in today’s world, it won’t be just humans interacting with it. A REST API presents a uniform, flexible, secure (over HTTPS) and widely recognized interface for third party systems, or your other clients (like an embedded mobile app), that wish to interact with your app. You’ll probably want it. With Dynamic web pages, you will have to implement them side by side with the system client. With SPA + REST and some smart designing, you get it out of the box.

Easier design

With the REST API being the crucial point in your system, and at the same time a language fairly easy to understand, you may want to centre your initial design around it. Identify your REST resources and the verbs you want to use on them (GET, PUT, DELETE – sounds familiar?) and put it all together into a REST API documentation. Have your developers verify and polish the design. They will usually do mockups of the API, and be able to implement the server, client and automatic tests simultaneously. As long as they conform to the documentation, everything will work like a charm!

Easier testing & continuous integration

My personal approach to testing is this:

• Things that interact with machines (i.e. the server) should be tested automatically.
• Things that interact with humans (i.e. the client) should be tested manually.

This being said, it must also be noted that cleverly designed automatic tests are way cheaper in terms of man-hours than manual ones. With SPA + REST you may build and run your entire server solution, and (by calling the REST API) develop automatic tests of all of the layers working together, just like they do in production (a process generally referred to as integration testing). Do it automatically with every push to the code repository to enjoy continuous integration. Now all that is left is to have your testers work the kinks out of the client. With dynamic web pages, on the other hand, automatic testing usually becomes a nightmare as developers strive to find a consistent form of communication with the various system components. The result is extra costs in developer and tester man-hours and mental wellness.

Better performance

With dynamic web pages, the web browser is forced to load an entirely new HTML document (that was generated by the server in real-time) every time the user navigates to a new view. Single-page applications (as the name implies) reside in only one static, initially loaded HTML document, and display all of its content by changing that document in real-time. This results in a much smoother, more responsive, embedded-app-like user experience, and also boosts performance, as there are fewer files for the browser to download and no overhead related to generating them in the first place. Also note that having your client in the form of static, ordinary HTML+CSS+Js files makes deployment super easy.

Better scaling

Since a REST API is stateless, there is no difference whether the client is talking to just one or many web servers with each request. This allows you to scale your app quickly and easily, by deploying multiple instances of the server solution side by side behind one common gateway. Fun fact: this is actually the way that most cloud hosting providers (like Microsoft Azure) scale your web applications, so no special handling will be required as you scale up your service. And, since the client is independent, you may also deploy multiple client instances that talk to that one gateway in case your static file servers start to choke.

Client – server loose coupling

With a SPA + REST technology stack, your client and server are separate entities, bound with nothing except the REST API documentation. This allows you to develop, test and deploy them independently, an advantage that users of a dynamic web pages technology stack do not enjoy. For example, an old client with an outdated design or bad UX can be replaced by a shiny new one without even touching the server code. On the other hand, new REST API endpoints related to i.e. third party system communication may be implemented on the server-side without having to test the client all over again.

Better code quality

Having the server and client tightly coupled (as with dynamic web pages) means more code in one place. And more code always means more clutter, and a higher risk of spaghetti code happening. Apart from that, since programming the server and client requires an entirely different approach, you may end up with several developers (or even teams), with several different technology backgrounds and programming styles all working on one codebase. Obviously, that spells trouble. SPA + REST draw a clear division between the worlds of the server (i.e. transactions, entities, business domains, background tasks, consistency) and the client (i.e. forms, charts, styles, UX, responsiveness, clarity). This, in turn, makes your solution clean. Developers love clean 🙂

Conclusions

While choosing a SPA + REST technology stack over one based on Dynamic web pages is not a magical solution that will make all of your problems go away, it will save a substantial amount of time and money in the long run. It will also keep Developer morale up, by producing a more elegant, less coupled solution.

Check our web application development services to get more insights into what we offer.