preface
The concept of microservices is mature in back-end development. With the help of microservices, multiple independent services can be better coupled to improve performance and stability of each other. With the development of these two years ago, the concept of a micro front end is also in full swing in the development of the front end, but why do we use a micro front end
Microservices are a variant of service-oriented architecture (SOA) that designs applications as a series of loosely coupled, fine-grained services organized by lightweight communication protocols
Specifically, build the application as a set of small services. Each of these services can be deployed and extended independently, with solid modular boundaries that allow different services to be written in different programming languages and managed by different teams
Why use a micro front end
Advantages of the micro front end:
- Independent technology stack: The main framework does not limit the number of technology stacks to access applications, and the selection of technology stacks for each application can be coordinated with the business team
- Independent development and deployment: The sub-application repository is independent, and the front and back ends can be independently developed. After deployment, the main framework synchronously updates the sub-applications
- Run independently: Each child application is isolated from each other. Failure of a single child application does not affect other projects
- Data sharing: A child application can share the data of its master application or sibling application
OMG, what are you waiting for
But in reality, the architecture of a project needs to consider not only advantages, but also disadvantages.
Disadvantages of the micro front-end:
- Does the technical team have the ability to fully understand the new architecture
- Independent module Applications are deployed independently
- Access to multiple technology stacks
- Address style isolation and generality, data isolation and communication between multiple applications
- Does the multi-team development work well together
- Whether the business is so centralized that it needs to be split into separate businesses
- Without coupling or being too small, microservices can be a burden
- Does the team have multiple technology stacks that cannot be unified
- There is no uniform technology stack, project base style, and architecture differences
- Project management handover will be difficult
- Overall research and development costs have increased
Most small and medium sized companies, without a strong technical pursuit, do not have a pressing need to introduce a micro front end, creating an additional burden
After all, architecture without actual business support is just a piece of paper and cannot be promoted
So should you introduce a micro front end to your project?
When do you need to introduce a micro front end
- The project technology stack is too old, there are few developers with relevant skills, it is difficult to expand functions, and the cost of reconstruction and maintenance is high.
Split the project through microservice separation, and gradually reconstruct, rewrite, and iterate late functions
- The project is too large, the efficiency of development and deployment is low, and problems occur, resulting in a global crash, which is difficult to maintain
- There are different technology stacks in the project team, but they need to be connected to the same main system
Implementation of micro front end
To put it simply, microservice is to split a large integrated Bundle into multiple sub-bundles, and then load each sub-bundle through the parent container to achieve the desired unpacking effect
Bundle integration
Build-time integration
- Distribute NPM packages for sub-applications separately, in the form of dependency packages, into the main project
- Git submodule is used to introduce the main project
The biggest problem with build-time integration is that it causes coupling at the release stage. Every change in a sub-version will result in the entire project having to be recompiled and built, which is not a priority for energy efficiency.
Runtime integration
The iframe reference
Advantages: Iframe is inherently styled and data isolated
Disadvantages: Native isolation means that it is difficult to link the various parts of the application together. Routing control, history stack management, deep-linking, responsive layout, etc., become extremely complex, which limits the flexibility of iframe solutions
The old pot of new wine, or very useful, in the super complicated and very short time, straight into the duck, don’t hesitate
Route + JS bundle
- We use Single — Spa + SystemJS built microservices, please see how our micro front-end is refined.
- Umijs + Qiankun Ecosystem is good, there are many blog posts in the nuggets, react technology stack can be considered
Web Components
Each child application is encapsulated as a custom HTML element (rather than a rendering function in a front-end routing scheme) to gain the style isolation benefits of Shadow DOM
Write in the last
This article is just for the use of micro-service in the actual project to do some simple discussion, the concept of the article is their own in the actual use of some feelings and experience, welcome to leave a message to discuss
One final piece of advice for your Devops series
The backend module
- DevOps – Gitlab Api usage (completed, click to jump)
- The conversation – build enterprise foundation platform Basic platform building last | foundation platform structures, medium-length | foundation platform set up next
- DevOps – Gitlab CI pipeline construction
- Devops-jenkins pipelined construction
- Devops-docker use
- DevOps – Release task flow design
- DevOps – Code review points
- Devops-node monitors service quality
The front-end module
- DevOps – H5 base scaffolding Build projects at warp speed
- Devops-react project development