Schedules & Architecture

I’ve now spent few weeks on E1’s Foundation Calendar module and Work Schedule resulting in cWorkSchedule and cEmployeeWorkSchedule with the objective of demonstrating how AIS backed web app can fill functionality gaps in E1.

Both projects are published under MIT open source license with the purpose of encourage AIS uptake and exchange of ideas.

Architecture

The development framework is Angular, design by Angular Material and state managed by ngrx. All are open source and supported by large communities.

Angular (Angular 2+) is the successor of AngularJS and developed by Google. With Angular, Google partnered with Microsoft to make Typescript its programming language of choice, which makes it quite a remarkable creation. Not just that two biggest software companies in the world banged their heads together to build a brand-new application framework with new programming language – but they made it open source!

The progression of Angular has been extraordinary with its first release, called Angular 2, in September 2016 after two and a half years of development. Just over a year later it’s now on version 5! But this releases-on-steroids evolution is not unique to Angular but quite common in the JavaScript universe – or the web app universe. It’s a philosophy called release early, release often.

Anyone who’s been in the trenches of software development knows the horrors that a new software release can bring and might find the release early, release often philosophy suicidal – myself included until 6 months ago or so.

The evolution in software development over the past few years is nothing short of a revolution. The explosion of smartphones and tablets along with the ongoing march of memory, cpu and internet performance has made the browser the run-time system of choice. An ironic side effect of this revolution is that JavaScript, the programming language created in 10 days back in 1995 is now the world’s most popular.

JavaScript, as the name indicates, is a scripting language which means that the run-time takes the code as-is for execution. No compilation into binary objects and library-linking into executable. The flexibility of a scripting language is enormous with almost no limits on code plug-ins or modules. Code changes like bug-fixes can be as simple as change < to > and off you go. This flexibility makes JavaScript ideal for release early, release often philosophy with the benefits of gradual improvements of the software. The downside of a scripting language is performance hit by the translator (largely irrelevant on modern devices), lack of implied program structure and risk of hacking. A well designed framework like Angular tackles both the program structure and security risk.

ngrx

The biggest development challenge of a REST application like AIS web app is its asynchronous nature. In traditional programming you write a sequence of statements with the knowledge that they will not only execute sequentially but each statement returns when completed – it’s synchronised. A REST execution however returns as soon as its http request is made regardless of the response – it’s asynchronous. For example in a sequence where the first statement requests a customer’s details and the second processes those details, there is no guarantee that the details are available when the second statement executes – and most likely they aren’t.

The asynchronous challenge is not new but a rather different way of handling client-server tasks where the client has to wait for the server to respond. Traditionally these were executed in parallel with the user interface by multi-threaded run-times. However the browser’s run-time is single-threaded so instead we enter the world of an Observable.

Getting your head around the concept of an Observable is quite a challenge. It brought me back to the transition from procedural/console- to event driven run-times, but that was a quarter of a century ago so it’s probably time to move on! An Observable is analogous to a run-time event in the sense that it triggers execution of a predefined code upon some condition being met, the difference being that events originate from the run-time while an Observable is a special type of variable or object. Programming with Observable like objects has its own paradigm called reactive programming.

The AIS interface is what’s called REST interface, or Representational State Transfer interface. What that means in a form request for example, is that after AIS has executed the form on the HTML server it responds with a snapshot of its data – or state. Upon receiving the state, ngrx then subsequently replicates it in the client’s ngrx/store as an Observable .

Replicating the AIS state in client’s ngrx/store achieves two design objectives:

• Encapsulate logic that’s driven by REST’s response into ngrx/effects service. For example logic to execute after authentication or transformation of data returned by a form request.
• Angular components can subscribe to data they need from the ngrx/store.

Two very important design principles are abstraction and encapsulation. Abstraction of AIS state in ngrx/store and encapsulation of REST response logic by ngrx/effects service. This design provides a general guide for programmers on where particular logic should reside, data transformation logic should be in the ngrx/effects service and data availability is provided by the ngrx/store.