CN115686449B - Plug-in architecture design method based on module federation - Google Patents
Plug-in architecture design method based on module federation Download PDFInfo
- Publication number
- CN115686449B CN115686449B CN202211172687.8A CN202211172687A CN115686449B CN 115686449 B CN115686449 B CN 115686449B CN 202211172687 A CN202211172687 A CN 202211172687A CN 115686449 B CN115686449 B CN 115686449B
- Authority
- CN
- China
- Prior art keywords
- plug
- end plug
- ins
- module
- remote
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Stored Programmes (AREA)
Abstract
The invention discloses a plug-in architecture design method based on module federation, which comprises the steps of obtaining a plurality of front-end plug-ins in Web application projects, wherein one front-end plug-in is selected as host from the plurality of front-end plug-ins, the other front-end plug-ins are remote, and the front-end plug-ins comprise a plurality of modules; constructing a shared dependency library according to the Web application project; when the front-end plug-in host is started, the shared dependency library is injected into modules of other front-end plug-ins remote; the modules of the other front-end plug-ins remote for the front-end plug-ins host are exported through the weback configuration file. The invention realizes plug-in architecture design based on module federation, can solve the problem of dependency library sharing, realizes resource sharing, and can make the loading speed of plug-ins faster and the processing logic simpler.
Description
Technical Field
The invention relates to the technical field of software system design, in particular to a plug-in architecture design method based on module federation.
Background
The software system is often oriented to persistent iteration, and it is difficult to clearly know all functions to be supported at the beginning of development, which requires that the software system have a certain expandability. In order to avoid over-design in a system, a plug-in design concept needs to be introduced, which is quite common in web application of toB, the plug-in is not a specific technology, integrates technologies, strategies and methods, even comprises auxiliary tools such as scaffolds, specification constraints and the like, is an implementation scheme of project architecture, and is converted from original single application into a plurality of small front-end plug-ins aggregated into one from the output product.
Iframe is an html-provided tag that can load the content of other web applications, and that is compatible with all browsers, with which any web application you want to load can be loaded. The biggest drawback of iframe is the problem of data state sharing, development efficiency and product experience among the plug-ins. Sharing of data states between the plug-ins is cumbersome, such as sharing of login states between individual plug-ins; the process of reconstructing and reloading the resources of the browser once can be carried out every time the plug-in is switched, and the process is time-consuming.
Qiankun is a technical tool capable of realizing plug-in the true sense, the bottom layer is based on single-spa, the goal of realizing plug-in of most projects can be almost met, and each plug-in can be developed based on any front-end framework irrespective of a technical stack, and has the characteristics of sandbox isolation and resource preloading. However, if qiankun is used to implement the plug-in transformation for the project of the convergence station, there is a problem that all plug-ins of the convergence station are developed based on an angular framework and an anti UI library, and anti itself does not support the advanced one-time introduction of all UI components. The single-spa route reloading mode conflicts with the angular router route reloading mode, so that the problem of incorrect route jump occurs sporadically; the method does not support one-time import in advance, which also determines that all third party libraries based on the angular environment and public libraries realized inside departments cannot be shared, thus necessarily resulting in overlarge packing volume of each plug-in; because the data state interaction of the qiankun is transferred by a bus mode, the method is very troublesome; and moreover, a plurality of logic processes are needed to be carried out at the project entrance to judge whether the project entrance is accessed as a plug-in or exists as a single independent application, so that the problems of complex program flow processing logic and high development and debugging cost are necessarily existed.
Disclosure of Invention
The present invention aims to solve at least one of the technical problems existing in the prior art. Therefore, the invention provides a plug-in architecture design method based on module federation, which can solve the problem of library sharing, realize resource sharing, enable the loading speed of plug-ins to be faster and enable processing logic to be simpler.
In a first aspect, an embodiment of the present invention provides a plug-in architecture design method based on module federation, where the plug-in architecture design method based on module federation includes:
acquiring a plurality of front-end plug-ins in a Web application project, wherein one front-end plug-in the plurality of front-end plug-ins is selected as host, the other front-end plug-ins are remote, and the front-end plug-ins comprise a plurality of modules;
constructing a shared dependency library according to the Web application project;
when the front-end plug-in host is started, the shared dependency library is injected into the modules of the other front-end plug-ins remote;
and exporting a module of the other front-end plugins remote for the front-end plugin host through a weback configuration file.
Compared with the prior art, the first aspect of the invention has the following beneficial effects:
in order to realize resource sharing, the method ensures that the loading speed of the plug-in is faster, the processing logic is simpler, and a plurality of front-end plug-ins in Web application projects are obtained, one front-end plug-in is selected as host from the plurality of front-end plug-ins, other front-end plug-ins are remote, and the front-end plug-ins comprise a plurality of modules; constructing a shared dependency library according to the Web application project; when the front-end plug-in host is started, the shared dependency library is injected into modules of other front-end plug-ins remote; the modules of the other front-end plug-ins remote for the front-end plug-ins host are exported through the weback configuration file. The method realizes plug-in architecture design based on module federation, and can inject the shared dependency library into modules of other front-end plug-ins remote; the module of the other front-end plug-in units remote used by the front-end plug-in unit host is exported through the weback configuration file, so that the problem of dependency library sharing can be solved, resource sharing is realized, the loading speed of the plug-in unit is higher, and processing logic is simpler.
According to some embodiments of the invention, the building a shared dependency library according to the Web application project includes:
according to the Web application project, configuring the alias of a public library of the service related function of each front-end plug-in a tsconfig. Json file of each front-end plug-in;
creating a share-lib.js file to import npm dependent packages under node_modules to be shared among all front-end plugins;
the shared dependency library is constructed from the common library and the npm dependency package.
According to some embodiments of the invention, before the injecting the shared dependency library into the module of the other front-end plug-in remote, the plug-in architecture design method based on module federation further includes:
installing a tool library @ angle-architecture/module-creation capable of realizing plug-in, wherein the tool library generates a configuration file of weback.config.js under the root directory of each front-end plug-in;
and configuring a module corresponding to each front-end plug-in the configuration file of weback.
According to some embodiments of the invention, the injecting the shared dependency library into the module of the other front-end plug-in remote at the front-end plug-in host start-up includes:
defining the shared dependency library in a weback. Config. Js configuration file of each front-end plug-in;
and configuring shared fields in the moduleFeedationPlugin plug-ins in the weback. Config. Js configuration file of each front-end plug-in, and injecting the shared dependency library into modules of the other front-end plug-ins remote through ModuleFederatio nPlugin plug-ins configured with shared fields when the front-end plug-in host is started.
According to some embodiments of the invention, the module for exporting the other front end plug-ins remote for use by the front end plug-in host through a weback profile includes:
and exporting a module of the other front-end plug-ins remote used by the front-end plug-ins host from a moduleFeedationPlugin plug-in a weback.config.js configuration file of each front-end plug-in.
According to some embodiments of the invention, after the module of the other front-end plugin remote for use by the front-end plugin host is exported through a weback configuration file, the plugin architecture design method based on module federation further includes:
configuring paths of modules of the other front-end plug-ins remote in a moduleFeedationPlugin plug-in of a weback.config.js configuration file;
and loading and switching modules from the other front-end plug-ins remote through lazy loading.
According to some embodiments of the invention, after the module from the other front-end plug-in remote is switched by lazy loading, the plug-in architecture design method based on module federation further includes:
taking the service in the regular framework as a data state manager of a front-end plug-in between the cross applications;
and transmitting data among the front-end plug-ins through the service.
In a second aspect, an embodiment of the present invention further provides a pluggable architecture design system based on module federation, the pluggable architecture design system based on module federation includes:
the front-end plug-in acquisition unit is used for acquiring a plurality of front-end plug-ins in the Web application project, wherein one front-end plug-in is selected as host from the plurality of front-end plug-ins, the other front-end plug-ins are remote, and the front-end plug-ins comprise a plurality of modules;
the dependency library construction unit is used for constructing a shared dependency library according to the Web application project;
the dependency library injection unit is used for injecting the shared dependency library into the modules of the other front-end plug-ins remote when the front-end plug-ins host is started;
and the module export unit is used for exporting the modules of the other front-end plugins remote used by the front-end plugins host through the weback configuration file.
It will be appreciated that the advantages of the second aspect compared with the related art are the same as those of the first aspect compared with the related art, and reference may be made to the related description in the first aspect, which is not repeated here.
According to some embodiments of the invention, the dependency library injection unit comprises a shared dependency library definition unit and a field configuration unit, wherein:
a shared dependency library definition unit, configured to define a shared dependency library in a weback. Config. Js configuration file of each front-end plug-in;
the field configuration unit is configured to configure a shared field in a modulefreedservationplug in plug-in a weback.config.js configuration file of each front-end plug-in, and inject the shared dependency library into the modules of the other front-end plug-ins remote through the modulefreedservationplug-in plug-in configured with the shared field when the front-end plug-in host is started.
According to some embodiments of the invention, the plug-in architecture design system based on module federation further comprises a path configuration unit and a lazy loading unit, wherein:
the path configuration unit is used for configuring paths of modules of the other front-end plug-ins remote in a moduleFeedationPlugin plug-in of the weback. Config. Js configuration file;
and the lazy loading unit is used for loading and switching modules from the other front-end plug-ins remote through lazy loading.
Drawings
The foregoing and/or additional aspects and advantages of the invention will become apparent and may be better understood from the following description of embodiments taken in conjunction with the accompanying drawings in which:
FIG. 1 is a flow chart of a plug-in architecture design method based on module federation according to an embodiment of the invention;
FIG. 2 is a flow chart of a plug-in architecture design method based on module federation in accordance with another embodiment of the present invention;
fig. 3 is a block diagram of a plug-in architecture design system based on module federation according to an embodiment of the invention.
Detailed Description
Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to like or similar elements or elements having like or similar functions throughout. The embodiments described below by referring to the drawings are illustrative only and are not to be construed as limiting the invention.
In the description of the present invention, the description of first, second, etc. is for the purpose of distinguishing between technical features only and should not be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated or implicitly indicating the precedence of the technical features indicated.
In the description of the present invention, it should be understood that the direction or positional relationship indicated with respect to the description of the orientation, such as up, down, etc., is based on the direction or positional relationship shown in the drawings, is merely for convenience of describing the present invention and simplifying the description, and does not indicate or imply that the apparatus or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus should not be construed as limiting the present invention.
In the description of the present invention, unless explicitly defined otherwise, terms such as arrangement, installation, connection, etc. should be construed broadly and the specific meaning of the terms in the present invention can be determined reasonably by a person skilled in the art in combination with the specific content of the technical solution.
First, several nouns referred to in this application are parsed:
web application: refers to a web site, a series of pages that can be accessed at a browser through a url address.
Single page application: the traditional website is generally a multi-page application, namely, one url address corresponds to one html file, but the traditional website is basically a single-page application, and the whole website only has one html entry file, but different contents can be presented by clicking a menu, and the url address of a browser can be changed correspondingly.
And (3) routing: in single page application, one url path page loads different contents, the behavior is to configure a route, the domain name of the whole website is the same, but the suffix of the url path is changed along with the different contents of the webpage, and the path suffix except the domain name refers to the route and is divided into a hash route and a history route.
Plug-in: in web applications, the plugin of the back end refers to packaging an interface with a function into an independent jar, and the plugin of the front end refers to an application with a micro front end, so that a front end plugin can be often regarded as a front end plugin or a sub-application (all the front end plugins are described as front end plugins in the following text), and one front end plugin has three largest characteristics: the device can be independently developed, independently packaged and deployed; inter-application isolation (style is not contaminated); independent of the technology stack.
Inter-application communication/cross-application data interactions: when the front-end plug-in data is changed or a user performs certain operation, other front-end plug-ins can be informed of changing states; for example, after the user logs in, all front-end plug-ins can acquire the data states of the token and the user after logging in.
Dependency library: a front-end project does not say that all functional points are developed from zero, and can rely on and introduce npm packages of open sources which are realized by some others; in addition, some repeated business codes are extracted into a common library inside the project group, and both cases are called dependent libraries.
Alias name: defining repeated business codes individually to a common library, giving an entry file a simple name called alias, the items based on the angular framework are developed by typescript language, and the alias can be configured by tsconfig.
The software system is often oriented to persistent iteration, and it is difficult to clearly know all functions to be supported at the beginning of development, which requires that the software system have a certain expandability. In order to avoid over-design in a system, a plug-in design concept needs to be introduced, which is quite common in web application of toB, the plug-in is not a specific technology, integrates technologies, strategies and methods, even comprises auxiliary tools such as scaffolds, specification constraints and the like, is an implementation scheme of project architecture, and is converted from original single application into a plurality of small front-end plug-ins aggregated into one from the output product.
Iframe is an html-provided tag that can load the content of other web applications, and that is compatible with all browsers, with which any web application you want to load can be loaded. The biggest drawback of iframe is the problem of data state sharing, development efficiency and product experience among the plug-ins. Sharing of data states between the plug-ins is cumbersome, such as sharing of login states between individual plug-ins; the process of reconstructing and reloading the resources of the browser once can be carried out every time the plug-in is switched, and the process is time-consuming.
Qiankun is a technical tool capable of realizing plug-in the true sense, the bottom layer is based on single-spa, the goal of realizing plug-in of most projects can be almost met, and each plug-in can be developed based on any front-end framework irrespective of a technical stack, and has the characteristics of sandbox isolation and resource preloading. However, if qiankun is used to implement the plug-in transformation for the project of the convergence station, there is a problem that all plug-ins of the convergence station are developed based on an angular framework and an anti UI library, and anti itself does not support the advanced one-time introduction of all UI components. The single-spa route reloading mode conflicts with the angular router route reloading mode, so that the problem of incorrect route jump occurs sporadically; the method does not support one-time import in advance, which also determines that all third party libraries based on the angular environment and public libraries realized inside departments cannot be shared, thus necessarily resulting in overlarge packing volume of each plug-in; because the data state interaction of the qiankun is transferred by a bus mode, the method is very troublesome; and moreover, a plurality of logic processes are needed to be carried out at the project entrance to judge whether the project entrance is accessed as a plug-in or exists as a single independent application, so that the problems of complex program flow processing logic and high development and debugging cost are necessarily existed.
In order to solve the problems, in order to realize resource sharing, the invention makes the loading speed of the plug-in faster and the processing logic simpler, and the front-end plug-in comprises a plurality of modules by acquiring a plurality of front-end plug-ins in the Web application project and selecting one front-end plug-in as host and other front-end plug-ins as remote; constructing a shared dependency library according to the Web application project; when the front-end plug-in host is started, the shared dependency library is injected into modules of other front-end plug-ins remote; the modules of the other front-end plug-ins remote for the front-end plug-ins host are exported through the weback configuration file. The invention realizes plug-in architecture design based on module federation, and can inject the shared dependency library into modules of other front-end plug-ins remote; the module of the other front-end plug-in units remote used by the front-end plug-in unit host is exported through the weback configuration file, so that the problem of dependency library sharing can be solved, resource sharing is realized, the loading speed of the plug-in unit is higher, and processing logic is simpler.
Referring to fig. 1, an embodiment of the present invention provides a plug-in architecture design method based on module federation, where the plug-in architecture design method based on module federation includes, but is not limited to, steps S100 to S400:
step S100, a plurality of front-end plug-ins in a Web application project are obtained, one front-end plug-in is selected as host from the plurality of front-end plug-ins, other front-end plug-ins are remote, and the front-end plug-ins comprise a plurality of modules;
step S300, when the front-end plug-in host is started, the shared dependency library is injected into modules of other front-end plug-ins remote;
step S400, a module of other front-end plug-ins remote for the front-end plug-in host is exported through the weback configuration file.
In steps S100 to S400 of some embodiments, in order to implement resource sharing, to make the loading speed of the plugin faster, the processing logic is simpler, by acquiring multiple front-end plugins in the Web application project, and selecting one front-end plugin as host from the multiple front-end plugins, and other front-end plugins as remote, where the front-end plugins include multiple modules; constructing a shared dependency library according to the Web application project; when the front-end plug-in host is started, the shared dependency library is injected into modules of other front-end plug-ins remote; the modules of the other front-end plug-ins remote for the front-end plug-ins host are exported through the weback configuration file. The invention realizes plug-in architecture design based on module federation, and can inject the shared dependency library into modules of other front-end plug-ins remote; the module of the other front-end plug-in units remote used by the front-end plug-in unit host is exported through the weback configuration file, so that the problem of dependency library sharing can be solved, resource sharing is realized, the loading speed of the plug-in unit is higher, and processing logic is simpler.
In some embodiments, building a shared dependency library from Web application projects includes:
according to the Web application project, configuring the alias of the public library of the service related function of each front-end plug-in the tsconfig. Json file of each front-end plug-in;
creating a share-lib.js file to import npm dependent packages under node_modules to be shared among all front-end plugins;
a shared dependency library is constructed from the common library and the npm dependency package.
In some embodiments, the plug-in architecture design method based on module federation further includes, before injecting the shared dependency library into the modules of the other front-end plug-ins remote:
installing a tool library @ angle-architecture/module-creation capable of realizing plug-in, wherein the tool library generates a configuration file of weback.config.js under the root directory of each front-end plug-in;
and configuring a corresponding module of each front-end plug-in a configuration file of weback.
In some embodiments, at the front-end plug-in host start-up, injecting the shared dependency library into the modules of other front-end plug-ins remote includes:
defining a shared dependency library in a weback. Config. Js configuration file of each front-end plug-in;
and configuring shared fields in the moduleFeedationPlugin plug-ins in the weback.config.js configuration file of each front-end plug-in, and injecting the shared dependency library into modules of other front-end plug-ins remote through the moduleFeedationPlugin plug-ins with the shared fields when the front-end plug-in host is started.
In some embodiments, the module for exporting other front end plug-ins remote for use by the front end plug-in host through the weback profile includes:
the modules of the other front end plug-ins remote for use by the front end plug-ins host are exported in the moduleFeedationPlugin plug-ins in the weback. Config. Js configuration file of each front end plug-in.
In some embodiments, after the module of the other front-end plugin remote for front-end plugin host is exported by the weback configuration file, the plugin architecture design method based on module federation further includes:
configuring paths of modules of other front-end plug-ins remote in a moduleFeedationPlugin plug-in of a weback.config.js configuration file;
the modules from the other front-end plug-ins remote are switched by lazy loading.
In some embodiments, after the module from the other front-end plug-in remote is switched by lazy loading, the plug-in architecture design method based on module federation further includes:
taking the services in the regular framework as a data state manager of a front-end plugin between the cross-applications;
and data transmission is carried out among the front-end plug-ins through the service.
It should be noted that, in this embodiment, the Web application plug-in architecture design is implemented based on an angular framework, and the method steps in this embodiment may be modified according to actual needs to adapt to the plug-in architecture design of other frameworks, for example, a react/vue framework, but the design conception method in this embodiment is not changed.
For ease of understanding by those skilled in the art, a set of preferred embodiments are provided below:
the plug-in architecture design described in this embodiment is developed based on the product business background of the converged message management platform, which is a middle project for providing a unified docking port of multiple message channels for the business platform of an enterprise, and integrates many functional modules, such as message sending, sending record management, automatic reply configuration, sensitive word configuration, etc., where each functional module is applicable to multiple message channels (WeChat, SMS, 5G, etc.).
The plug-in architecture design of the present embodiment is implemented based on module federation of weback 5, and by referencing the tool library @ angular-architecture/module-feature, the processing logic in terms of weback configuration and routing configuration can be simplified.
Referring to fig. 2, a plurality of front-end plugins in a Web application project are acquired, one plugin in the Web application project corresponds to a micro application, one front-end plugin is selected as a host from the plurality of front-end plugins, the other front-end plugins are remote, and the front-end plugins comprise a plurality of modules. In the converged communication platform project, any front-end plug-in is selected from the service perspective as host, and other front-end plug-ins are selected as remote. host is responsible for login authorization, routing configuration, interface interception, and basic functions related to user and role, while other functional plug-ins export corresponding modules for host use. The method comprises the following steps:
acquiring a plurality of front-end plug-ins in a Web application project, wherein one front-end plug-in the plurality of front-end plug-ins is selected as host, the other front-end plug-ins are remote, and the front-end plug-ins comprise a plurality of modules; constructing a shared dependency library according to the Web application project; when the front-end plug-in host starts, the shared dependency library is injected into modules of other front-end plug-ins remote. The shared dependency library includes npm packages from node_modules and common libraries associated with business functions, such as message type channel component libraries. According to the remote configuration in the weback, the required module code is obtained from the remote service, namely, the modules of other front-end plug-ins remote for the front-end plug-ins host to use are exported through the weback configuration file by injecting the shared dependency library into the modules of the other front-end plug-ins remote.
Implementing the plug-in architecture of web applications under the module federation scheme mainly involves the configuration of scaffolding weback and the configuration of routing lazy loads.
(1) The tsconfig.json file of each front-end plug-in is configured with the alias of the public library related to the business function of the front-end plug-in, e.g., the alias of the message type component dependent library.
Note that, in this embodiment, the alias of the public library related to the service function may be configured according to actual needs, and this embodiment is not limited specifically.
(2) A share-lib.js file is created to import npm dependent packages under node_modules that need to be shared between all front-end plug-ins. The format is as follows: generally, three classes are included: the @ angle/related dependency packages, UI library related dependency packages, other tool dependency packages (echartits/rxjs, etc.), single represents a single instance, and there is no requirement for version numbers.
(3) The tool library @ angle-architecture/module-creation, which can implement plugin, is installed, and automatically generates a configuration file of weback. And configuring a corresponding module of each front-end plug-in a configuration file of weback.
(4) The dependency library related to the service function is defined in the weback. Config. Js configuration file of all front-end plugins, for example, the message type component library is defined.
It should be noted that, in this embodiment, the dependency library related to the service function may be configured according to actual needs, and this embodiment is not limited specifically.
(5) Configuring shared fields, namely shared dependency libraries, including npm dependency libraries under node_modules, and dependency libraries related to service functions, in the moduleFeedationPlugin plug-ins in weback.config.js configuration files of all front-end plug-ins; and the shared dependency library is injected into modules of other front-end plug-ins remote through a moduleFeedationPlugin plug-in configured with shared fields.
(6) As a front-end plug-in of remote, a module of another front-end plug-in remote for injecting the shared dependency library for host needs to be exported in a weback. Config. Js configuration file of each front-end plug-in, and the export format is as follows: designating the name of the front-end plug-in, and deriving the name of the module and the path of the corresponding module. For example, a control name of the front-end plug-in, a module name of deriving the module name exposed to host/Sencon, and a path corresponding to the module name/Sencon are defined.
(7) In the front-end plug-in as host, paths of modules requiring the introduction of other front-end plug-ins remote need to be configured in the moduleFeedationPlugin plug-in of the weback.
(8) In the routing configuration file of the front-end plug-in as host, the modules switching from the other front-end plug-ins are loaded in the form of routing lazy loading.
In an angular environment, taking a service in an angular framework as a data state manager of a front-end plugin between the cross-applications; and data transmission is carried out among the front-end plug-ins through the service. In this embodiment, a service may act as a cross-component data state manager, in module federation-based front-end plug-in system, the service is still a data state manager that spans components between applications, as the services in the dependency library are shared and single instance objects.
It should be noted that, the module federation of weback 5 in this embodiment is not limited to any front-end framework as a technical support for implementing the web application plug-in architecture design in the angular framework, and, for example, the react/vue front-end framework may implement plug-in using module federation technology, but the steps in this embodiment are applicable to projects developed based on the angular framework.
For better illustration, the experimental analysis was performed in the browser in this embodiment, and the following conclusion was drawn:
1. the embodiment solves the problem of sharing the dependency library between the plugins, and the effect can be seen from the following three aspects:
firstly, opening a plug-in web application realized by the technical scheme of the embodiment in a browser, opening a developer tool by a right key, and clearly seeing that a dependency library in the embodiment is loaded firstly, clicking a menu to switch a route, and correspondingly loading only module codes of required service related functions, wherein the dependency library among plug-ins is indicated to be shared and not packaged into the service codes of each front-end plug-in;
secondly, from the aspect of the size of the packaged code, the total volume of the packaged sizes of all plugins in the platform project in fusion communication is 600M by using the plugin realized by using the qiankun, and the packaged sizes of all plugins are 200M by using the technical scheme of the embodiment, so that the original size is reduced to one third, and the fact that no repeated dependency library code is packaged into the service code of each front-end plugin is also explained;
thirdly, after the route is switched, from the loading time of the browser, the original page loading time is more than eight hundred milliseconds, and is more than eighty milliseconds, and the time is almost reduced to one tenth of the original time, which also shows that the dependency library is shared, so that when the front-end plug-in is switched, only the service code of the page needs to be loaded, the volume is much smaller than the original volume, and the loading speed is naturally much faster.
2. The technical scheme of the embodiment is much simpler than the qiankun technical scheme which is mainstream in the market, and the logic judgment of whether the web application plugin is accessed as a plugin or is independently deployed is added at a plurality of places in each front-end plugin. But also relies on some external tool library (e.g., system) to implement, the overall main flow logic and scaffold configuration is complex. The technical scheme of realizing plug-in based on module federation in the embodiment is that the bottom layer of the angular-cli scaffold is developed based on weback 5, and has the function, and does not need to rely on an external tool library. The state interaction between the plug-ins is easier, and the interaction is not needed in a bus mode. Overall, it is more friendly and easier to understand for the developer.
3. A smoother path is paved for the later project framework upgrading, and because the single-spa route reloading mode collides with the regular router route reloading mode, the source code packet needs to be patched, so that the framework upgrading is very unfavorable, but the embodiment is based on the module federation plug-in technology, and because the plug-in is not based on the difference of route paths in the internal principle, the framework upgrading is facilitated.
Therefore, the embodiment can solve the problem of dependency library sharing, so that the code packaging volume is smaller, the loading speed of the plug-in is faster, the processing logic is simpler, and the overall performance is greatly improved. And module federation as a core technology for plugin, implementation of plugin includes a number of aspects. The method comprises the steps of organizing and managing a plurality of plug-ins in projects, managing multiple applications by using an angular-cli scaffold based on projects developed by an angular framework, namely, creating a plurality of front-end plug-ins under a large project catalog, wherein the plurality of plug-ins are required to be managed by a team, and node_modules, project configuration, resource files and the like among the plug-ins can be shared.
Referring to fig. 3, the embodiment of the present invention further provides a plug-in architecture design system based on module federation, which includes a front-end plug-in acquisition unit 100, a dependency library construction unit 200, a dependency library injection unit 300, and a module export unit 400, wherein:
the front-end plug-in acquisition unit 100 is configured to acquire a plurality of front-end plug-ins in a Web application project, and select one front-end plug-in as host from the plurality of front-end plug-ins, and the other front-end plug-ins as remote, where the front-end plug-ins include a plurality of modules;
a dependency library construction unit 200 for constructing a shared dependency library according to Web application items;
the dependency library injection unit 300 is configured to inject the shared dependency library into a module of another front-end plug-in remote when the front-end plug-in host is started;
the module exporting unit 400 is configured to export, through the weback configuration file, a module of another front-end plug-in remote for use by the front-end plug-in host.
It should be noted that, since a plug-in architecture design system based on module federation and a plug-in architecture design method based on module federation in the present embodiment are based on the same inventive concept, the corresponding content in the method embodiment is also applicable to the system embodiment, and will not be described in detail herein.
In some embodiments, the dependency library injection unit comprises a shared dependency library definition unit and a field configuration unit, wherein:
a shared dependency library definition unit, configured to define a shared dependency library in a weback. Config. Js configuration file of each front-end plug-in;
the field configuration unit is used for configuring shared fields in the moduleFeedationPlugin plug-ins in the weback. Config. Js configuration file of each front-end plug-in, and injecting the shared dependency library into modules of other front-end plug-ins remote through the moduleFeedationPlugin plug-ins configured with the shared fields when the front-end plug-in host is started.
In some embodiments, the module federation-based plug-in architecture design system further comprises a path configuration unit and a lazy loading unit, wherein:
the path configuration unit is used for configuring paths of modules of other front-end plug-ins remote in the moduleFeedationPlugin plug-ins of the weback. Config. Js configuration file;
and the lazy loading unit is used for loading and switching modules from other front-end plug-ins remote through lazy loading.
The embodiments of the present invention have been described in detail with reference to the accompanying drawings, but the present invention is not limited to the above embodiments, and various changes can be made within the knowledge of one of ordinary skill in the art without departing from the spirit of the present invention.
Claims (6)
1. A plug-in architecture design method based on module federation, which is characterized in that the plug-in architecture design method based on module federation comprises the following steps:
acquiring a plurality of front-end plug-ins in a Web application project, wherein one front-end plug-in the front-end plug-ins is selected as host, the other front-end plug-ins are remote, and the front-end plug-ins comprise a plurality of modules;
constructing a shared dependency library according to the Web application project; the method comprises the following steps:
according to the Web application project, configuring the alias of a public library of the service related function of each front-end plug-in a tsconfig. Json file of each front-end plug-in;
creating a share-lib.js file to import npm dependent packages under node_modules to be shared among all front-end plugins;
constructing the shared dependency library according to the public library and the npm dependency package;
installing a tool library @ angle-architecture/module-creation capable of realizing plug-in, wherein the tool library generates a configuration file of weback.config.js under the root directory of each front-end plug-in;
configuring a module corresponding to each front-end plug-in the configuration file of weback. Config. Js according to the Web application project;
when the front-end plug-in host is started, the shared dependency library is injected into the modules of the other front-end plug-ins remote; the method comprises the following steps:
defining the shared dependency library in a weback. Config. Js configuration file of each front-end plug-in;
configuring shared fields in a moduleFeedationPlugin plug-in a weback.config.js configuration file of each front-end plug-in, and injecting the shared dependency library into modules of other front-end plug-ins remote through ModuleFederatio nPlugin plug-ins configured with shared fields when the front-end plug-in host is started;
and exporting a module of the other front-end plugins remote for the front-end plugin host through a weback configuration file.
2. The plug-in architecture design method based on module federation of claim 1, wherein the deriving the module of the other front-end plug-ins remote for use by the front-end plug-in host from a weback profile comprises:
and exporting modules of other front-end plug-ins remote used by the front-end plug-ins host from the moduleFeedationPlugin plug-ins in the weback.config.js configuration file of each front-end plug-in.
3. The plug-in architecture design method based on module federation of claim 1, wherein after the deriving the modules of the other front-end plug-ins remote for use by the front-end plug-in host from a weback profile, the plug-in architecture design method based on module federation further comprises:
configuring paths of modules of the other front-end plug-ins remote in a moduleFeedationPlugin plug-in of a weback.config.js configuration file;
and loading and switching modules from the other front-end plug-ins remote through lazy loading.
4. The plug-in architecture design method based on module federation of claim 3, wherein after said loading the module from the other front-end plug-in remote by lazy loading, said plug-in architecture design method based on modul e federation further comprises:
taking the services in the regular framework as a data state manager of a front-end plugin between the cross-applications;
and transmitting data among the front-end plug-ins through the service.
5. A plug-in architecture design system based on module federation, the plug-in architecture design system based on module federation comprising:
the front-end plug-in acquisition unit is used for acquiring a plurality of front-end plug-ins in the Web application project, wherein one front-end plug-in is selected as host from the plurality of front-end plug-ins, the other front-end plug-ins are remote, and the front-end plug-ins comprise a plurality of modules;
the dependency library construction unit is used for constructing a shared dependency library according to the Web application project; the method comprises the following steps:
according to the Web application project, configuring the alias of a public library of the service related function of each front-end plug-in a tsconfig. Json file of each front-end plug-in;
creating a share-lib.js file to import npm dependent packages under node_modules to be shared among all front-end plugins;
constructing the shared dependency library according to the public library and the npm dependency package;
the module configuration unit is used for installing a tool library @ angular-architecture/module-implementation capable of realizing plug-in, the tool library generates a configuration file of weback.config.js under the root directory of each front-end plug-in, and a module corresponding to each front-end plug-in is configured in the configuration file of weback.config.js according to the Web application project;
the dependency library injection unit is used for injecting the shared dependency library into the modules of the other front-end plug-ins remote when the front-end plug-ins host is started; the method comprises the following steps:
defining the shared dependency library in a weback. Config. Js configuration file of each front-end plug-in;
configuring shared fields in a moduleFeedationPlugin plug-in a weback.config.js configuration file of each front-end plug-in, and injecting the shared dependency library into modules of other front-end plug-ins remote through ModuleFederatio nPlugin plug-ins configured with shared fields when the front-end plug-in host is started;
and the module export unit is used for exporting the modules of the other front-end plugins remote used by the front-end plugins host through the weback configuration file.
6. The pluggable architecture design system based on module federation of claim 5, wherein the pluggable architecture design system based on module federation further comprises a path configuration unit and a lazy loading unit, wherein:
the path configuration unit is used for configuring paths of modules of the other front-end plug-ins remote in a moduleFeedationPlugin plug-in of the weback. Config. Js configuration file;
and the lazy loading unit is used for loading and switching modules from the other front-end plug-ins remote through lazy loading.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211172687.8A CN115686449B (en) | 2022-09-26 | 2022-09-26 | Plug-in architecture design method based on module federation |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211172687.8A CN115686449B (en) | 2022-09-26 | 2022-09-26 | Plug-in architecture design method based on module federation |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115686449A CN115686449A (en) | 2023-02-03 |
| CN115686449B true CN115686449B (en) | 2023-06-02 |
Family
ID=85063178
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211172687.8A Active CN115686449B (en) | 2022-09-26 | 2022-09-26 | Plug-in architecture design method based on module federation |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115686449B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111427558A (en) * | 2020-04-10 | 2020-07-17 | 创盛视联数码科技（北京）有限公司 | Method for customizing front-end automatic development environment based on webpack |
| CN114860228A (en) * | 2022-05-18 | 2022-08-05 | 杭州指令集智能科技有限公司 | Module centralization sharing system realized based on Module Federation technology |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10095499B2 (en) * | 2016-09-16 | 2018-10-09 | Microsoft Technology Licensing, Llc | Optimization for multi-project package manager |
-
2022
- 2022-09-26 CN CN202211172687.8A patent/CN115686449B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111427558A (en) * | 2020-04-10 | 2020-07-17 | 创盛视联数码科技（北京）有限公司 | Method for customizing front-end automatic development environment based on webpack |
| CN114860228A (en) * | 2022-05-18 | 2022-08-05 | 杭州指令集智能科技有限公司 | Module centralization sharing system realized based on Module Federation technology |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115686449A (en) | 2023-02-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110324169B (en) | Interface management method and device | |
| US9104506B2 (en) | Assembly and deployment of multi-platform flow-based applications | |
| WO2022135178A1 (en) | Micro-frontend system, sub-application loading method, electronic device, computer program product, and computer readable storage medium | |
| WO2014146198A1 (en) | Systems and methods for intercepting, processing, and protecting user data through web application pattern detection | |
| Späth et al. | {SoK}:{XML} parser vulnerabilities | |
| Sewell et al. | Secure composition of untrusted code: Wrappers and causality types | |
| CN115686449B (en) | Plug-in architecture design method based on module federation | |
| US20070192704A1 (en) | Method, apparatus and computer program product for port configuration of resources in a virtual topology | |
| CN112799652A (en) | Client construction method and device, electronic equipment and storage medium | |
| Ortega | Mastering Python for Networking and Security: Leverage Python scripts and libraries to overcome networking and security issues | |
| CN113434217B (en) | Vulnerability scanning method, vulnerability scanning device, computer equipment and medium | |
| Zuzak et al. | A classification framework for web browser cross-context communication | |
| Paronen | A web-based monitoring system for the Industrial Internet | |
| Cisco | Task 2-- Exploring SNMP Capabilities by Using UCD-SNMP | |
| CN114662022A (en) | Application isolation method and device | |
| KR101674543B1 (en) | System and Method for Improving content Layer in protocol | |
| Jadidi et al. | Capexec: Towards transparently-sandboxed services (extended version) | |
| Trapp et al. | Automatic source code decomposition for privilege separation | |
| Novák | Simulation of network structures | |
| CN114816579B (en) | SaaS chemical industrial APP access method based on industrial Internet platform | |
| CN113961376A (en) | Message middleware switching method and device | |
| US11526600B2 (en) | Taint tracking via non-intrusive bytecode instrumentation | |
| CN114610409A (en) | Webpack-based calling system and method and electronic device | |
| CN117707521A (en) | Micro front-end resource utilization method, device, equipment and storage medium | |
| Park et al. | Java-based network management environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |