“Usually, we have an IT-department and a business department working separately, I think that in an ideal scenario there are end-to-end cross-functional teams responsible for solving specific business issues”
This was one of my colleagues about micro frontends and how this way of working should be implemented. But let’s rewind, what does the term even mean?
Working with micro frontends means that you work in cross functional, autonomous teams focused on everything related to a specific function or part of the customer journey.
So, for example, in an e-commerce store, there could be a team responsible for the search function, another for the check-out and so on. In this example, the team responsible for the search function would have responsibility not just for designing the search button on the site (frontend), but also for checking which of the items searched for the company has in stock (backend). The various functions often communicate using pub-sub patterns, which is a communication pattern between services, enabling decoupling and enhanced scalability since it is not necessary for the sender of the information to understand how the receiving modules work. Furthermore, when developing the micro frontends separately, the process of testing the specific modules is much quicker than for monolithic code bases.
Micro frontends present a potential way to move away from monolithic architectures through enabling a high degree of autonomy for the teams, freer choice of tech stack, decreased complexity, fewer unnecessary interdependencies, better DX (=> easier hiring), and quicker time-to-market for new functions.
There are many ways to improve developer experience and micro frontends is as of now more a vision and a paradigm than a methodology — but it is continuously developing.
The question remains, what is the future of scaling development?
Gustav Malmer, Client Relations
Share article
