At innFactory, we have relied on microservices in the backend from the beginning. The technological independence and flexible scalability between the individual services are unbeatable in our eyes. Additionally, frameworks like Lagom (Scala) silence the “more overhead” argument.

Last week, I was a guest lecturer at Rosenheim University of Applied Sciences as part of the “Microservices” course and addressed the question of how the frontend can be adapted and integrated into the microservice architecture in the backend.

The “Classic” Approach

In the classic approach, the frontend is left as a monolith. In our experience, this is also the most common way to connect a frontend to a backend with microservice architecture. The development team usually consists exclusively of frontend specialists who integrate the backend via a so-called “aggregation layer.” The aggregation layer provides a special API tailored to the respective needs. This allows the app and website to be served with a precisely fitting interface to keep data transfer low and clarity high. To implement this so-called “backend for frontend pattern” more dynamically, we primarily use GraphQL as a query language for the API at innFactory.

Classic Microservice UI

The “FullStack” Approach

In contrast to the classic architecture, the FullStack approach extends the idea behind microservices all the way to the frontend. Although the individual services are still separated between back- and frontend, technologically mixed development teams emerge that are focused on a specific use case. This usually has a very positive effect on knowledge transfer within the development team, but significant hurdles also arise in the frontend, which are explained below under “Problems in UI development with a microservice architecture.”

FullStack Microservice UI

Comparison: Classic – FullStack

The following comparison is intended to show the tendencies by which the two approaches differ in our experience:

“Classic”

Best practice – low technical risk
Faster onboarding of new developers
One team, one user experience

“FullStack”

Greater knowledge transfer in the team
More flexible developers (+ often higher self-motivation for FullStack projects)
Focus completely on one service

Technical Problems in UI Development with a Microservice Architecture

A particular challenge is the exchange of UI components between individual teams. This is primarily because, as is common in a microservice architecture, each team should be able to maintain and deploy their components independently. OpenTable pursues an interesting approach with their serverless GUI framework OpenComponents (https://github.com/opentable/oc).

Microservice UI Problems

In the backend, the individual microservices are technically completely independent. Providing this independence in the frontend as well and letting each team freely choose between frameworks or libraries like React, Angular, or Ember is difficult to realize. In addition, there are many different versions of the mentioned frameworks as well as other JavaScript extensions. The browser would be forced to load countless JavaScript files for client-side rendering, which would push speed to an unacceptable level. But server-side rendering with, e.g., next.js is also not feasible with different libraries and versions for compatibility reasons.

To still realize a microservice architecture, the only option is a uniform technical basis for all teams. This can be a single framework or development in pure JavaScript, CSS, and HTML. A promising approach is the WebComponents standard, which the major browser manufacturers are currently preparing for.

Conclusion

Adapting the frontend to the microservice architecture promises advantages in team structuring and clear service responsibilities, especially for very large projects. Technologically, this challenge is best mastered by forgoing external frameworks and libraries. One consideration is to implement custom HTML tags with WebComponents in the near future to achieve the desired independence.