Web application development evolved significantly during the last decade. From the introduction of AJAX and the transition to Web 2.0 to progressive apps, we’ve seen hundreds of promising strategies, approaches and technologies arising in the world of distributed application development. In the era of IoT and hyperconnection I'm drawing a personal high level architectural approach to multi device development of rich internet applications.
IoT and the digital transformation: in progress revolutions
For the few who have not realised it yet, there’s a revolution ongoing, named IoT. In very simple terms any electronic device can be connected to the internet to collect, exchange and produce data, interacting with the everyday use applications of our lives. Together with another very inspiring phenomenon named API economy, IoT is massively contributing to one of the most exciting evolutions of our economy that has ever lived, the digital transformation.
The ongoing scenario sees a galaxy of devices able to operate mutual collaborative interoperable software in globally-connected environments. Washing machines, home alarms or even toasters could be interested in receiving and sending data into the application virtual domain, exchanging information with other devices or applications, consuming and obviously contributing to the variety of always more proactive and detailed services available.
A practical example could be a smart home hub; it can connect to an agenda and define startup and shutdown heating according to the owner's daily commitments. What about a washing machine? Wouldn't it be great if it retrieved tariff information from the energy provider and could start washing clothes when it’s cheaper to operate?
How does the IoT revolution reflect on the web-based applications we everyday architect? The design of a distributed web application has been device-centric for years. Having a browser as the only or primary beneficiary of the application’s data processing, obviously influenced its design. The system architecture was implicitly tailored to the very limited set of consumers it should have run for, then eventually derived or extended to adapt to specific and atypical appliances.
IoT transforms the set of devices we are used to developing for, making it liquid and out of control, under an everlasting and ongoing evolution made of frequent changes hardly controllable and predictable at architecture time. The need to serve many heterogeneous consumers with deep OS differences, processing capabilities, user interfaces, breaks the traditional web-based paradigm.
Design and architecture phases must aim at conceiving a structure able to easily provide data and services to a multitude of unrelated devices. Third generation consumers, like wearable devices, personal and support equipment, sensors and actuators, and more in general any electrical appliance, should be easily pluggable and require the lowest integration and maintenance efforts, without any structural integration.
The consequence is simple: we cannot architect our applications as they were isolated islands, self-contained and device/platform dependent. We must provide easy access to the information processed by our software, easing the fruition from devices potentially unknown.
Architecture in practice
From a merely architectural POV, it is once again very easy to take inspiration from milestone design principles like SoC (Dijkstra 1974) or SOLID (Robert C. Martin 2000), actualising them to a higher abstraction level. We should decouple elements and components, especially when they do not share functional goals and, in particular with reference to our present scenario, when their life-cycles do not overlap.
A separation between presentation and content must be the reference idiom when designing any multi-device distributed architecture: elements of business domain, should be self-contained and completely decoupled from those belonging to the presentation and visualisation domains which are, by their nature, strictly dependant on the features of the device they run on.
Business elements, belonging more in general to the set of the intelligence data processing assets, must be commonly shared and cross-device in order to allow reuse, evolution and at the same time protection for their precious core business value. They will undergo a slow and stabilization-oriented evolution, aimed at consolidation and optimisation.
Presentation assets will be designed and implemented (or made available to third parties for it) with a tailored-approach mode, ad hoc, to meet perfectly the physical visualisation characteristics of the executors. Their evolution will be massive, driven by constant frequent device hardware and software innovations.
Fig. 1 – Architecture overview
At a high level, we can imagine the architecture being composed by two macro components. A set of presentation logic elements interoperates through HTTP based protocols with remote service-oriented business layers, encapsulated in a single/multi-level set of APIs.
This layer can rely on a monolithic or, more ideally, on a micro-service based architecture. To ease redundancy, continuity, scalability of resources involved, services and applications should be necessarily conceived with a cloud oriented approach, taking advantages offered by PaaS, containers and other abstraction and decoupling technologies.
The presentation asset owns a shared base of visualisation logic which defines functional behaviour of interfaces and components. It can be implemented following a pure native approach with the creation of many independent platform driven projects, each with its own customised logic. A more hybrid approach on the other hand, takes advantage of tools and cross-device frameworks like ionic, Phonegap, Intel XDK or general purpose technologies like HTML5, Angular, React to drastically reduce the efforts of an ad-hoc UI development.
Fig. 2 – API driven architecture and stack
- Front end web technologies (HTML5, Angular, React, VanillaJS, Bootstrap) are de-facto standard and. They run on Desktop or Notebook computers and through the usage of layered ghost browsers (XWalk) even on smartphones, tablets and wearable devices. A shared frontEnd codebase can be easily written to run in a cross device scenario, reaching code reuse rates rateable up to 85%.
- Native development technologies (Android Studio, Apple Xcode) allow development of native applications over devices belonging to the same family. Cross-platform technologies (IntelXDK, Apache Cordova, Ionic) can reduce the effort of multidevice development allowing high productivity multiplatform development, in particular when an application should run over completely unrelated devices.
- Entertainment frameworks can be used to develop for infotainment consumers, sharing codebase with other projects connected (Android, Apple TV, Sony)
- Visual Studio. With the recent acquisition of Xamarin by Microsoft, one of the most widespread platforms for application development, .NET, becomes a platform ready to cover various multidevice development tasks. The advantage of using a stable and largely distributed technology like C#, able in particular to integrate with lower level languages like C++, can offer an interesting approach to application development in particular when the set of consumers should include sensors, actuators and embedded devices.
- Ad hoc native development can be considered as an alternative for devices which, for their nature, do not easily integrate with technologies like the ones mentioned above.
API driven architecture and its consequences
In conclusion, the setup of an API base with a hybrid front-end approach offers an easy access to any device equipped with a network and an HTTP protocol. Cross device technologies, together with the adoption of de-facto standard languages, usually offer long term support outlooks thus reducing negative factors connected with extreme vertical team specialisation, like for instance know how fragmentation and technical debt.
The illustrated process of ‘appification’ grants a complete support to current business assets, and at the same time introduces at the design phase the lowest level of limitations; in particular when in need to serve new users from different channels, different devices, or even join new business models like the ones offered by the API economy.