Front End Architecture
In this post, we discuss the front-end architectural choices made in developing one of our newer products, DDP (Digital Discovery Pro). Along the way we hope to give insight as to why we went the way we did. Before starting, let us mention that in the last few years there has been an explosion of choices of front-end libraries, frameworks, and design patterns for building dynamic web sites. This post covers only the particular set of choices we made. We try to give some justification along the way for these choices, but other combinations are certainly reasonable and may have worked equally well.
This type of system is in contrast to designs where the server is more intimately involved in the construction of the web pages of the product. Popular examples of such systems are MVC frameworks which exist for all of the popular server-side languages. We chose the static webpage / RESTful API pattern  because it gives us a very clean break between client and server. This allows engineers to make independent and rapid progress on both sides of the APIs. In addition, specifically to AWS, the ability to ‘front’ the static website with CloudFront offers many advantages .
Single Page App
Our web application, DDP, is designed as a Single Page Application (SPA) . In a nutshell, the goal of a SPA design is to provide a user experience similar to that of a UI in conventional software. In a SPA, as the user switches from one view to another, the data is called up via HTTP requests and the on-screen view is seamlessly changed. One is not navigating to new web pages.
Front-End Framework — AngularJS
AngularJS provides an important piece of SPA functionality known as routing . This allows us to navigate from ‘screen’ to ‘screen’ without the request-response latency and rendering of reloading the entire page. As mentioned before, this gives the user a seamless, ‘like regular software’ experience.
Constructing and using components is doable in AngularJS. As one moves to Angular 2 , it is strongly encouraged by the framework. We are currently in a good position to upgrade to Angular 2 and have started the process.
In addition to AngularJS, we employ other useful libraries. One of these is jQuery, which provides us with some valuable plugins. If one mixes jQuery with AngularJS in this way, one must be mindful that AngularJS will not know what jQuery is doing. Remember, AngularJS is a framework and as such, it likes to be in control! In some circumstances one may have to use $watch from AngularJS to synchronize the two systems. Overall, it really isn’t good practice to mix the two libraries very much and we do it only in a limited way.
Another benefit of our TypeScript investment is that our ongoing upgrade from AngularJS to Angular 2 has been made much easier. The folks at Google have adopted TypeScript for Angular 2 and so it is a good idea to use it. Unfortunately this has helped lead to resistance in the community against Angular 2.
A final plug for TypeScript is the availability of the typeLITE  tool which allows us to annotate our objects in our API code so that we can establish a rigorous type connection between our back-end object JSON stream and our front-end objects. In our case, the back-end objects are written in C#. One adds annotations to the model C# objects involved in the API, runs the typeLITE tool, and then a TypeScript file is created with type definitions that is included in the front-end code. This helps significantly in keeping the two worlds of front-end and back-end code in sync with one another.
In this post, we hope we have given you a flavor of what we have found important in building a web application with a rich interface and yet at the same time, keeping it correct and rigorous.