Micro Frontends

Hello everyone, I hope you all are doing well!

"Our end users don’t care whether your app is a monolith or micro-frontends—they just want an app that loads expeditious and solves their quandaries. "  ✌                                                                                                                                                                                                 Knowledgefactory.net[Sibin]

Today we are going to discuss Micro-frontend architecture, Maybe most of the latest digital products are adopted microservice architecture on their back, companies are blissful and developers are relishing their works, from all the angles technical experts are verbally expressing microservice architecture is fine.

But, the Front end part is still monolithic. It's the right time to think about Micro Frontend architecture

What is Micro-frontend architecture?   

Micro-frontend architecture is a design approach in which a front-end app is decomposed into individual, micro-apps working loosely together. The micro-frontend concept is vaguely inspired by, and designated after, microservices.

A simple micro-front end architecture


Some of the benefits of the micro-frontend pattern:

  • Independent development teams can collaborate on a front-end app more easily.
  • Micro frontend codebases can be smaller, more manageable
  • Micro frontends promote reusability across process and case management
  • Micro frontends help you rapidly develop different views of your processes relevant to each person’s role
Micro frontends are sections of our UI, often consisting of 'n' number of components, that use frameworks like React, Vue, and Angular to render their components. Each micro frontend can be managed by a different team and may be implemented utilizing its own framework. It is practical and suggested to utilize just one framework for all your micro frontend, albeit you may integrate additional frameworks when migrating or when experimenting.

Each micro frontend has its own code repository, its own package.json file, and its own build implement configuration. As a result, each micro frontend has an independent build process and an independent deploy / CI. This generally betokens that each repo has expeditious build times.

Are micro-frontends the right cull for you?

There’s an abundance of substantial reasons to adopt a micro-frontends architecture, but they do integrate an abundance of involution to your front-end ecosystem. Afore you go ahead and modify your app to utilize micro-frontends, ascertain that you take a moment to evaluate if the involution is worth the payoffs that micro-frontends give you. Here are two reasons why you might adopt a micro-frontends architecture.
  • You have a huge app with a ton of complexity
  • You have multiple teams contributing to our app, and each has its own deployment cycles.
Here’s what the server looks like

require("dotenv").config();

const path = require("path");
const proxy = require("express-http-proxy");
const express = require("express");
const app = express();

app.use("/auth", proxy(process.env.AUTH_URL));
app.use("/search", proxy(process.env.SEARCH_URL));
app.use("/payment", proxy(process.env.PAYMENT_URL));

app.get("/", (req, res) => res.sendFile(path.join(__dirname, "./index.html")));

const port = process.env.PORT || 8000;

app.listen(port, () => `Listening for connections on port ${port}`);

Most of the authentic stitching logic is inside of the index.html file being sent to the utilizer

<!DOCTYPE html>
<html lang="en">

<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>Micro front ends!</title>

<link rel="import" href="/AUTH/micro-frontend.html">
<link rel="import" href="/SEARCH/micro-frontend.html">
<link rel="import" href="/PAYMENT/micro-frontend.html">
</head>

<body>
<auth-micro-frontend></auth-micro-frontend>
<search-micro-frontend></search-micro-frontend>
<payment-micro-frontend></payment-micro-frontend>
</body>

</html>

Our end users don’t care whether your app is a monolith or micro-frontends—they just want an app that loads expeditious and solves their quandaries. Granted, something like micro-frontends might avail us meet that goal in a more scalable way, but at the end of the day, the utilizer should feel like they are utilizing a single application.

Some of the Micro Frontends Frameworks

1.Bit

The Bit is a scalable and collaborative way to build and reuse components. It's everything you need from local development to cross-project integrations.
If you take a look at the bit.dev homepage you will notice that it is composed of independent components that are built by different teams, in different codebases, and are all integrated together to create a cohesive product.




single-spa is a framework for bringing together multiple JavaScript micro frontends in a frontend application. Architecting your frontend using single-spa enables many benefits, such as: Use multiple frameworks on the same page without page refreshing (React, AngularJS, Angular, Ember, or whatever you're using)

3.Systemjs

SystemJS is a module loader that can import modules at run time in any of the popular formats used today (CommonJS, UMD, AMD, ES6). It is built on top of the ES6 module loader polyfill and is smart enough to detect the format being used and handle it appropriately.


We should use Webpack to generate a bundle for production or development, let's say Webpack helps you to generate a folder called dist and a file main.js within this folder. This is the result of all of your JavaScript code that you normally have in a folder called src

The more we add code into our src folder the heavier is this main.js file that Webpack generates. Remember that this is the file you take to our production environment and clients download in their browsers, if this file is heavy that means it will take longer for the users to load your page.

That means we care about the size of our bundle but we also want to keep adding new features to our projects

With Module Federation we can import remote Webpack builds to our application. Currently, we should import these chunks but they would have to come from your same project. Now, we have these chunks (Webpack builds) from a different origin, which means, a different project!

Comments