ROCA vs. SPA

Comparing two architectural styles with a concrete example

Lucas Dohmen, Marc Jansing

Currently, a lot of companies are migrating from Desktop applications (mostly written in Java) to Web applications for their products as well as for their internal tooling. When they start with this process they often ask themselves: Which technologies should we use to build our Web application? Should we use Angular.js or React? Or should we go with recommendations like ROCA instead of a Single Page Application?

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?

Thumb smaller

I’m a senior consultant at innoQ, programming in Ruby and JavaScript (and a lot of other languages in my free time ;)) and helping with technology decisions about different NoSQL solutions (and their adoption if we see a fit for them). Outside of work I’m doing a lot of open source and community work (the hacker and nerd calendar hacken.in, organising and teaching at our local CoderDojo and helped to organise the eurucamp conference) and record the podcast Nerdkunde (which is in German).

More content

Thumb dsc01911

Marc Jansing arbeitet als Senior Consultant bei innoQ und entwickelt seit mehreren Jahren Webanwendungen mit leichtgewichtigen Frameworks. Sein Schwerpunkt liegt in der Implementierung von ergonomischen Anwendungen auf REST-Basis und verteilten Systemen.

More content

Comments

Please accept our cookie agreement to see full comments functionality. Read more