Playing Lego with our front-end

Modularisation is a confusing word. It’s used in lots of different industries, like automotive, construction and manufacturing. But what does modularisation mean in software development? I lead the front-end development team at MillTechFX, so I’m particularly interested in what modularisation means for front-end applications, like our customer portal.

Well, it’s just like Lego. I love Lego, it’s simple and fun, the possibilities of what you can do are endless, and for me personally, it’s a little bit of nostalgia as well. But what I really like about Lego is that you can create an infinite number of toys. You can also build things, that later become a piece of something much bigger. It's modular and reusable.

Why modularise our customer portal?

Well, consider this: you are playing with a friend, and you want to build something out of Lego. You have a great idea of something you want to change to make it better. But each time you try to make a change to this awesome Lego build, your friend must check each block to make sure everything still works and looks the same. Let’s just say that this will be a very dull game.

The dull game

To make this a more enjoyable and pleasant game, we could group the Lego blocks by colour. This way we save some time because our friend doesn’t have to check all the blocks again and again, they only need to check the colour group where I made the change.

The not-so-dull game

So, in this case, if I change something in the red block group and everything else stays the same, if we check only the red group, it should be fine. Also, while our friend checks the red group I could make some changes to the green block group, and this way none of us is bored, we use the time efficiently. And when we both are happy, we could just put the blocks together.

A front-end application works the same way. We build our application block by block, component by component. We create a component like a button and reuse it, everywhere we need a button.

As our front-end application grew it started to behave like the Lego game I described earlier. If we wanted to make a change to a page, the whole application had to be rebuilt, and therefore the whole application needed to be re-tested. This was a lot of effort from our QA friends, a dull game to play, and ultimately slowed us down delivering new functionality to our clients.

Our plan was to break our front-end application into separate modules for each page of the application. By doing this we hoped to:

  1. Help QAs visualise what modules were affected by code changes so they can regression test only the affected modules

  2. Remove unnecessary builds for unaffected modules – there is no point rebuilding a page if it had no changes

  3. Make the codebase cleaner, easier to work with and scalable

How did we modularise our customer portal?

Before the refactor, we had the whole application as a single module. The diagram below gives a rough idea of the application architecture. Changing one line of code in a component, for example, forced us to rebuild the whole application.

One application as a module

What we aimed for instead, was a structure organised into three stages, App, Modules and Shared modules. The most important are the last two because the app is just the entry point of the application. Each module is a page of the app, and every single one of these pages has its own types, helpers, components, styles, etc. These are being used only by that module/page.

Application is broken into modules and shared modules - each module is a page

The rule we followed was simple. From the moment a helper, component, type, style etc, is used in more than one page/module, it should go in a shared module. This shared module is then used by more than one page, and it becomes a dependency of those pages. If something is used in both applications it goes into our libraries (which is also a module), and that library will be a dependency of the application as well. After creating all these new modules, and reorganising everything with the team, we ended up with 52 modules in our repository.

The tool we used is called NX, a build system for mono repositories. If you are already using Lerna, NX is simple to add on top and they work very well together. One of the most important reasons for choosing NX is because they do build caching. Meaning that each module is built separately and cached. If the content of that module changes, it will be rebuilt again. But only the modules where we made code changes will be rebuilt, everything else will be reused from the cache. This helped us a lot, and NXs affected command **helpfully highlight what are the affected/changed modules.

The affected command shows us the modules affected by the change

Doing this means that if I make a change to a helper, for example, I will see that the helper's shared module changed. It’s like in our Lego game, we don’t want our friend to check everything, again and again, to make sure it looks and works correctly, it’s enough to check only the changed/affected modules.

What we found

By the end of the refactoring we had 52 modules.

Our 1st goal was to help QAs visualise what modules were affected by code changes so they can regression test only the affected modules. This we achieved.

Our 2nd goal was to reduce the build time by building only the affected modules. If we calculate how much time a developer spends on average building the apps before and after the modularisation.

(Nr. local builds + nr. CI builds) * min/build

Before: (5 + 2) * 8 = 56 min per developer per day

After: (0 + 2) * 4 = 8 min per developer per day

48 mins per developer per day is a big productivity gain for the team 👏

Our 3rd goal was to have a clean, easy-to-work-with codebase that is scalable. Whilst too early to say conclusively, I have a good feeling about this too. One additional bonus is the work here sets us up well to explore a micro front-end approach in the future. The team put in a big effort, and we are already seeing the benefits.