Is your organization ready for micro frontends?

Quality frontend is fast

It’s a beautiful statement that cannot be faulted, but it slightly neglects the price of speed. What matters to clients is the first rendered screen, the time to full interactivity, the transition time between pages and the fluidity of animations. Rapidly changing web technologies and their diversity have not favoured the emergence of well-founded statistics that would show what exactly is spoiling these parameters. It’s not so much the measured milliseconds that are interesting, as identifying the places where the greatest improvement in parameters will occur at the least expense. Generally and subjectively, we do not find noticeable differences in speed between modern frameworks. If a correlation were to emerge, then causality would likely lead to the finding that certain frameworks attract developers of varying quality, which then creates a difference in speed. According to Browserstack, frontend slowdowns caused by bad frontend code only rank in sixth place. The top ranks are occupied by poor service performance and poor network connectivity.

Output packet size must be small

It affects speed and consumes mobile data. Speed is more affected by what’s packed in - too many ads rank eighth among the major site decelerators. In general, there is no need to be concerned with this parameter at all. Solving the other parameters will ensure this by itself.

Quality frontend has quality UX

And quality UI as well. UXers usually know their job well - poor quality is created under pressure from all sides. The lead designer needs to be able to tell the graphic designers where the area of usability is and at what point they should put away their shading and colour palates, preferably for the rest of their careers. Kick out the product owners’ priorities and push through proper form movement using buttons, even if the new item isn’t delivered today, but in a week. Again, the technology is virtually irrelevant.

Quality frontend is accessible

The night-blind can see the text against the background, the visually impaired can zoom in on the page without spilling the content, and the blind won’t get a headache when the reader gives them the annotated content. We’re merely talking about the damage caused, for example, by generative A/B testing software. That is, pressures from different departments on the end result.

Quality frontend is consistent

An inconsistent frontend will only gain consistency through a complete rewrite. A sequential rewriting is prohibitively expensive. Once consistency has been underestimated, you can’t make up for it later.

Frontend must be secure

Room for attacks in frontend is fundamentally smaller than in the rest of the application. A handful of attacks are covered by known methods and the rest is a matter of trust. The results of a dependency tree audit are by default disregarded because the vast majority of their findings do not apply in the given context. These include vulnerabilities that are only attributable to JavaScript on the server and not in the browser. Third-party embedded software is politically solvable. Web analytics, ad serving, chatbots, maps and other utilities are included as standard. This software potentially sees anything that is displayed, such as an account number and its balance, and has the potential to send that data elsewhere. It often “spills the beans” in communication, and even a security audit would have a hard time finding it.

What are micro frontends?

Micro frontends continue the trend of “vertical slicing”. The team that is responsible for the development of backend will also be responsible for frontend. The organization avoids horizontal teams; instead, vertical teams are encouraged to communicate effectively with each other and develop common parts communally. Pure theory says that each team should be able to build its part of the application in isolation.

Single page applications

The largest software companies have chosen the single page application technology for their applications. Most developers in the market can and want to do this, making it a non-negligible strategic aspect for decisions in a market with a surplus of demand for programmers. Micro frontends support so-called federated modules, where it is possible to build only part of the application independently and post it. This works on small, isolated units, the adoption of which into corporate applications creates unjustifiable risk. It is still possible to avoid SPA, especially in e-shop applications where we need a strong link with search engines and pages where content prevails over interactivity. Common build itself is no showstopper for micro frontends either, it’s just not as clean. It’s a beauty flaw similar to the strategic terms in scrum.

Organizational structure

The theory is that multiple vertical teams should not be responsible for a single screen. If one team was in charge of displaying map widgets on pages managed by another team - for example, the HR team’s "About us" page, minimally the ability to build independently would be violated. Micro frontends also have a complicated relationship with planning according to the “customer journey”. By default, the client passes through several vertical teams. Strong separation can complicate communication.

Consistency

In microservice architecture, it is common to have one service in Java and another in .NET. The theory of some micro frontend proponents is that teams are free to choose the technology. Gartner, on the other hand, encourages unity at least in the choice of framework, an opinion upheld by rather a large group of Czech large companies, where React technology is very often starting to appear as the primary choice. Other consistencies that are necessary for frontend are design, UX and texting. Maintaining these consistencies without a horizontal team is a major challenge for organizations.

Riders

According to theory, a functional micro frontend model requires all the shared modules to be built for micro frontends. In an application, we need services that are very often provided by third parties - web analytics, chatbots, cobrowsing, A/B testing, dynamic content, ads, maps and more. Most third parties deliver these services in legacy architectures as sdk instead of interfaces. Deploying such services on every page is very costly in terms of frontend performance and especially network communication. If you require on-premise solutions as part of your security, the quality of the solutions delivered will drop significantly. If you want a clean micro frontend architecture, you need to evaluate each individual service. At this point, the technological hurdles will not be major, but the organizational ones will be all the more painful. Some teams have been taught the technology and work methods and this will have to be discarded, as it blocks technological transformation.

Hiring, team size

Downtime is very expensive when working on SW projects. The larger and more complex the organization, the more back-end teams can be expected compared to front-end teams. When you slice an organization vertically across domains, it is common to see allocations of frontend developers under one FTE. This will create difficulties with allocation, motivation and education. Senior programmers will very soon find that they don’t want to work in such teams, which will result in worse recruitment, lower quality programmers in the teams, and ultimately a slower frontend with worse UX.

Are you ready?

Probably not. However, as with scrum, halfway models can still work very well. Keep in mind that frontend and backend developers are fundamentally different professions with fundamentally different workflows. Backend developers, like IT architects, rarely understand the frontend. Invite someone from the industry to help you decide.