MicroFrontend on Time Friend

Micro-Frontend Advanced 4 - Cross-Framework Shared Components (Widgetization)

Sat, 22 Jun 2019 22:17:36 +0000

In micro-frontend, we can let sub-modules use different framework technology stacks according to our business needs. Although reaching this step is already very beautiful, is this the end of micro-frontend?

The answer is no, micro-frontend boundaries can be further broadened.

The previous micro-frontend article https://time-friend.com/archive/qh7x5i5szfh/ introduced how to call React components between sub-modules with the same technology stack.

What we’re talking about today is how sub-modules between different technology stacks call components from different technology stacks.

Micro-Frontend Advanced 3 - Cross-Module Shared Components

Sun, 12 May 2019 22:17:36 +0000

After front-end microservices, we face a problem: duplicate code between modules cannot be reused.

If we use npm to manage our duplicate code, we’ll have additional costs maintaining npm packages. Updating npm package versions in sub-modules is also very troublesome. There’s no optimization in js file size either.

Today let’s talk about how to use one component simultaneously in multiple modules.

Approach

Manage public components in base module, encapsulate components as dynamic components, so when packaging we can split this component into a separate file. When other sub-modules need this component, dynamically get it from Base module.

Micro-Frontend Advanced 2 - Local Development Guide

Mon, 22 Apr 2019 22:17:36 +0000

After building our microservices front-end application using single-spa, there’s actually a problem that will always trouble us, That is how to develop effectively? How to be as simple and easy to use as our usual front-end application development. Today using umi sub-module as an example, hoping to give everyone an idea

Today I’ll introduce one method, hoping it helps everyone.

Module Loader

Do you remember my previous module loader, https://time-friend.com/archive/1a60cede/

We just need to encapsulate the original module loader into an npm package.

Micro-Frontend Advanced 1 - Umi-Based Submodule Solution

Sat, 13 Apr 2019 22:17:36 +0000

It’s been more than half a year since the first article about front-end microservices. Many people are interested.

Today let’s talk about how we build a more complete front-end microservices sub-module based on umi.

If you’re using front-end technology stacks other than React, Many of my handling methods can also be applied to other technology stacks.

Hope it helps you too.

Excellent umi Framework

In front-end mid-backend projects, front-end microservices needs are relatively strong.

Building Your Single-SPA Micro Frontend App with Webpack & SystemJS

Wed, 31 Oct 2018 01:00:00 +0000

Here is an introduction to using micro frontend applications built with Single-SPA in various popular build tools.

Webpack 2+

Webpack 2+ supports import() for code splitting. Webpack 2+ is already widely used in other projects, so I won’t go into too much detail here.

import {registerApplication} from 'single-spa';

registerApplication('app-name', () => import('./my-app.js'), activeWhen);

function activeWhen() {
 return window.location.pathname.indexOf('/my-app') === 0;
}

SystemJS

In our previous projects, we used SystemJS because it facilitates secondary builds after application deployment. It’s also very convenient to use.

Single-SPA Micro Frontend Demo Collection

Wed, 31 Oct 2018 00:00:00 +0000

Here are the single-spa micro frontend demos that can be found on GitHub:

single-spa-examples

This is the official single-spa example. Here is the online demo.

simple-single-spa-webpack-example

This is a usage example built with webpack. The webpack version might be a bit old, but the concept is the same.

single-spa-angular-cli-examples

An Angular example based on angular-cli, suitable for Angular 2.0+ versions.

single-spa-es5-angularjs

An AngularJS example, i.e., AngularJS 1.x version.

single-spa-portal-example

This is already a very complete multi-tech-stack use case, integrating multiple tech stacks with inter-module communication ideas. Very worth studying.

Micro Frontend Solution 8 - Secondary Build

Fri, 07 Sep 2018 01:00:00 +0000

Secondary Build

Further optimize our micro frontend performance

In a micro frontend architecture, each module outputs fixed files, such as the previously mentioned:

Project config file
Store.js file
main.js render entry file

These three are the necessary files for each module in a micro frontend architecture.

When the module loader starts the entire project, it must load all modules’ config files and Store.js files. In a previous article, we discussed config automation, which is essentially a simple form of secondary build. Although each module’s config file is not very large, each file is loaded and is necessary for project startup. Each file takes one HTTP request, and each file’s blocking affects the project’s startup time.

Micro Frontend Solution 7 - Static Data Sharing

Thu, 06 Sep 2018 01:00:00 +0000

From the previous introductions, I believe you now have a relatively complete understanding of micro frontends. Below are some tips and handling methods I’ve developed during my work.

Dynamic Entry

When a new submodule is mounted to the project, a new entry point in the UI is needed to access the submodule’s UI. Such an entry point needs to be generated dynamically.

For example: the menu on the left side of the image should not be hardcoded. It should be automatically generated based on the data provided by each module.

Micro Frontend Solution 6 - Build & Deploy

Wed, 05 Sep 2018 01:00:00 +0000

Micro Frontend Build

There are some things to note when bundling micro frontend projects. Take webpack as an example:

AMD Modules

In previous articles, we mentioned that our loader is based on System.js. So the final bundle of our micro frontend modules must conform to module specifications. We use the AMD module specification to build our modules.

Specify Base Path

Since the module loader calls the module entry file after bundling, To clearly manage each module and correctly load all our module resources, we specify a publicPath for all module resources.

Micro Frontend Solution 5 - Route Distribution

Tue, 04 Sep 2018 01:00:00 +0000

Route-Distributed Micro Frontend

From Application Distributing Routes to Routes Distributing Applications

There is no better way to explain micro frontend routing than this sentence.

Route-distributed micro frontend distributes different business functions to different, independent front-end applications through routing. This can usually be achieved through reverse proxy on an HTTP server, or through the routing that comes with the application framework. Currently, route-distributed micro frontend architecture is probably the most adopted and easiest “micro frontend” solution. However, this approach looks more like a聚合 of multiple front-end applications, i.e., we just piece together these different front-end applications to make them look like a complete whole. But they are not — every time a user goes from App A to App B, they often need to refresh the page. — Quoted from phodal The Matters of Micro Frontends

Micro Frontend Solution 4 - Message Bus

Mon, 03 Sep 2018 01:00:00 +0000

The main function of the micro frontend message bus is to bridge communication between modules.

Black Box

Problem 1:

After applying microservices architecture, each individual module becomes a black box. What happens inside, what state changes, other modules have no way of knowing. For example, when Module A wants to perform an action based on a certain internal state of Module B, there is no way for black boxes to communicate. This is a major problem.

Micro Frontend Solution 3 - Module Loader

Mon, 03 Sep 2018 00:00:00 +0000

The micro frontend module loader handles three main responsibilities:

Loading project configuration files
Loading module API files (used by the message bus, covered later)
Loading module entry files

These are three essential parts for every module.

Configuration File

In our micro frontend practice, each module has an external configuration file used when registering with Single-SPA.

{
 "name": "name",
 "path": "/project",
 "prefix": "/module-prefix/",
 "main": "/module-prefix/main.js",
 "store": "/module-prefix/store.js",
 "base": true
 }

When a module supports multiple URL prefixes, the path can be an array:

Micro Frontend Solution 2 - Single-SPA

Sun, 02 Sep 2018 22:17:36 +0000

Technology Selection

After extensive research, we chose Single-SPA as the foundation for our frontend microservices solution.

Your browser does not support video.

Single-SPA

A JavaScript frontend solution for frontend microservices

With Single-SPA, you can:

Use multiple frameworks (React, Vue, AngularJS, Angular, Ember, etc.) on the same page without refreshing.
Write new code with modern frameworks without refactoring existing code.
Load each module on demand for better performance.
Run each independent module separately.

Demo: https://single-spa.surge.sh/

Micro Frontend Solution 1 - Thinking

Sat, 01 Sep 2018 22:17:36 +0000

In recent years, microservices architecture has become hugely popular in the backend development community, considered the future direction of IT software architecture. How can we apply the principles of backend microservices to build modern frontend applications? Here I provide a frontend microservices solution that can actually be implemented in production.

Comparison of Backend and Frontend Microservices

Advantages of Backend Microservices:

Controlled Complexity: Small size, low complexity. Each microservice can be fully managed by a small development team, making it easy to maintain high maintainability and development efficiency.
Independent Deployment: Since microservices run in separate processes, each can be deployed independently.
Flexible Technology Choices: In a microservices architecture, technology selection is decentralized. Each team can freely choose the most suitable tech stack based on their service needs and industry trends.
Fault Isolation: When a component fails, in a single-process traditional architecture, the fault is likely to spread within the process, causing global unavailability.
Scalability: Monolithic applications can also scale horizontally, but it requires replicating the entire application to different nodes.

Advantages of Frontend Microservices:

Controlled Complexity: Each UI business module is developed by an independent frontend team, preventing code bloat, maintaining fast compilation during development, and keeping complexity low for easy maintenance.
Independent Deployment: Each module can be deployed independently, down to a single component’s UI, without affecting other modules.
Flexible Technology Choices: The most attractive advantage — you can use any frontend tech stack available today, including future ones, within the same project.
Fault Isolation: A single module failure does not affect the entire application.
Scalability: Each service can be independently scaled horizontally to meet business needs without unnecessary resource consumption.

When Do We Need Frontend Microservices?

The project’s tech stack is outdated, developers with relevant skills are scarce, feature expansion is difficult, and refactoring or maintenance costs are high.
The project is too large, code compilation is slow, the development experience is poor, and a higher-level decoupling solution is needed.
A single tech stack cannot meet your business requirements.

Problems and Challenges

We will face the following issues: