Your frontend is a fish tank
Imagine you are working at a tropical aquarium. You are in charge of one of the main tanks, and have a ton of cool and beautiful fish swimming in there. All of them have specific needs, but you are good at your job and have created the perfect environment for all the fish in the tank to live together. The aquarium is successful and has happy customers, so your boss is planning to expand. Your boss wants to build a bigger tank with tons of new fish. He promised the visitors sharks, clown fish, salmon and koi carps.
Just make it work
To me, this tank serves as a perfect analogy for a monolith frontend application. Your boss (product owner) wants new fish (features) to impress the visitors (end-users), and probably expect you to just make it work. The visitors expect to see happy and healthy fish (expect the features to work). As a caretaker (developer), your task is to keep both your boss and the visitors happy whilst taking care of the technicalities that keep the fish healthy, but you know that placing some fish together is risky (might cause bugs or errors). You’ll also need to install specific water plants (dependencies) for some fish to thrive, but they’ll have a negative impact on some of the other fish.
Micro-frontends
An obvious solution would be to split the tank into multiple smaller ones, creating separated environments. Apply this to a frontend, and you’re basically doing micro-frontends. You cut your massive monolith frontend into multiple smaller ones. They each have different functionalities and configurations, but they are pieced together in the browser to provide one working application to the end users. You’ll get a few benefits from that:
- Smaller bundle sizes
- Faster pipelines
- Downtime only affects part of your app
- Trace bugs to less code
- Mix and match parts of your frontend
Our own fish tanks
In my own department, we chose to build a micro-frontend framework from scratch with React and TypeScript. Mainly because we didn’t totally understand the concept at first, we wanted to keep in control and we didn’t want to pay money for a framework.
Over the course of two years, we built 6 frontends and 1 code library, that together form our BestOne Buying platform. We cut our frontend along the lines of our pages, which means that every page houses a different micro-frontend.
One for all…
We have one frontend that keeps the whole structure in place, which we call Umbrella. It’s hosted on the root of our cluster and it has some core features:
- Handling user authentication
- Handling page navigation
- Rendering overlaying UI elements (like notifications)
- Rendering micro-frontends in the DOM
- Providing relevant data to micro-frontends
…and all for one
For every page in our platform, we have one micro-frontend. This micro-frontend is tasked with fetching, rendering and manipulating data for that specific page. For example, the micro-frontend for our collections page only knows how to CREATE, GET, UPDATE and DELETE collections, and renders UI elements that our users can use to perform these actions. It does not know how to authenticate the user, but it will receive the right credentials from Umbrella to be able to perform these actions. In turn, it can communicate back to Umbrella as well, so we have a two-way communication channel.
Let’s take an example. Our user clicks on a page button in the navigation menu while having an uncompleted form open in the micro-frontend they currently have open.
Umbrella will send a message to this micro-frontend, basically asking if it can be closed. That micro-frontend holds some unsaved changes to a form, and it might be good to let the user confirm this action to prevent them losing their changes. Therefore, the micro-frontend replies that it might not be okay and that the user should be asked for input.
Umbrella receives that signal and renders a confirm dialog on the page, overlapping the micro-frontend. It informs the user that they will lose their progress if they navigate to a different page, and asks them if it is okay to proceed.
If the user decides to continue, the micro-frontend will be closed and the user will be taken to the intended page. However, if the user decides to stay, the navigate action will be ignored, and the user can continue to make changes to the form.
Challenges
Since we built our own micro-frontend-framework, we also encountered a few challenges that a framework could’ve solved for us. We’ve had to prevent any external code interfering with our communication channels. We do this by thoroughly screening all signals going back and forth between our frontends. Also, we don’t want to have duplicate code in different frontends, so it was necessary to create our own code library. This way we can store logic, UI components, Typings and other things in one place, and have it available for all our frontends to use.
In the end, if you want to start using micro-frontends but you care more about speedy development than owning all the code, you should consider a framework like Bit , Luigi or Piral. They offer a lot of solutions for common problems out of the box, but of course you’ll need to pick the right one and learn how to use it.
It was fun building my very own aquarium though 😜
About me
Hello! My name is Jory Schiebroek, and I work as a Frontend Developer for the Buying team in the BESTSELLER Tech department.
