Proper frontend development is highly challenging, but scaling frontend development such that several teams can work simultaneously on large and complex products is much harder. We will address the recent trend of breaking up frontend monoliths into smaller, more manageable modules, which has become more common. This architecture improves the effectiveness and efficiency of teams collaborating on frontend code. It may be your goal is to build a responsive or progressive web application. But, there's no secure place to begin integrating these features into existing code. It may also be your goal to use new JavaScript language features. Yet, you find it hard to merge the critical build tools into your existing build process.
In another scenario, you may want to scale development to involve many teams. Yet, the coupling and complexity in the existing monolith could hamper efficient progress. This is because people are bound to step on one another's toes. These real issues can negatively affect everyone's delivery potential. As a result, customers may lose out on a high-quality experience.
Traditional monolithic software
Ancient monoliths or monolithic systems had everything bundled inside one deployable unit. Some monoliths may be quick to design and simple to deploy. But, they are not as agile because the tiniest changes often need full redeployment. Here, we're talking about microservices. They are a more popular architectural concept. But micro frontends cater to the frontend. Instead of one significant, unwieldy frontend architecture, we have several small parts (modules). You develop each one in isolation.
Microservices revived the old idea of building smaller, reusable pieces of software. Each piece only has a minimal coupling to another. Each piece is also efficient at doing one thing well. Thus, they share no dependencies. Developers can also work on them and deploy them independently. Large organizations have used this architectural choice for their projects. Microservices architecture is gaining ground. The reason is that it breaks down the limitations of monolithic backends.
Some significant benefits of microservices include:
- fault isolation
- technology independence
- early scaling
- continuous development and deployment
The resounding success with server-side solutions has not simplified how frontend codebase works. It also does not address how it complements the backend services. Single Page Application (SPA) is popular for superior performance, user experience, and conversion. But, SPAs are also reliant on a monolithic architecture. As SPAs scale, their maintenance and deployment become slow. Every small change is needing regression testing. This increases the efforts in implementation, also leading to high-risk memory leaks
Microservices work to tame issues with traditional software architecture. This happens through following a modular strategy for development. Front-end development can occur through the concept of the micro-app. Hence the name, micro frontends. But, what are micro frontends? Micro frontends are the microservices approach to frontend web development. Again, one should ask why developers consider them to be so. Besides, what does a developer need to begin micro frontend development?
What is micro frontends architecture?
Micro frontends describe the modular approach to web development. An application is broken up by its pages and features; each feature becomes the responsibility end-to-end of a single team. A reusable, component-dependent architecture employs multiple pieces of code. It combines these components to create a monolith frontend which sits on a layer of backend services.
A micro-frontend also makes sure that each feature is individually developed and tested. With micro frontends, the codebase is much smaller. It is also cohesive, meaning it is convenient to maintain. It decouples the features and pages, allowing independent teams to work on them. Now, you can understand why it is much easier to upgrade parts of an application. It is also easier to update and rewrite parts of the application than it would a monolith.
Sample application structure that mounts multiple microfrontends inside one container application. Apps can communicate with each other via common message bus with standardized interface:
Which to choose – monoliths or Microfrontends – and why
It is essential to decide whether to go the route of a monolith SPA or micro frontend architecture. This decision must come before web application development begins. To be fair, micro frontends do not suit every project. They come with their own set of benefits, but they are not ideal for every case.
The complexity and size of the project are two critical factors in making this decision. But, a big team with subteams may work on a project. Each subteam will work on individual modules and functionalities. A micro frontend architecture is a relevant decision. A small- or medium-sized project that needs less regular releases or updates. The teams also depend on each other for releases. Here, they can opt for a monolithic architecture for frontend web development.
The cost of adopting a microfrontend architecture
Using micro frontends offers microservice-like benefits. It's important also to point out the cost of developing micro frontends architecture. Everything does come at a price in software architecture. Some micro frontend implementations can engender dependencies duplication. It increases the number of bytes users must download. Also, the dramatic rise in team autonomy can lead to fragmentation in team function. But, these are manageable risks. The benefits of micro frontends even often outweigh the costs.
Testing
Testing doesn't quite differentiate between monolithic frontends and micro frontends. In general, the methods for testing a monolithic frontend applies to individual micro frontends. So, each micro frontend should have its comprehensive suite of automated tests. This strategy ensures quality and code correctness. The apparent disparity would be integration testing of the various micro frontends. Use the container application for this. This can happen using any functional/end-to-end testing tool you prefer (for instance: Cypress) yet, tread with caution.
Functional tests only cover aspects that you may not be able to test at a lower level of the Test Pyramid. This means unit tests should cover your low-level business logic and rendering logic. You can then use acceptance tests to confirm that you correctly assemble the page. For example, you may load up the fully-integrated application at a particular URL. You may also assert that the hard-coded title of the relevant micro frontend is available on the page. If your user journeys span several micro frontends, use functional testing to cover those. But, ensure the acceptance tests focus on validating the integration of the frontends. It should not impact the internal business logic of each micro frontend. Unit tests should cover these beforehand. Consumer-driven contracts can help to specify the interactions between micro frontends directly.
Sample solutions
- https://single-spa.js.org/ (integrates multiple frameworks)
- Ember Engines (ember dedicated solution for micro-frontend approach)
Conclusion
Frontend codebases become more complex, creating a growing need for more scalable architectures. There must be boundaries establishing the appropriate levels of coupling and cohesion. These are vital for domain and technical entities. It has to be easy to scale software delivery across independent, autonomous teams. This approach is not the only one. There are many real-world cases where micro frontends deliver these benefits. This approach works with legacy codebases and new ones too. Businesses can assess if micro frontends are appropriate for them or not. That said, frontend engineering and architecture continue to evolve in exciting ways. Every serious developer should keep abreast.
If you prefer watching to reading, here is a video on the topic:
