Make your web app development sales-centered, more productive, and risk-resilient by borrowing the principles of microservice design from the back end.
Building front-end applications gets tricky over time. Web apps grow, accumulate new features and elements, and become difficult to manage.
Regardless of their size, most contemporary web apps rely on:
As long as a website remains small, one team and one codebase are enough. Everyone in the team shares the same knowledge, so work and communication go on smoothly. But as time goes on and the codebase expands, new additions to the team are necessary to handle the growing complexity.
Sooner or later, the project becomes too big for a single individual to grasp. Consequently, “knowledge silos” arise within, breaking down communication and reducing productivity. “At some point,” Frederick Brooks writes in “The Mythical Man-Month”, “adding new developers to a team does not increase productivity.”
“At some point, adding new developers to a team does not increase productivity”
Frederick Brooks, “The Mythical Man-Month”
In the beginning, entire applications were developed as monoliths, with no division between front and back. As a result, they could expand indefinitely and grow into behemoths. We sliced these behemoths in two because it was easier to control the front and back separately. Later, the back end got the same treatment: split into more manageable parts called microservices, it merged into one by way of an aggregation layer.
Unfortunately, throughout all that time, the front-end architecture remained largely unchanged. Today, it’s still a hefty brick of code sitting atop microservices (Fig. 1).
The front end of today is a world apart from the front end of yesterday. You can make full-fledged games with HTML5 and mind-blowing animations with CSS. So it doesn’t make sense to cling to the same development methodology we used in the 2000s.
When it comes to the structure, micro frontends mirror their back-end counterparts. You can see a bird’s eye view of the micro frontend architecture in Figure 2. Notice the visual similarities to the microservices design in Figure 1: several vertical pillars connected by an overarching integration layer.
The following are key features of the micro frontend approach viewed through the lens of teams:
What is a mission statement? Essentially, it’s a definition of the customer need or use case we’re trying to address. Consider Figure 3. The customer is looking for something and Team “Inspire” helps them find it. With the choices narrowed down, Team “Decide” strives to make the decision process easier. And finally, once the customer knows what they want, Team “Checkout” makes sure they can purchase it.
You may have noticed that the missions roughly correspond to steps in the customer journey, or to stages in the sales funnel. The sales funnel comes in many shapes and forms, but let’s look at its simplest implementation in Figure 4.
The three basic stages of the sales funnel (or customer journey) are:
Now we can see how each team is responsible for each stage in the sales funnel:
In web design, the sales funnel (often synonymous with the customer journey) goes hand in hand with specific website elements.
For example, the customer becomes aware of our offering by visiting our homepage. They consider the available options by browsing through and clicking on items. Finally, they make a decision by placing some items in the basket and proceeding to payment. We can map teams, website elements, and the customer journey in Figure 5:
The correspondence between website elements and the customer journey isn’t always clear-cut. For example, you may have a header or footer that functions exactly the same way on every page. It would be unproductive to have all the teams work on it simultaneously. Not to worry – you can assign such an element, also known as “isolated user interface”, to one team only (Fig. 6):
The fact that micro frontend teams are interdisciplinary is an important aspect that sets them apart from microservices. With microservices, team members are selected on the basis of skill or technology. With micro frontends, the members are diverse because the goal is to address a use case or a customer need (Fig. 7).
Cross-functional teams have the following advantages:
Micro frontend teams work on separate elements independently and can choose any technology they like, but the final product must look coherent. If the teams did not communicate at all, our website might end up looking like a Frankenstein’s monster.
To ensure a coherent result, we must allow between-team communication in two critical areas:
Micro frontend teams are usually smaller and way more focused on customer needs than the traditional web development teams. This allows them to deliver features faster, more efficiently, and in a manner more attuned to the customer than in the old model.
In traditional web development, one thing going south could potentially ripple through the entire project like a domino effect because everything was interconnected. With micro frontends, the risk of malfunction is limited to the scope of operation of a single team.
The bigger the codebase, the harder the refactoring. To give an example, it took GitHub years to move away from its dependence on jQuery. Meanwhile, each micro front-end team works on its own codebase, smaller than in the final product. For this reason, refactoring is easier, less expensive, less time-consuming, and doable on a case-by-case basis.
Micro frontends can be used to change giant websites into sleek and modern, customer-centered systems. Now slow and clunky, such giants will reap all the benefits of micro frontend design we have discussed so far: vertical structure, customer focus, sales funnel optimization, increased creativity and problem-solving, more effective in-team communication, faster feature development, improved risk-resilience, and easier refactoring.
For one of our clients, a SaaS platform for gyms, we’re following an approach akin to micro frontend development. Our teams are divided into sub-teams, each responsible for particular functionalities, dubbed “sub-apps”. These sub-apps may separately handle employee management, booking, analytics, etc. Afterward, they’re all dynamically integrated into the final product by way of JS scripts.
Next time, we will discuss the technical aspects of micro frontends. Are you curious how all the different technologies come together under the hood in the aggregation layer? Come back soon to learn more.