Micro Front-end Architecture — Rapid Development In A Startup Environment
Building a new front end application in a startup can be challenging, as you want to be able to quickly add features for your customers, and don’t spend a lot of time building the best technical solution. Using a Micro Front-end Architecture can help you in being agile, flexible, and most importantly: fast.
My name is Coen Mooij, and I am responsible for all that is Web at FINN, Banking of Things. FINN is a startup initiative from ING Labs that connects IoT to payments. Smart fridges, your friendly neighbourhood car wash, your car itself, or any smart device you own. We enable it to make autonomous payments on your behalf.
The Situation
We are a platform, and as such, have different types of users (e.g. consumers, clients, suppliers, partners, administrators). We also have some public facing web applications that don’t have any roles or permissions, like our marketing website or the technical documentation.
It does not have a lot of content right now, but it will grow. As we expand our product from POC, MVP, all the way to Enterprise, features and complexity increase. Of course we started out with a single repository, but stuff got a little complicated when we needed to show & hide content based on which user was looking at the page. Every feature we added, it took a little bit of impact consideration. Also, when there would be a bug, there was a small functional and security risk that functionality leaks out to different user types. As a bank, we can not risk that.
Splitting it up
For me, as a developer, the first solution to something getting too big is separating responsibilities. So we did and we decided to make a couple of small and simple applications instead of a single big one. Currently, our micro front ends are characterised (but not limited) by these three rules:
- They do not contain any component logic, but use a component library.
- They do not contain any assets, but get these through our CDN.
- They contain views, business logic and data for one specific user group.
How did we build it?
For our component system we use a private library. Since we are using Angular, we publish our versioned Angular Library to the NPM registry as a scoped package.
All we need in the micro front end is npm install -s @example/components. Great! The package.json should look something like this:
Now for the assets. We have all our styling into a separate repository which has synced versions with the component system. For now, some assets like logos and fonts are combined into one package that is delivered over CDN. In our index.html we just need a few lines to add our icons, fonts and minified styles. Whichever version we need. Awesome! Almost there.
The pages for our application look very simple and mainly use our shared components. Simplified, a section of the page could look like this:
I think it’s important to mention that creating generic (enough) components is something we aim for regardless of using micro front ends. But more on what makes a good design system in the next part of this series.
Simplicity
Our architecture now only contains the pages, domain logic, data services, API connection and content for our micro app. Easy, right? No need for keeping track of the usertype, conditionally showing menu items or complex error flows. All it cares about is the specific target audience. Half of our apps don’t even need to connect to an API. And creating a new app? No problem. We can do it in an afternoon.
What I love about this article is there are not a lot of code examples, since this is a ‘less-code-by-design’ strategy. But if you’ve ever worked on a medium to large size front-end application, you might recognise some of the pain points highlighted.
Considerations
Unfortunately, life is often a game of balance. We can not have the cake and eat it too. When we create smart solutions, there are always downsides. In our case:
1. Increased Operational Complexity
Instead of managing one running application, we now have 5! That means more test environments, more pipelines, and more moving parts that can go wrong. Luckily, if something goes wrong, most other things just keep going!
2. Maintenance
As a developer, it means that we have to sometimes switch between projects. To make this switch hassle-free, we need to keep things consistent. For instance, every week we update to the latest component system, framework version, and sync architecture or coding guidelines changes. More work is spent on maintaining the system, and less on creating features. You do have to still write code though!
3. Ownership & Responsibility
Even though both updating & adding to a small system is way faster, not all companies allow for this flexibility. You might need to earn your right to apply these concepts, or make a good case before you can start implementing. Fortunately, at FINN we have a lot of shared freedom and responsibilities, and we have our priorities aligned. Going fast while making sure we can keep going fast.
4. Alignment
Projects are easily divided between teams. Nonetheless, we need to keep in sync with each other, and an effort needs to be made to make sure teams are aligned. This is no different than in other organisations, although using micro front ends makes it easier for apps to diverge in architecture.
Next steps
Since our architecture is modular, soon we will migrate a legacy app from PHP to an Angular Micro Front End. This will be quite easy. We’ve done it before, have a small impact, are in sync with coding guidelines and on the latest Angular. We might add some new components to our library, or styles to our CDN. Everything else keeps working while we build the latest addition to our ecosystem.
In Conclusion
In a startup environment, things tend to rapidly change. A micro front-end architecture allows engineers to respond quickly to these changes. Investing early in a modular infrastructure facilitates independent deployments of decoupled codebases.
Reduced state management by design makes technical solutions simpler. This all contributes to development speed and flexibility. By making maintenance a part of the development process we ensure our privileged position of being always ready.
When building micro front ends you probably need a way to share components. The next article in this series will cover how to leverage a design system and make this possible.
What do you think?
Of course, as a creator, we are never done with refining our ideas, strategies and tactics, so I would love to hear your thoughts. Would this approach work for you and your project(s)? What are the values that you consider when making such a decision? Let me know!
About FINN
FINN — Banking of Things is a platform that connects IoT to Payments. Simply put it enables IoT devices to do autonomous payments. Facilitating Product-as-a-Service business models by making things pay. Want to know more? Check out the website: makethingsfinn.com
