The LVM insurance company wanted an answer for this last question. They decided to let two consulting companies (thinktecture and innoQ) build a prototype for a part of the functionality of their existing Java Desktop application:
- thinktecture was asked to build it using a SPA approach.
- innoQ was asked to build it following ROCA guidelines.
One requirement was to show how the application could be built in separate teams that should be able to work independently of one another. Those teams should also use different versions of frameworks and libraries or even various frameworks. thinktecture solved this by building an application consisting of parts written in Angular 1, Angular 2 and React. We decided to build four self-contained systems.
The entire code written for this contest was released as open source. You are invited to check out the two applications as well as the source code and provide your feedback. Which approach do you prefer? What would you have done differently? You can find an explanation of the requirements as well as links to all the source code here.
Our approach
We wrote four applications. Each of these applications can be used, developed and deployed independently. To show that they are also independent from a technology perspective, we implemented three of them using Node.js and Express for the backend and one of them using Java and Spring Boot. Each of them runs in a separate virtual machine using Vagrant in development (in production they are running on separate machines). Each of them delivers its own frontend including CSS and JavaScript.
The four applications are not integrated with one another via a database, message queue or an API. They are solely integrated via their frontends. The main technique here is simply a link. When you click on a link, you may be in a different system without really noticing it. This is partially progressively enhanced with JavaScript for functionalities like showing the number of items in your inbox or previewing all contracts. We refer to this technique as transclusion.
The user should not see that they are switching between different systems. It is thus important that the systems share the same look and feel. We decided to share parts of the CSS and JavaScript as well as some images between the applications via an NPM package (both for the Node applications as well as the Spring Boot application). This NPM package also contains the tools to build the JavaScript and CSS (a so-called “asset pipeline“ that mainly uses Webpack, Babel and a CSS preprocessor). The applications depend on this package and can add their individual CSS and JS as well as determine were the compiled files should be put (as the expected place is different between different frameworks). One of the reasons why sharing is done via an NPM package is that the different applications can run on different versions of the shared assets. This is important to let the teams work and deploy independently.
The entire website is usable without JavaScript, and the JavaScript functionality is only an enhancement of the functionality without any business logic. Arguments to the enhancements are provided via attributes of the DOM elements. That means we can write tests for each application’s features without needing to execute JavaScript.
A consequence of the combination of the shared assets and the usage of progressive enhancement is that the developers of the systems do not need to learn CSS and JS in depth. The documentation of the shared assets package acts as a living style guide, which can be used as a kind of catalog: Pick the element you need and add the appropriate HTML to your application. Done.
Due to the small assets and very few HTTP requests per page, the applications are fast and responsive. This is also true for slow Internet connections. Due to the usage of PJAX, the transition between pages is almost instantaneous.
In conclusion, we think that this solution has many advantages over the other presented solution:
- Independent development and deployment of the systems.
- A fast and responsive application without any loading animations, even for slow connections.
- An established and well designed architecture that combines the best practices of ROCA and SCS.
That being said, you can check out the two solutions yourself and form your own opinion. You can also just try out our solution here. What would you have done, given the same requirements? How does it apply to the requirements you are addressing in your project?