Microfrontend Development 2020: Creating a Strategic Roadmap for Microfrontend Development iauro Follow Mar 31 · 3 min read

Microfrontends are a supplement to the boost that Microservices Architecture provides a software solution. Breaking the monolithic frontend, microfrontend development further revamps the development processes as well as the solution quality. Just like services, even frontends can be independently deliverable. All it requires is some perceptive decision making.

Based on our experience with the Microfrontend services that we offer, iauro presents to you a roadmap for strategic decision making in this domain.

The Outline

Although the organizations should be flexible enough to accommodate real-time hiccups, yet defining an outline is necessary to further the journey towards the independence of frontend development. To implement a coherent architecture for microfrontend, organizations can take two approaches:

· View wise Composition: Here, the microfrontend development team will be working on the different frontend components and modules but on a single view. This means that for each view, the microfrontend implementation teams will work together on different frontend components. This is effective in presenting a uniform view. However, a lot of coupling issues are likely to arise

· View Dissemination: Another approach is to distribute different views amongst different microfrontend development teams. This will reduce the coupling risks and is a more familiar way for frontend developers. However, the uniformity of the view might be compromised in this case

Based on their requirements and restrictions, the enterprises can make a call as to which approach they would prefer. Once the approach is defined, the outline for the roadmap is visible.

Understanding the Terrains

The next decision for building the microfrontend implementation roadmap is to understand the possible terrains or compositions that the organizations can navigate through. As of now, there are three popular options for this:

· Client-side Composition: This is a suitable composition technique for single-page applications. Similar application shells can be developed with the same technique. This is, therefore, a good technique if you decide to go with View Dissemination.

· Edge-side Composition: Here we use Edge Side Includes or ESIs. For edge level development this is a good technique.

· Server-side Composition: There are multiple frameworks available for this type of composition. OpenComponents and Piral are some popular examples

It must be noted that for page-by-page composition, any of these composition techniques can be employed. Once the terrains are locked, the organizations can move further to decide their route.

The Route

One can proceed on to the routing of views depending on the composition they choose:

· Application Shell for Client-Side Composition

· Page URL for Edge-Side Composition

· Web Server in case of Server-Side Composition

Till now, the microfrontend implementation roadmap is pretty much locked in. The only thing left for seamless implementation is the way you choose to travel your way to independent frontend development. That leaves the organization with the decision for communication amongst the microfrontends.

Maintaining Communication

Frontend Independence requires strong decoupling, and strong decoupling requires strong communication among the microfrontend units. Here are a few guidelines that can help companies to make a decision:

· Custom events or even emitter libraries for the microfrontend units on the same page

· For inter-page communication, one can choose between

o Web storage solution

o Request to the backend

Effective communication is important for the successful Microfrontend implementation. Once decided over that, the company is ready to introduce independence and reusability in frontend development too.

Conclusion

Building a roadmap to implement a robust architecture for microfrontend is necessary. As mentioned earlier, organizations need to be flexible enough to accommodate real-time conditions. However, the purpose of a roadmap is to assess the deviations for future references. Making these fundamental decisions the companies can ensure smooth microfrontend development, thus, promising quality solutions to its customers.