Interview: Micro Frontends and Module Federation at Cube Bikes
Cube Bikes reduced build times to 1/4 by switching to Micro Frontends and Module Federation.
In this interview, I talked with Helmut Jost from Cube Bikes about their introduction of Micro Frontends. The combination an Nx Build Cache and Module Federation allowed them to dramatically reduce build times.
Also, for improving build times after changes that affect the whole application, the Nx Cloud could help as it provides distributed task execution. This means, that several parts of the system are built in parallel on different nodes in the cloud. Also, the Nx Cloud comes with a distributed cache out of the box.
Manfred: Helmut, for getting started, can you tell us a bit about the company you are working for?
Helmut: I’m the deputy head of IT at Cube Bikes. We are a large bicycle manufacturer and the European marked leader for mountain bikes. We are already working quite long with Angular. Originally, we started with AngularJS in 2014. There are several systems built with it, e. g. for merchandise management and stock management.
Manfred: Awesome. One thing I didn’t now is that Cube bikes are manufactured in Bavaria (Germany).
Helmut: Yes, we are in the north of Bavaria and manufacture most of our bikes directly there. Also, there is our headquarter and the IT department.
Manfred: Very cool! You are developing quite a big system with Angular for several years. What kind of system is this?
Helmut: Many years ago, we started with Access-based solutions and then we moved over to AngularJS and then to Angular. We started with the mentioned merchandise management system. Then, we added the stock management and meanwhile we are also implementing systems for communicating with customers like a web shop.
Manfred: Recently, you’ve migrated this system to micro frontends. I also helped a bit with this. Can you tell us about the motivation for introducing micro frontends?
Helmut: Sure. Here, we are talking about a system that is in active development for seven years. Meanwhile we have 17 developers; about the half of them is writing Angular code. Over time, we got issues with the size of this project. You notice this during development because starting the project takes too much time. Also, the build times were getting longer and longer.
This makes everything sluggish over time. However, in the beginning, when the system was small, it felt lightweight and slim, and this is what we wanted to get back. Hence, we were looking for ways to split up the applications for development but provide it as one integrated application to the users at runtime. Hence, we did a workshop together with you [AngularArchitects.io] to find out about possibilities.
Manfred: And I think the resulting numbers of this endeavor are quite well. You’ve really managed to dramatically decrease build times, didn’t you?
Helmut: Yes, especially when developing locally, because we only need to start the parts we are working on. During the build [on the build server] it depends on a bit: Before it took about 10 minutes. Now, if we can take many things out of the build cache – we will talk about it in more detail a bit later – then it can be reduced to 3 or 4 minutes. However, sometimes it takes a bit longer. This has to do with ngcc and sometimes we have changes affecting everything, e. g. when changing the package.json. Hence everything needs to be recompiled and then it takes longer as before. But as this does not affect all builds, at the end of the day, the build is still faster on average.
Manfred: Cool. And we are lucky because ngcc already has an "expiration date". Ok, that means this is all about decreasing build times. From 10 minutes to 3 or 4 in the best case – this is quite a number.
Manfred: How did you implement Micro Frontends?
Helmut: We use Nx [Monorepos] in combination with Module Federation.
Manfred: I guess there have been some challenges, right?
Helmut: For sure there have been some challenges. That’s why we did this workshop with [AngularArchitects.io]. We delt with some of these challenges upfront: Originally, we had several npm packages. However, we removed them before to get rid of version conflicts [and put the code into one Angular application] and we already used lazy loading a lot. This was for sure a big advantage for the migration. Also, we had something like Domain-driven Design as we sliced our application into business domains. These domains have been the foundation for splitting the application into several Micro Frontends in the Nx monorepo.
Manfred: I think, this shows once again that the theory of domain slicing makes a lot of sense. If one already has decoupled domains that don’t depend much on each other, such a migration is easier. And this was really the case in your project. I remember, I was really astonished how well the domains have been isolated from each other.
Helmut: Yes, thanks to you and your consulting in the past we respected this. Hence, this all was a good investment.
Manfred: Thanks. I’m happy to hear this. You also use the Nx Build Cache. What advantages does this bring?
Helmut: Most of the times one changes one module at a time, one Micro Frontend. The other parts are very often not changes. Hence, it makes sense to not recompile these parts that haven’t been changed. Exactly this happens when using the Nx Build Cache. It checks for each part whether it changed. If it didn’t change, it takes the result of the compilation out of the cache; otherwise, the affected part needs to be recompiled.
Manfred: Cool. And this is the reason why we managed to reduce the build times to 4 minutes.
Helmut: Totally! Otherwise, if needed to recompile everything time and again, we would end up with 15 or 16 minutes.
Manfred: When not using additional offerings, Nx caches in the file system. I still remember, you didn’t like the idea with directly caching in the file system that much. You wanted to place it somewhere else. Hence, you wrote your own cache implementation. What does this implementation do?
Helmut: Yes, we use Kubernetes and there we already have an S3 cluster. Our cache implementation zips the built artefact and uploads it there and if we need it again, we are fetching it from there.
Manfred: Hence, we have a global cache, and we don’t need to work with file shares that might be different on different machines. Helmut, thanks for taking the time for this interview. This is really a cool case study.
Helmuth: With pleasure!
What’s next? More on Architecture!
Please find more information on enterprise-scale Angular architectures in our free eBook (5th edition, 12 chapters):
- According to which criteria can we subdivide a huge application into sub-domains?
- How can we make sure, the solution is maintainable for years or even decades?
- Which options from Micro Frontends are provided by Module Federation?
Feel free to download it here now!
Don't Miss Anything!
Subscribe to our newsletter to get all the information about Angular.
Angular Schulung: Strukturierte Einführung
In dieser Schulung lernst du von bekannten Insidern und Experten der ersten Stunde anhand vieler Beispiele, wie du mit Angular erfolgreich moderne Anwendungen entwickelst
Angular Architektur Workshop
In diesem weiterführenden Intensiv-Kurs lernen Sie, wie sich große und skalierbare Geschäftsanwendungen mit Angular entwickeln lassen.
Angular Signals & Your Architecture: 5 Options
This article provides 5 different options and some technical background information for building architectures with…
What’s new in Angular 16? – Signals, Hydration, esbuild and More!
Angular 16 comes with two big innovations: signals and non-destructive hydration. Numerous further improvements simplify…
Automatic Migration to Standalone Components in 3 Steps
Since Angular 15.2, there is a schematic that automates the migration to Standalone Components.
Signals in Angular: The Future of Change Detection
Angular is going to rely on a reactive mechanism called Signals to make change detection…