How web developers reduce complexity

Web applications consist of a frontend and a backend. They usually communicate with various backend services in order to access all necessary information or place corresponding orders. It may therefore be the case that the product images in an online shop come from a product service, while the product recommendations and shopping cart functionalities come from other services.

In larger organisations and software systems, in particular, it is common for different teams to be responsible for the (enhanced) development, provision and maintenance of services. This is because specialist or domain knowledge is often required during development.

This type of application architecture is summed up by the term “microservice-oriented architecture”. The services are decoupled from each other and operated independently. This leads to greater autonomy and flexibility. It is therefore conceivable that different technologies will be used in the services depending on requirements.

The problem: Backend and frontend are heavily dependent on each other

Nowadays, the web frontend is often implemented by a team and all components converge there. The larger the frontend, the more difficult and complex this task. While changes and enhanced developments of backend services can be implemented and rolled out autonomously and independently, frontend adjustments may also be necessary depending on how a service is changed.

This means that adjustments have to be made to the frontend, retested and rolled out every time. The frontend team therefore becomes a bottleneck and the backend teams are dependent on it. This results in an increased need for coordination and, in the worst case scenario, waiting times.

The solution: Greater flexibility thanks to microfrontends

The logical way to solve this problem is to take the microservices architecture approach further and extend it to the frontend. In this respect, the monolithic frontend is broken down into various components that are supported by different development teams.

With this architecture concept, the backend service not only supplies data, but a mini-application that provides the entire functionality. For example, the product recommendation service supplies its own minimal web application, which is integrated one-to-one with the frontend application.  Each microfrontend as such ensures independent persistence, i.e. has its own database or similar storage mechanism.

This approach allows the independence and decoupling of the individual microservices to be replicated fully throughout the entire architecture. Each team of developers therefore performs development, rollout and topics like scaling independently of each other.  This significantly reduces the coordination effort. While a frontend is still needed in which the individual microfrontends are integrated, there is no longer a strong dependency.

A new challenge presents itself however: Microfrontends need to interact with each other. Parameters such as a product number, for example, have to be transferred in order to cover all use cases. There are various technical approaches that can be followed here, which we will highlight in a follow-on article.

The opportunities offered by microfrontends

•  Faster time-to-market: The teams are independent and flexible in terms of developing and rolling out new functions quickly and easily – ideally with an automatic CI/CD pipeline. Coordination between the various teams and the waiting times are reduced to a minimum.
• Technological independence: Each team can use the technology stack that best suits them. This means that technologies can be exchanged or modernised without the entire application or other areas being affected.
• Developer know-how: Because different technology stacks can be used, there is greater flexibility as regards using developer know-how. For example, technologies can be used that offer the necessary resources.
• Scaling and resilience: Each microfrontend is operated in an isolated environment. If a microfrontend causes problems (performance, errors), this only affects the relevant area and not the entire application. The user can still interact with the other parts of the application. If a microfrontend needs more resources (e.g. storage space or CPU), it is also possible to simply scale it and supply it with more resources.
• Error handling: Handling errors is both an advantage and a disadvantage of microfrontends. The advantage: Thanks to microfrontends, there are fewer dependencies and troubleshooting is easier. Because errors can be searched for within an individual microfrontend, this simplifies the processes – especially when microfrontends are supported by dedicated teams.

The challenges posed by microfrontends

• Duplication: Splitting the application components can result in the same code being used in different microfrontends. Code duplicates can lead to higher maintenance costs, for example, when making adjustments or fixing bugs. This disadvantage can be addressed by using shared libraries. Attention: This can again lead to more dependencies.
• Styling/UI: Microfrontends are independent components of an application. This not only affects the functionality, but also the elements of the user interface. Nonetheless, the finished application should look uniform and comply with the corporate design. Possible solutions include simple sharing of CSS stylesheets or the use of a design system with rules for generating microfrontends.
• Error handling: In the event of an error, localisation and troubleshooting can be more complex, since various independent and isolated microfrontends are used. A code analysis for the entire application also requires significant effort.
• Greater complexity: It is possible that microfrontends will have to communicate with each other. For example, if the recommended products are to update when an item is added to the shopping cart. Communication channels are therefore needed between the microfrontends. There is a risk here that dependencies will be generated again, which will destroy the newly gained flexibility.
• Heterogeneity: The potential to use different technologies for each microfrontend can prove to be an impediment if a developer moves to a different team and the necessary technological know-how is not available. It is therefore a question of striking a balance between more individual independence for each microfrontend and overriding interests (e.g. which technology stacks should be used at all).

When are microfrontends the right choice?

There are various possibilities for structuring an application. Each variant has its advantages and disadvantages. Like everything in software development, microfrontends are not a wonder tool. Whether or not their use makes sense depends on a number of factors: the complexity of the application, the organisation of the developer teams or the required agility.

A monolith can be an appropriate choice if it is a simple and clear application or if the application is cleanly structured (“cut”). If an application is large, if many parties are involved and microservices are already available in the backend, then microfrontends can, on the other hand, offer added value.

It is therefore advisable to evaluate the use of microfrontends with a proof of concept and to assess the results in a neutral way.