Problems with current frontend development processes

Front-end Monolith

The Micro Frontend Architecture
Previous traditional development processes. Source: Mobillegends.net

The software development process has evolved through 3 main models:

  • The Monolith: A single team is responsible for all development. The most typical is the MVC pattern, server-side rendering
  • Front & Back: There is a clear division between the frontend and back-end team and server and client.
  • Microservices: The server development process is broken down into separate parts, and each part is developed in parallel.

The common disadvantage of all three models is the frontend monolith. The front end is developed and maintained by a separate team, which leads to a long development period and difficulty in maintenance, making the front end a bottleneck of the whole development process.

Separate frontend apps in the same ecosystem lack a connection with each other

A company can develop many individual apps with many similarities in the same ecosystem. There are many components of one app that can be reused in another, requiring them to have a connection with each other. However, for current development processes, especially with web3, when there is no longer a server, and due to the difference in technology used between apps, the interaction between applications is almost non-existent.

Components can't be reused between apps that combines TraDAO, TRAVA
Components can't be reused between apps. Source: Trava.finance

* Micro frontend architecture was born to solve the above problems

Micro frontend architecture

Monolith frontend app slicing
Monolith frontend app slicing

A frontend app will be broken down into many micro-apps developed independently, in parallel, by different micro developer teams, running on a separate repo. Then a container app, or shell app, will be responsible for aggregating, routing, and navigating the micro apps and switching between micro apps without reloading the page.

The system is flexible in that:

  • Micro apps can be developed using different technologies, making for a particularly important property of the micro frontend: technology agnostic. That gives micro teams the freedom to choose development processes and technologies that match the properties of their micro app, making development and maintenance faster and easier.
  • Micro apps can freely share components, functions, contexts, and hooks that can be reused in other micro apps. That helps decrease the time and effort required to rewrite the source code, reduce redundancy in source code, and increase the association between micro-apps.
  • It is possible to remove the container app if it is not necessary to aggregate all the micro-apps into one large app.

With the above characteristics, micro frontend architecture is especially effective for large-scale frontend applications with large development teams.

Micro frontend disadvantages

Drawbacks of Micro frontend architecture:

  • Dependencies between micro-apps: Improper division of large apps into micro apps will cause difficulties in the independent and parallel development of micro-apps because they are highly interrelated. According to the rules, there should be a strategy to divide micro apps logically: high cohesion and low coupling (association within a micro app is high, the association between apps is low). That helps to reduce the dependencies between apps.
  • Conflicts between micro apps due to differences in technology: Although allowing micro apps to choose technology freely, micro frontend architecture still cannot solve all the problems of clashing between apps when combining them or when reusing components between different micro-apps. Therefore, it is still advisable to limit the use of many different technologies and try to synchronize micro apps as much as possible.
  • Complexity: For their components, functions, contexts, and hooks to be reused effectively without encountering bugs by other micro apps, micro teams need to have a detailed plan and estimate the use cases reasonably in advance. Like the extensibility of their components, other micro apps also have specific requirements for a reusable component. Developing such a component cannot be simple, resource-intensive, and requires developers to have extensive experience.

Some Micro Frontend tools

Here are some of the simplest methods and tools to help build a micro frontend architecture

Webpack's Module Federation Plugin

Webpack is a static module bundler for modern JavaScript applications [2]. Webpack 5 offers Module Federation Plugin that lets us share and connect components between different micro apps built with different frontend frameworks to build a micro frontend architecture.

The strength of this approach is that it is effortless to implement. Each micro app only needs to configure the entry to communicate with other micro apps and define the components it wants to share in a single webpack.config file.

Demo Micro fronted structure with three micro apps using webpack module federation plugin. Source: Dev.to
Demo Micro fronted structure with three micro apps using webpack module federation plugin. Source: Dev.to

Another strong point is that it's not a framework, but just a plugin added to the webpack, which gives micro teams the freedom and flexibility to build their micro-app. That is often more difficult for frameworks to build micro frontends because it has very tight control over their microapps' dependencies.

Bit

The bit is designed in style "everything is component."

Bit main concepts
Bit main concepts. Source: octuweb.com

Bit helps micro teams export their components to bit.dev, allowing other micro teams with import access to reuse those components. Similar to installing a dependency using npm or yarn, the bit provides a bit-cli tool that makes this process easy by the command-line interface.

Micro teams are responsible for maintaining, upgrading, and creating different versions of their shared components. Other teams are free to import arbitrary versions of that component, and changes from the producer to the current version of the component will be automatically updated on the user side.

Single-spa

Single-spa is a typical framework for building, deploying, and testing multiple micro frontend apps in a single extensive application.

Two main parts of Micro frontend architecture built with Single-spa:

  • Single-spa-root-config: acts like a container app,
  • Micro apps are packaged up into modules and combined in the container app.

Single-spa-root-config register an micro app to single-span system using registerFunction() with 3 arguments:

  • Name: Project identifier
  • App: an import call to bring the micro-app to the single-spa
  • activeWhen: do the routing, decide when to activate or deactivate the micro-app

We can use many tools to import, such as systemJS import map, webpack module federations, etc.,

Some similar frameworks to build micro frontend architecture: Luigi, Piral, etc.,

Conclusion

With its outstanding advantages, such as increasing development speed, easy maintenance, and optimizing the use of source code, micro frontend is becoming a popular pattern for developing large frontend apps today.

References

[1] Micro Frontend Architecture and Best Practices, Xenonstack, accessed May 12th, 2022.  

[2] Webpack documentation, Webpack website, accessed May 12th, 2022.

[3] Shedu, I., How to Build a Micro Frontend with Webpack's Module Federation Plugin, dev.to, accessed May 12th, 2022.