Among the many technology stacks available for making web applications today, two major groups may be distinguished based on client architecture.
- ASP.Net MVC,
- Java server pages,
- REST API frameworks:
- Express Js
- ASP.Net Web API
- Nancy Fx
- 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.
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 it side by side with the system client. With SPA + REST and some smart designing, you get it out of the box.
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 center 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 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.
With dynamic web pages the web browser is forced to load an entire 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 is less 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.
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 sphagetti 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 code base. Obviously, that spells trouble. SPA + REST draws 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 🙂
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.