What are Micro Frontends?

The term Micro Frontends first came up in Thought Works Technology Radar at the end of 2016. It extends the concepts of micro services to the frontend world. The current trend is to build a feature-rich and powerful browser application, aka single page app, which sits on top of a micro service architecture. Over time the frontend layer, often developed by a separate team, grows and gets more difficult to maintain. That’s what we call a Frontend Monolith.

The idea behind Micro Frontends is to think about a website or web app as a composition of features that are owned by independent teams. Each team has a distinct area of business or mission it cares about and specializes in. A team is cross-functional and develops its features end-to-end, from the database to user interface.

However, this idea is not new. It has a lot in common with the Self-contained Systems concept. In the past approaches like this went by the name of Frontend Integration for Verticalized Systems. But Micro Frontends is clearly a more friendly and less bulky term.

Monolithic Frontends

Organization in Verticals

Core Ideas behind Micro Frontends

•    Be Technology Agnostic

Each team should be able to choose and upgrade their stack without having to coordinate with other teams. Custom Elements are a great way to hide implementation details while providing a neutral interface to others.

•    Isolate Team Code

Don’t share a run time, even if all teams use the same framework. Build independent apps that are self-contained. Don’t rely on shared state or global variables.

•    Establish Team Prefixes

Agree on naming conventions where isolation is not possible yet. Name space CSS, Events, Local Storage, and Cookies to avoid collisions and clarify ownership.

•    Favor Native Browser Features Over Custom APIs

Use Browser Events for communication instead of building a global Pub Sub system. If you really have to build a cross-team API, try keeping it as simple as possible.

•    Build a Resilient Site

Your feature should be useful, even if JavaScript failed or hasn’t executed yet. Use Universal Rendering and Progressive Enhancement to improve perceived performance.
 
      

Micro-Frontend With ASP.NET And MVC

Many development teams have spent the last few years organizing and empowering cross-functional teams, building independently managed micro services, and implementing DevOps pipelines to go faster than ever!

These industry shifts, critical for organizations to plan less and react more, solved old problems while creating new ones. As we focused on designing domain-aligned micro services, we also engineered JSON-hungry responsive UIs, Single Page Apps, and portals to consume them. A ton of client-side code has been thrown into our frontend layers creating monoliths, which are often maintained by a different team. Front ends have become increasingly more complex, interdependent and highly coupled to whatever Angular, React, Ember, Vue framework was cool when it was built.

As a result, Micro-frontend strategies and patterns have emerged to break the monolith and promise independent, friction less, end-to-end control of feature code. A Micro-frontend design decomposes your application into smaller isomorphic functions rather than writing large interconnected front-end UIs. Here is a quick run-down of the general implementation approaches each come with their own tradeoffs.

Composition UI: Micro services contain backend and frontend display logic, returning HTML and JS/CSS dependency references to the consumer.

Multiple single-page apps: Fully independent micro sites living at different URLs.

Integration at the Code Level: A more traditional approach that uses a shared code or an app shell with componentized, team owned functionalities added to pages.

Choosing the most appropriate implementation depends on your tolerance for WET (Write Every Time) autonomy versus DRY (Don't Repeat Yourself) co-dependency.

For those already using an ASP.NET Core MVC frontend, we can leverage framework features to support code-level integrated micro-frontends.

View Components

If you need a way to bundle up bits of UI and related behind-the-scenes logic, chances are you're looking for View Components in ASP.NET Core MVC.

View Components don't use model binding and depend only on the data you provide, making it an ideal choice for rendering logic like shopping carts, content lists, or any componentized feature. View Components support parameters and have a backing class making them suitable for complex functionalities. They share the same separation-of-concerns and testability benefits found between view and controllers. Additionally, View Components can be externalized, loaded from a class library, packaged via NuGet, and shared across multiple applications making them an excellent ownership boundary for feature teams.

These characteristics allow feature teams to independently manage microservices and their frontends by deploying parameterized View Components for consuming applications.

Invoking View Components is easy within an MVC view. Tag Helpers provide an HTML-friendly experience with Intellisense support.

FrontendView.cshtml

<!--other shared code-->
<div class="row">
   <div class="col-md-12">
      @await Component.InvokeAsync("GoldTeam.BannerAds")
   </div>
</div>
<div class="row">
   <div class="col-md-4">
   <!--tag helper-->
      <green-team-related-items itemCount="4"></green-team-related-items>
   </div>
   <div class="col-md-8">
      @await Component.InvokeAsync("BlueTeam.ProductDetail",new {displayType = "simple"})
   </div>
</div>
<!--other shared code-->

Summary

Micro service architectures have created new challenges in unexpected places. ASP.NET Core MVC View Components provide a mechanism for teams to isolate and manage frontend feature code, clearly define ownership and enhance agility. Regardless of your implementation strategy, breaking down Frontend monoliths into independently testable and deployable features will continue to be an emerging trend.