Shulou(Shulou.com)06/03 Report--

This article mainly explains "the realization method of micro-front-end", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next let the editor to take you to learn the "micro-front-end implementation method" bar!

Zero coupling between micro front ends

In order to realize the benefits of this architecture, accidental coupling should be avoided as much as possible; this will unlock the flexibility and scalability that the micro-front-end model must provide and replace future proof of your application by allowing upgrades or future complete rewrites that take up part of the application.

Each micro-front end should be able to be rendered in isolation or container applications. The required data should be loaded by each micro-front end and data waterfalls should be avoided.

Do ✅:

Shared libraries that can be exchanged without affecting other micro-front ends.

Load all required data rendering.

Do not ❌:

There is centralized storage / sharing of data in different micro-front ends.

Share libraries that are actively developed.

Separate code base

Each micro-front end should have its own code base, and the version control chosen should not have any impact on how the project is developed or deployed. It is good to have all projects under a single or single repository.

Do ✅:

Use a single code warehouse monorepos.

Use a single repos.

Each micro-front end should be deployed independently

Each micro-front-end has its own CI / CD pipeline and can be deployed to production without any dependencies of other micro-front-ends. A common anti-pattern that should be avoided is the "deployment queue of hell," where different micro-front ends are so tightly coupled that they need to be deployed in a specific order to avoid breaking the application.

Do ✅:

Has a separate CI / CD pipeline.

Release on demand.

Do not ❌:

There is a release schedule.

Has incremental / sequential deployments that allow previous versions.

Micro front end should be tested independently

Because separate micro-front ends and internal rendering of container applications are required, it makes sense to also test them with integration tests for units and the entire solution.

Do ✅:

There are unit and integration tests for each isolated micro-front-end rendering.

Run the integration test of micro-front-end rendering in the container application as part of the end-to-end test.

The micro-front end should have a version.

When a new micro-front end is deployed to production, the previous version should not be deleted, and the new version should be marked with a semantic version or a similar version number. It is up to the container application to decide which specific micro-front end to use (manage) or always use a specific version of the latest version (Evergreen).

Do ✅:

Use semantic versioning.

Use a specific version or "latest".

Do not ❌:

A global deployment of the changed version is required.

Delete the previous version.

Minimal communication

Communication between micro-front ends should be as small and simple as possible, avoiding as many global states and framework-specific solutions as possible.

If two or more micro-front ends share a large number of messages to provide their minimum functionality, they may be too tightly coupled, and they can share similar and sufficient purposes, that is, they should be considered to integrate them into one.

Do ✅:

Keep the information small and simple.

If possible, avoid stateful and communication frameworks.

Do not ❌:

Shareholder.

There is unnecessary communication.

CSS should be a range

CSS from one micro-front end should not affect other micro-front ends.

Do ✅:

Define the scope for your CSS.

Use CSS-IN-JS or naming libraries (such as CSS modules).

Do not ❌:

Use global CSS.

Final proposal

Do ✅:

Try to create an autonomous team.

Try to arrange a micro-front end around business functions.

Reusability is a good "side effect" rather than a goal.

Do not ❌:

Do not force this architectural style because it is "new".

You don't need multiple JavaScript frameworks.

You do not need a "micro-front-end framework".

The micro front end does not have to be "Micro".

At this point, I believe that everyone on the "micro-front-end implementation method" have a deeper understanding, might as well to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.