Building Micro Front-Ends

Introduction to micro front-ends

In recent years, the programming community has been exploring and implementing microservices architecture. The goal of this architecture is to split up monolithic applications into smaller-sized chunks such that a group of smaller services now work together to provide application functionality. The benefit of doing things this way centers around the idea that each microservice can be independently deployed, can have a completely independent build and release cycle, and multiple copies of these services can be easily spun up to provide scaling capabilities. Each microservice becomes independent of any others and can, therefore, use its own choice of technology stack, deployment pipeline, and testing regime. A microservice can also evolve its functionality over time without impacting other services, as it is an independent unit that does a particular job within a larger community of services.

An extension of the micro-services architecture is the concept of micro front-ends, where a single application can be made up of several user interfaces that are built independently of each other. In other words, if a microservice is responsible for providing a specific set of functionality, then a micro front-end is a front-end that surfaces this data and functionality to a user. If we think of silosIsolated from others. as functionality, complete with services, data storage, and user interfaces, then this silo is a micro front-end. This micro front-end can be owned by a specific team, and the act of isolating the services, data, and front-end has certain benefits. They can be deployed independently of other front-ends, they can follow their own development cycles and release cycles, and they would have no impact on other silos of functionality.

Most importantly, though, is that the application itself is not a monolithic application; it is built up of independent component parts and becomes more modular and easier to change.