Two apps and a shack
How we’ve been using micro-frontend architecture to refactor and strengthen our application’s backbone
Being relatively too young to have experienced that era when a classical application was build up entirely by the help of a handful of workaholic developers, that used to touch every aspect of the application, I’ve got to know enough software engineers who pictured that age as the Middle Age. Quite frankly, I imagine dark corridors and dull white walls in software companies buildings. As ludicrous as it may sound, editing even a quote in the application code was a very critical operation which could have almost caused a butterfly effect.
Over time things have changed. Teams ended being split up and the concepts of frontend/backend development emerged: people were separated into those interested in how to talk with the browser and charmed by a good UI implementation, and those interested in talking with DBs and in making their hands dirty in the mud.
When these new teams got bigger and bigger, backenders (and PMs) were the first facing the “scaling-up” drama.
Adding new people to the team, working together on the same backend-monolith, wouldn’t have increased speed whatsoever. Things, therefore, got frustrating and hard to maintain.
The popular solution was to create microservices by cutting out from the backend small pieces that could have been developed independently.
At the end of the day, engineers ended up with a solution for the backend growth but the frontend still lacked a similar intellectual resource.
Despite the introduction of API gateways, which hid the ecosystem of microservices beneath the front surface, there was still a big thing to sort out: the frontend-monolith.
On top of that, we should take into account the following issue: let’s assume we wanted to add a new feature. The Product Owner one day comes up with a new brilliant idea (whatever…). In a typical situation, they have to talk with all the different teams involved. Getting the teams all on the same page might rise up communication problems that produce an infinite number of frustrating meetings, yawns and tears.
Gustaf Nilsson Kotte, in an extensive article, introduced the concept of micro-frontend. This micro-frontend architecture promotes the organisation in Technical Teams made up of engineers focused on one specific technology (we’ll keep having that BE/FE separation, though).
It may sound like the ultimate solution, but even though it’s good for technicians who want to specialise in one technology it is not good for clients.
Therefore the idea is to group people by not using technical criteria, but by use cases — so by bearing in mind customers needs: the Use Case Teams; cross-functional teams made up of players with different know-how: FE/BE engineers, designers, business people, …
In that way project managers, especially, are going to get a model where apart from a kind of symmetric micro-fragmentation structure in both back and front, even teams get micro.
As our application at Signaturit grows the needs of adding quickly new features get essential every day more.
Even though our backend part is all but completely separated in microservices we’ve been still facing the harder integration of new features in the frontend, when it comes to code new ideas.
We had to sort this out. So we recently decided to do some researches on how to move towards that direction breaking our frontend code up as well.
Our original platform was written in AngularJS — by the way, we already have a version of the new signature app made in Angular 7 — and although it’s an LTS, we wanted to migrate to the most recent version of Angular in somehow (that’s even because we do love TypeScript).
Getting down to the nitty-gritty: we first off came up with a proof-of-concept by building up a web server in Express.js which served static assets. That allowed us to insert into the HTML pages the test apps’ entry points (plus JS and CSS bundles) we wanted to see rendered, and…boom!…eventually we managed to get different frameworks living in harmony and peace on the same page. Hooray!
Caching and performances. Over-optimising does not take to good results: enough is as good as a feast. That’s the truth. Well, for our POC the browser strategy implemented by default seemed working pretty fine already. Of course, we will review this afterwards.
On top of that don’t forget the advantages of using HTTP2 which nurtures multiple simultaneous requests; with (not) that big surprise, everything was executed quite good actually.
That led us going after the actual monolith. Micro-frontend suggests an approach very similar to the proof made. We wanted to make a further experiment modifying a bit the paradigm for a softer migration: having the AngularJS application rendering inside its templates an Angular 7 app.
The technique behind the model is based for the most on: Web Components through the use of Custom Elements API, Server Side Includes, Top shared routing.
Here Angular doesn’t let us down. In fact, under the hood, it uses the Custom Elements API itself.
Regarding the Server Side Includes: since we’ve been writing in a Twig template, preprocessed by the server and then parsed by AngularJS, for now, we got things working without the need of an explicit SSI.
The weak point is about the routing. Angular 7 takes advantage of zone.js to handle asynchronous tasks, like routing indeed. The library is quite aggressive in terms of global namespace pollution and we ended up with too many console errors when we tried to have AngularJS and Angular 7 routers coexisting.
Literatures states that we should benefit from a shared top-level router. I can state that we have yet not gathered enough information to implement this. The workaround was breaking the “inner” app to the bare minimum so by getting rid of the Angular 7 router (please, feel free to comment down if you have any suggestion. They’re more than welcome)
In conclusion, looking into what we got right now looks definitely that we’re already on the good path for this software evolution. Yeah, for sure we’re still dealing with some issue and fiddling with different solutions but in a nutshell, as noticed by an older workmate who might have professionally lived that dark age, we’re about to the see the light.
NOTES
- https://micro-frontends.org/
- https://www.youtube.com/watch?v=o1Sr39DVdOQ
- https://www.youtube.com/watch?v=ZkHp_qbaCok
- https://medium.com/@tomsoderlund/micro-frontends-a-microservice-approach-to-front-end-web-development-f325ebdadc16
- https://www.mosaic9.org/
- https://medium.com/@benjamin.d.johnson/exploring-micro-frontends-87a120b3f71
About Signaturit
Signaturit is a trust service provider that offers innovative solutions in the field of electronic signatures (eSignatures), certified registered delivery (eDelivery) and electronic identification (EID).
Open Positions
We are always looking for talented people who share our vision and want to join our international team in sunny Barcelona :) Be a SignaBuddy > jobs
