Micro-front-end base resource processing method, system and equipment

By downloading and storing micro front-end application data in parallel and batch storage, the problem of repeated download of micro front-end base resources is solved, data download efficiency and user experience are improved, and network bandwidth consumption and server load are reduced.

CN119232716APending Publication Date: 2024-12-31广域铭岛数字科技有限公司 +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411293611.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-09-14
Publication Date
2024-12-31

AI Technical Summary

Technical Problem

When the micro front-end base processes resources, there is a phenomenon of repeatedly downloading the micro front-end application resources, resulting in waste of network bandwidth and reduced rendering speed.

Method used

By creating multi-threaded resource download threads to download each application data in parallel, and store the data in batches to different data tables of the front-end database. If application activation is detected, resource acquisition requests will be sent to the front-end and back-end databases respectively, using first come first-use The policy terminates the request from another database to avoid duplicate loading.

Benefits of technology

It improves data download efficiency, reduces response time, realizes classified management and efficient access of data, ensures rapid response and loading of application resources, reduces unnecessary resource loading and server load, and improves user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119232716A_ABST
    Figure CN119232716A_ABST
Patent Text Reader

Abstract

The invention relates to the field of micro-front-end development, and discloses a micro-front-end base resource processing method, system and equipment. The method comprises the steps of determining to-be-downloaded application data in response to an application table, and creating a multi-thread resource downloading thread to download the application data in parallel; after downloading, storing the application data in different data tables of a front-end database in batches; if it is monitored that any application is activated, the resource management thread sends a resource obtaining request to the front-end database and the rear-end database, and the resource obtaining request comprises obtaining all resources of any application; if it is monitored that all the resources of any database are obtained firstly, the resource obtaining request of the other database is terminated, all the obtained resources are analyzed to render the application, quick response and loading of the application resources are ensured, repeated loading and waste of the resources are avoided, and the resource rendering efficiency is improved. And the load of the server and the consumption of network bandwidth are also reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of micro-front-end development, and in particular to a micro-front-end base resource processing method, system and device. Background Art

[0002] Micro frontend is a technical solution that splits a large monolithic frontend application into multiple small, independently deployable frontend applications. Similar to the microservice architecture, micro frontend transforms a single-page frontend application from a single monolithic application to an application that aggregates multiple small frontend applications. Each frontend application can be developed and deployed independently, and at the same time, it can also be developed in parallel while sharing components.

[0003] However, when the micro-frontend base processes resources, when it comes to resource acquisition, storage, and loading, there is often a phenomenon of repeated downloading of micro-frontend sub-application resources, which not only wastes network bandwidth, but also reduces the rendering speed of the sub-application. Summary of the invention

[0004] In view of the shortcomings of the prior art mentioned above, the present application discloses a micro-front-end base resource processing method, system and device, which are used to solve the problem of repeated downloading and poor rendering of application resources obtained by the above-mentioned micro-front-end base.

[0005] The first aspect of the present application discloses a method for processing resources of a micro-front-end base, comprising: in response to an application table determining each application data to be downloaded, creating a resource download thread to download each application data in parallel, wherein the application table is configured for the micro-front-end base; after downloading, storing each application data in batches to different data tables of a front-end database; if it is detected that any of the applications is activated, the resource management thread sends a resource acquisition request to the front-end database and the back-end database respectively, and the resource acquisition request includes acquiring all resources of any of the applications; if it is detected that all resources of any database are acquired first, the resource acquisition request of the other database is terminated, and all acquired resources are parsed to render the application.

[0006] In certain embodiments of the first aspect of the present application, before determining the application data to be downloaded in response to the application table, it also includes: opening the micro-front-end base to determine whether the micro-front-end base has the front-end database; if it exists, linking the front-end database; if it does not exist, creating the front-end database; in response to the table creation instruction of the micro-front-end base, creating the application table according to the application name of the table creation instruction, the application table carries basic application information, and each of the applications has a corresponding data table.

[0007] In certain embodiments of the first aspect of the present application, before each of the application data is stored in batches in different data tables of the front-end database, it also includes: releasing the thread corresponding to the application data after downloading according to the state of the thread, and cleaning up threads with abnormal states, generating storage events for batch storage in the front-end database, and sending each of the application data to the micro-front-end base; in response to the storage event, sending the received each of the application data to the front-end database for batch storage.

[0008] In certain embodiments of the first aspect of the present application, a resource download thread is created to download each of the application data in parallel, including: creating a multi-threaded resource download thread, configuring the application download priority and download quantity rules of the resource download thread, wherein the application download priorities are, from high to low, new applications, version updated applications, and applications for which resources have not been downloaded, and the download quantity rules determine the number of application downloads due to differences in the number of threads and parallel numbers of different platforms; determining the target application based on the application data carried by the application table and the download quantity rules; determining the download order of the target application based on the application download priority, and downloading each of the application data in parallel through one application in turn using one resource download thread according to the download order.

[0009] In certain embodiments of the first aspect of the present application, if it is monitored that any of the applications is activated, the resource management thread sends resource acquisition requests to the front-end database and the back-end database respectively, including: in response to the application activation request, starting the corresponding application and determining the activation status of the application, the application activation request including unique identification information of the application to be activated; determining the activated application based on the activation status of the application and the identification information; based on the activated application, the resource management thread sends a first resource acquisition request to the front-end database and a second resource acquisition request to the back-end database, and the first resource acquisition request and the second resource acquisition request both include the identification information of the activated application.

[0010] In certain embodiments of the first aspect of the present application, if the monitoring first obtains all resources from any database, the resource acquisition request of the other database is terminated, and all acquired resources are parsed to render the application, including: real-time monitoring of the response information of the resource acquisition request of any of the applications, the response information including all resources of any of the applications; if the monitoring first obtains all resources from the front-end database, the resource acquisition request of the back-end database is terminated, and all resources of any current application are parsed to render the application; or if the monitoring first obtains all resources from the back-end database, the resource acquisition request of the front-end database is terminated, and all resources of any current application are parsed to render the application.

[0011] In certain embodiments of the first aspect of the present application, parsing all acquired resources to render the application also includes: performing resource loading operations and parsing operations, and storing the parsed resources in a cache; confirming the application to be rendered, acquiring the resources to be rendered required by the application to be rendered from the cache, and rendering the resources to be rendered to the application to be rendered; and executing business logic code in response to the application.

[0012] In certain embodiments of the first aspect of the present application, after each of the application data is stored in batches in different data tables of the front-end database, it also includes: if it is monitored that the cached application resources in the front-end database reach a preset data volume, then the application cache order of the applications stored in the front-end database is determined; for each of the applications cached in the front-end database, a portion of the application resources cached first is cleared according to the application cache order to release the cache space of the application resources.

[0013] The second aspect of the present application discloses a micro-front-end base resource processing system, including: an application download module, which is used to determine the application data to be downloaded in response to an application table, create a resource download thread and download each application data in parallel, wherein the application table is configured for the micro-front-end base; a batch storage module, which is used to batch store each application data to different data tables of the front-end database after downloading; a resource acquisition module, which is used to enable the resource management thread to send a resource acquisition request to the front-end database and the back-end database respectively if it is monitored that any of the applications is activated, and the resource acquisition request includes acquiring all resources of any of the applications; a resource processing module, which is used to terminate the resource acquisition request of the other database if it is monitored that all resources of any database are acquired first, and parse all acquired resources to render the application.

[0014] The third aspect of the present application discloses an electronic device, comprising: a processor and a memory; the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the electronic device executes the above method.

[0015] The beneficial effects of the present application are as follows: by creating a multi-threaded resource download thread to download each of the application data in parallel, each of the application data is stored in batches in different data tables of the front-end database; if any of the applications is detected to be activated, the resource management thread sends a resource acquisition request to the front-end database and the back-end database respectively, and the resource acquisition request includes acquiring all resources of any of the applications; if all resources of any database are acquired first, the resource acquisition request of the other database is terminated, and all acquired resources are parsed to render the application. In this way, on the one hand, the efficiency of data download is improved and the response time is reduced through multi-threaded downloading; on the other hand, the downloaded application data is stored in batches in different data tables of the front-end database, realizing classified management and efficient access of data; on the other hand, the front-end and back-end acquisition strategies ensure the rapid response and loading of application resources, while reducing unnecessary resource loading and improving user experience; in addition, the first-come-first-served strategy is adopted to avoid repeated loading and waste of resources, and also reduce the server load and network bandwidth consumption. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 This is an application environment diagram of an implementation of a micro-front-end base resource processing system in an embodiment of the present application;

[0017] Figure 2 It is a flow chart of a micro front-end base resource processing method in an embodiment of the present application;

[0018] Figure 3 It is an execution flow chart of a micro-front-end base resource processing method in an embodiment of the present application;

[0019] Figure 4 It is a principle framework diagram of a micro-front-end base resource processing method in an embodiment of the present application;

[0020] Figure 5 This is a flow chart of reacquiring resources in a micro-front-end base resource processing in an embodiment of the present application;

[0021] Figure 6 It is a structural schematic diagram of a micro front-end base resource processing system in an embodiment of the present application;

[0022] Figure 7 It is a structural schematic diagram of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0023] The following describes the implementation methods of the present application through specific examples, and those skilled in the art can easily understand other advantages and effects of the present application from the contents disclosed in this specification. The present application can also be implemented or applied through other different specific implementation methods, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that the following embodiments and sub-samples in the embodiments can be combined with each other without conflict.

[0024] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present application, and thus the drawings only show components related to the present application rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed at will, and the component layout may also be more complicated.

[0025] In the following description, a large number of details are discussed to provide a more thorough explanation of the embodiments of the present application. However, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details. In other embodiments, well-known structures and devices are shown in the form of block diagrams rather than in detail to avoid making the embodiments of the present application difficult to understand.

[0026] The terms "first", "second", etc. in the specification and claims of the embodiments of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchanged where appropriate, so as to describe the embodiments of the embodiments of the present disclosure described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions.

[0027] Unless otherwise stated, the term "plurality" means two or more.

[0028] In the embodiment of the present disclosure, the character " / " indicates that the preceding and following objects are in an "or" relationship. For example, A / B indicates: A or B.

[0029] The term "and / or" is a description of the association relationship between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or, A and B.

[0030] Combination Figure 1 As shown, an implementation environment diagram of a micro-front-end base resource processing system provided by an embodiment of the present disclosure includes a user end and a server end, wherein the user end and the server end are connected to a network and communicate with each other. In this application, the user end is the front end and the server end is the back end.

[0031] It should be understood that the micro-frontend base resource processing system is applied to the terminal. In some embodiments, the terminal can be at least one of a computer device, a desktop device, a smart phone, and a tablet device; the server can be configured as an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, and big data and artificial intelligence platforms; the software can be an application for micro-frontend base resource processing, etc., but is not limited to the above forms.

[0032] Combination Figure 2 As shown, the embodiment of the present disclosure provides a flow chart of a micro-front-end base resource processing method, including:

[0033] Step S201, in response to the application table determining each application data to be downloaded, creating a resource download thread to download each application data in parallel, wherein the application table is configured by the micro front-end base;

[0034] It should be noted that micro frontends are to split a large frontend application into multiple independent and flexible small applications. Each application can be independently developed, independently run, and independently deployed, and then these small applications are merged into a complete application, or several applications that have been running for a long time and are not related are merged into one application. Micro frontends can not only merge multiple projects into one, but also reduce the coupling between projects and improve project scalability. Compared with a whole frontend warehouse, the frontend warehouse under the micro frontend architecture tends to be smaller and more flexible.

[0035] Among them, the micro front-end base refers to encapsulating common functions into a complete main application as the system base, and then integrating the characteristic parts as sub-applications to reduce the development tasks.

[0036] Specifically, by creating multi-threaded resource download threads to download application data in parallel, the efficiency of data download is significantly improved; in a multi-threaded environment, multiple download tasks can be processed simultaneously, reducing the overall waiting time, which is especially suitable for scenarios where data needs to be downloaded from multiple sources or large files.

[0037] Optionally, in some embodiments, before determining the application data to be downloaded in response to the application table, the method further includes:

[0038] Open the micro front-end base, and determine whether the front-end database exists in the micro front-end base;

[0039] If it exists, then connect to the front-end database; if it does not exist, then create the front-end database;

[0040] In response to the table creation instruction of the micro front-end base, the application table is newly created according to the application name of the table creation instruction. The application table carries basic application information, and each application has a corresponding data table.

[0041] For example, check whether the front-end base (a server-side application or an environment containing multiple front-end application containers) contains a front-end database. If the database does not exist, it will be automatically created; if the database is detected to exist, it will automatically connect to the database without manually configuring the database connection information, which improves the convenience and efficiency of data access.

[0042] For example, in response to a table creation instruction, an application table is dynamically created or updated based on the application name. This mechanism supports flexible data models and allows rapid creation of corresponding data storage for new front-end applications or functions without modifying the underlying database structure. Each application has its own data table, which achieves data isolation between applications, effectively prevents data conflicts, and improves data security and maintainability.

[0043] Specifically, on the server side, frameworks such as Node.JS and Express can be used to build the micro-frontend base, and databases such as SQLite and MongoDB can be used to store front-end data. On the front end, single-page application (SPA) frameworks (such as React and Vue) can be used to build front-end applications, and data can be interacted with the server through HTTP requests. In addition, database management services and table creation logic can be used to ensure the realization of technical effects.

[0044] Step S202, after downloading, storing each of the application data in batches into different data tables of the front-end database;

[0045] Specifically, the downloaded application data is stored in batches in different data tables of the front-end database, which realizes classified management and efficient access to data. Different application data is stored in different tables, which not only ensures the independence of the data, but also facilitates subsequent data query and maintenance.

[0046] Step S203, if it is detected that any of the applications is activated, the resource management thread is caused to send a resource acquisition request to the front-end database and the back-end database respectively, wherein the resource acquisition request includes acquiring all resources of any of the applications;

[0047] Specifically, in response to an application activation request, starting the corresponding application and determining the activation state of the application, wherein the application activation request includes unique identification information of the application to be activated;

[0048] Determining the activated application according to the activation state of the application and the identification information;

[0049] Based on the activated application, the resource management thread sends a first resource acquisition request to the front-end database and sends a second resource acquisition request to the back-end database, and both the first resource acquisition request and the second resource acquisition request include identification information of the activated application.

[0050] The activated application is characterized in different states by state information, for example, the state information includes but is not limited to a closed state, an open state and an activated state. In addition, each application has unique identification information, and different types (names) of applications are characterized by the unique identification information.

[0051] Through the above method, fast response and loading of application resources are ensured, while unnecessary resource loading is reduced and user experience is improved.

[0052] Step S204: if the monitoring obtains all resources of any database first, the resource acquisition request of the other database is terminated, and all acquired resources are parsed to render the application.

[0053] Monitoring in real time the response information of the resource acquisition request of any of the applications, wherein the response information includes all the resources of any of the applications;

[0054] If the monitoring obtains all resources from the front-end database first, then the resource acquisition request of the back-end database is terminated, and all resources of any current application are parsed to render the application; or

[0055] If the monitoring obtains all the resources from the back-end database first, the resource acquisition request of the front-end database is terminated, and all the resources of any current application are parsed to render the application.

[0056] Specifically, if all resources are obtained from one database first, the resource acquisition request from another database will be terminated immediately. This "first come, first served" strategy avoids repeated loading and waste of resources, and also reduces the server load and network bandwidth consumption; once all resources are obtained, they are immediately parsed and rendered. This instant processing method ensures that users can quickly see and interact with the application, further improving the user experience.

[0057] Optionally, in some embodiments, before storing the application data in batches in different data tables of the front-end database, the method further includes:

[0058] According to the state of the thread, the thread corresponding to the downloaded application data is released, and the thread with abnormal state is cleared.

[0059] And generate storage events for batch storage to the front-end database, and send each of the application data to the micro-front-end base;

[0060] In response to the storage event, each of the received application data is sent to the front-end database for batch storage.

[0061] It should be understood that when multiple threads are started to download the required application data, multiple download tasks are processed asynchronously and in parallel; during the download process, the status of each thread (such as running, completed, error, etc.) is continuously monitored. For example, when a thread successfully completes the data download, the thread resources are released, including closing the network connection, releasing memory, etc., to avoid resource leakage; for another example, if a thread is found to enter an abnormal state due to an error or timeout, the thread is immediately cleared and the error information is recorded for subsequent analysis.

[0062] Based on all successfully downloaded data, one or more batch storage events are generated. These events will contain information such as the data to be stored, the target database address, and the storage type. When generating events, optimization measures such as data compression and encryption are considered to reduce the burden of network transmission and ensure data security. The generated storage events are sent to the front-end database processing system. This is achieved through message queues (such as Kafka and Rabbit MQ) to ensure high concurrency and reliability. For example, after receiving the storage event, the front-end database processing system performs batch data storage operations (including data parsing, verification, deduplication, index creation, and other steps). This ensures that the entire batch storage process is executed under transaction control to ensure data consistency and integrity.

[0063] The application data successfully stored in the database is encapsulated into a format recognizable by the front-end component or API, and the encapsulated data is sent to the micro-front-end base through HTTP requests, Web Sockets or other communication protocols. After receiving the data, the micro-front-end base renders, updates or further processes it according to business needs.

[0064] Through the above method, thread resources can be managed efficiently, accurate downloading and storage of application data can be ensured, and the latest data can be pushed to the micro-frontend base in a timely manner, thereby improving user experience and system performance.

[0065] Optionally, in some embodiments, creating a resource download thread to download each of the application data in parallel includes:

[0066] Create a multi-threaded resource download thread, and configure the application download priority and download quantity rule of the resource download thread, wherein the application download priorities are, from high to low, new applications, version update applications, and applications for which resources have not been downloaded, and the download quantity rule determines the number of application downloads due to the differences in the number of threads and parallelism of different platforms;

[0067] Determine the target application according to the application data carried by the application table and the download quantity rule;

[0068] The download order of the target application is determined according to the application download priority, and each application data is downloaded in parallel by using one resource download thread through one application in turn according to the download order.

[0069] For example, by controlling the version number of the application - resource download priority

[0070] Download priority [new applications > applications with changed version numbers (version updated applications) > applications with no downloaded resources, i.e. applications without cached resources (queued)] are queued. Each time you re-enter the desktop, it will be queued once, 8 applications at a time for Windows and 24 applications for Mac. If it is not a new application, the version number will not be updated in the base GOS, and it will not be queued. It will only be stored after the user has visited it once - but the page speed of the application will be slower when the user visits it for the first time.

[0071] Another example is the download quantity rule of the application (customizable rule):

[0072] Window: Open up to 4 threads at a time, run 2 applications in parallel, and download up to 8 applications at a time

[0073] Mac: Up to 6 threads can be opened at a time, and 4 applications can be downloaded in parallel. Up to 24 applications can be downloaded at a time.

[0074] Other platforms: 8 threads, download 3 apps in parallel, download up to 24 apps at a time

[0075] Specifically, according to the application data carried by the application table and the download quantity rule, the target application (data) that can be currently downloaded by the micro-front-end base is determined, and the download order in the target application is determined according to the application download priority, that is, the order of precedence, and parallel download is adopted according to this order.

[0076] In addition, the application data carried by the application table, that is, the download data list, can be used to determine the download order according to the resource download priority, and then the download order can be used to use the hardware and system of the current micro-front-end base to determine the number of threads of the micro-front-end base, the number of parallel downloads, and the maximum number of applications that can be downloaded at one time. In this way, each application can be downloaded in parallel according to the download order.

[0077] Through the above method, application resources can be acquired in a non-blocking, multi-task parallel manner, thereby improving application acquisition efficiency.

[0078] Optionally, in some embodiments, parsing all acquired resources to render the application further includes:

[0079] Execute resource loading and parsing operations, and store the parsed resources in the cache; confirm the application to be rendered, obtain the resources to be rendered required by the application to be rendered from the cache, and render the resources to be rendered to the application to be rendered; execute the business logic code in response to the application.

[0080] As an implementation mode, before executing the resource loading operation and the parsing operation, resource list configuration information is obtained; and the resource configuration module stores a temporary loading resource list according to the resource list configuration information.

[0081] For example, the resources are parsed into resources that support Cocos Creator recognition; for another example, as an implementation method, when parsing resources, it also includes: parsing Plist resources, FNT configuration information, FNT font basic information, FNT font character information, and creating an FNT dictionary.

[0082] As an implementation mode, confirming the application to be rendered includes: instantiating Prefab to obtain the application to be rendered.

[0083] As an implementation mode, the resource to be rendered includes: a first resource, a second resource, a third resource and a fourth resource; the first resource includes: a Plist atlas resource; the second resource includes: an Animation resource; the third resource includes: a Spine resource; the fourth resource includes: a scattered image resource;

[0084] As an implementation mode, rendering the resource to be rendered to the application to be rendered includes: generating an entity Node through the Prefab; binding the first resource, the second resource, the third resource and the fourth resource to the application, for executing business logic code to end development in response to completion of application rendering.

[0085] Through the above methods, a system is built that can load, parse, cache resources, and render them to the application, while supporting the application to execute its business logic code.

[0086] Optionally, in some embodiments, after storing the application data in batches in different data tables of the front-end database, the method further includes:

[0087] If the cached application resources in the front-end database are monitored to reach a preset data volume, determining the application cache order in which the front-end database stores the application;

[0088] For each application cached in the front-end database, a portion of application resources that are cached first are cleared according to the application cache order to release the cache space of the application resources.

[0089] Specifically, when it is monitored that the cache application resources (storage application resources) in the front-end database reach the preset data volume, that is, when the storage application resources are acquired, the cache order of each application storage, that is, which application is stored first and the storage order of the applications.

[0090] By starting from the first application stored in the cache order, it is determined which part of the cached application resources needs to be cleared (ie deleted). In this way, the storage of application resources can be prevented from being too large through the cleaning mechanism.

[0091] For example, automatically clean up old data (automatically inspect the application's survival status), clean up resources every 10 minutes when the page is active (to prevent the DB from being too large), inspect all application cached resources (JS, CSS) and if the number of resources is greater than 80, delete them from the first one (often unlikely) and keep the last 80. If there are 200 resources, delete the first 120 resources. In addition, manual cleaning can also be used (cleaning function is provided), and the base sends the Clear All Table (clean up all data) command interface to the data resource management thread.

[0092] For example, browser cache can reduce the problem of multiple retrieval by writing images and fonts to resources that the application depends on and needs to be loaded multiple times, and using browser cache.

[0093] For another example, the application's Html source file cache uses a resource download thread to persistently store the application's Html source code, and is updated through the application version mechanism to facilitate direct secondary reading and parsing.

[0094] In some embodiments, see Figure 3 , is an execution flow chart of a micro-front-end base resource processing method in an embodiment of the present application, which is described in detail as follows:

[0095] Step 1: Create a database (Micro App Name). If the Micro App Name already has a database, directly connect to the Micro App Name. Receive instructions (Create Table) from the micro front-end base (collectively referred to as the base) and create an application table (one table for each application). The table name is [App Name] passed by the micro front-end base. Among them, this [Table Configuration - [File_Name, File_Url, File_Content]] is ignored if [App Name] exists.

[0096] Step 2: After completing the first step, the resource management thread sends a Create DB Successly (database creation completed) / Create Table Successly (table creation completed) instruction to the base. After receiving the Create Table Successly instruction, the base sends a Create Table Successly to the resource download thread.

[0097] Step 3: After receiving the Create Table Successly instruction, the resource download thread starts to confirm which sub-applications to start downloading and the number of downloads of the application according to the download priority rule.

[0098] Default download priority (customizable rules): (priority of non-existent new applications > priority of applications with changed version numbers > priority of applications whose resources have never been downloaded).

[0099] Download quantity rules for apps (customizable rules):

[0100] Window: Up to 4 threads can be opened at a time, 2 applications can be run in parallel, and up to 8 applications can be downloaded at a time;

[0101] Mac: Up to 6 threads can be opened at a time, and 4 applications can be downloaded in parallel. Up to 24 applications can be downloaded at a time.

[0102] Other platforms: 8 threads, download 3 apps in parallel and download up to 24 apps at a time.

[0103] Step 4: The resource download thread starts to create multiple threads (one thread for each application) based on the confirmed application data and starts to download application resources in parallel. It analyzes the source code of the HTML of the requested application and extracts the HTML. <script>标签的JS文件路径,<Style>CSS源文件路径,以‘递归’方式收集所有JS / CSS文件路径后,再批次下载,整个过程结束之后,向基座发送Batch Items To Tables(批量保存文件内容到IndexDB),App Batch Download End(应用下载完成)开始释放该应用占用的线程资源(浏览器资源)。

[0104] Step5:接收到App Batch Download End后,开始清理不再使用的线程;

[0105] 说明:源文件未成功下载资源(如网络,应用地址不可用)也会被程序清理。

[0106] Step6:接收到Batch Items To Tables(批量存储数据到表)后开始存储资源;

[0107] 说明:Batch Items To Tables可实现无阻塞并行方式存储。

[0108] Step7:基座激活应用时发送Get Files By Table Name(获取应用所有资源)给资源管理线程;

[0109] 说明:获取的资源优先级高于应用远程资源

[0110] Step8:基座监听资源管理线程Get Files By Table Name Successly消息(已获取到所有资源)获取已存储在本地的资源;

[0111] 说明:基座监听Get Files By Table Name Successly指令异步获取,如果网络状态非常良好,快于本地获取,将使用远程资源。

[0112] Step9:执行本地获取的资源;

[0113] 说明:执行代码由基座的Micro-APP完成。

[0114] 需要说明的是,第一步到第九步其中任何一步的失败对程序无任何影响,不会对微前端基座项目有任何影响,它们是互相独立的。还需要说明的是,前三个步骤只初始化执行一次,后三个步骤每次都会执行,中间三个步骤看资源是否在本地已存储而定。

[0115] 在本实施例中,相比网络带宽(或者浏览器缓存)与本地存储的性能对比:本申请应用的页面速度普遍高于网络带宽(或者浏览器缓存),不仅数量越大,且相对于本地方案优势更明显。

[0116] 详见图4,是本申请实施例中一种微前端基座资源处理方法的原理框架图,详述如下:

[0117] 数据资源管理线程通过微前端基座GOS链接资源下载线程池

[0118] 例如,数据资源管理线程分为两部分,一部分接受(即接收)事件,另一部分发送事件。

[0119] 其中,接受事件包括创建数据库、创建表、单表批量、批量存储数据到数据表、清理指定应用数据、清理所有应用数据、巡检、获取应用标识获取所有资源。

[0120] 发送事件包括创建数据库成功、创建表成功、清理所有应用数据成功、获取应用标识获取所有资源成功,需要说明的是,上述成功事件是主动触发的。

[0121] GOS基座,即,微前端基座,用于监听发送事件,获取相关信息。

[0122] 资源下载线程池,通过资源下载线程下载资源。其中,资源下载线程接受应用开始下载,通过触发发送事件,例如,批量存储下载资源,并行资源下载完成。

[0123] 还需要说明的是,数据资源管理线程:负责处理资源的管理例如数据库创建,资源表创建,清理,资源清理巡检,资源删除,获取等操作,独立线程不会占用基座的页面执行资源,同时,提供对应配套的Create DB Successly,Create Table Successly,App BatchDown Load End,Check Count And Delect Rverse Successly等消息通知基座,相对应的指令操作已经完成。

[0124] 请参阅图5,是本申请实施例中一种微前端基座资源处理中重新获取资源的流程图,详述如下:

[0125] 重写获取应用资源的Fetch方法,基座向资源线程发送Get Files By Table Name指令,同时检听Get Files By Table Name Successly(获取应用资源指令是否完成),来获取子应用资源判断是否已存储,如果未存储走网络带宽下载,存在直接本地获取。

[0126] 需要说明的是,对于应用的异步的资源(JS,CSS)重写Micro-App时也对其存储,如果没有等到异步结果,会网络获取请求下一个,下个请求时再看有无异步结果。

[0127] 例如,100个菜单应用加载耗时,WindowsB:2600ms;WindowsC:2797ms;Mac&AirB:2356ms;Mac&AirC:2258ms;Mac&ProB:1993ms;Mac&ProC:2227ms。

[0128] 例如,500个菜单应用加载耗时,WindowsB:3120ms;WindowsC:3358ms;Mac&AirB:2134ms Mac&AirC:2194ms;Mac&ProB:1741ms;Mac&ProC:2227ms。

[0129] 如,1000个菜单应用加载耗时,WindowsB:3339ms;WindowsC:3981ms;Mac&AirB:2126ms;Mac&AirC:2499ms;Mac&ProB:2184ms;Mac&ProC:2389ms。

[0130] 例如,7298个菜单应用加载耗时,WindowsB:4639ms;WindowsC:6467ms;Mac&AirB:4083ms Mac&AirC:5482ms;Mac&ProB:2838ms;Mac&ProC:3967ms。

[0131] 通过上述方式,相比网络带宽(或者浏览器缓存)与本地存储的性能对比:应用的页面速度普遍高于网络带宽(或者浏览器缓存),而且数量越大,本地方案优势越明显。

[0132] 请参阅图6,是本申请实施例中一种微前端基座资源处理系统的结构示意图,包括:

[0133] 应用下载模块601,用于响应于应用表确定待下载的各应用数据,创建资源下载线程并行下载各个所述应用数据,其中,所述应用表为微前端基座配置而成;

[0134] 批量存储模块602,用于待下载后,将各应用数据批量存储到前端数据库的不同数据表;

[0135] 资源获取模块603,用于若监测到任意所述应用被激活,则使所述资源管理线程分别向所述前端数据库、后端数据库发送资源获取请求,所述资源获取请求包括获取任意所述应用的所有资源;

[0136] 资源处理模块604,用于若监测先获取到任一数据库的所有资源,则终止另一数据库的所述资源获取请求,并解析获取到的所有资源以渲染所述应用。

[0137] 需要说明的是,本申请微前端基座资源处理方法与微前端基座资源处理系统一一对应,所对应的技术细节即技术方案参照上述微前端基座资源处理方法,在此不再一一赘述。

[0138] 通过上述方式,微前端基座资源处理系统具有以下技术效果:通过创建多线程的资源下载线程并行下载各个所述应用数据,将各个所述应用数据批量存储到前端数据库的不同数据表;若监测到任意所述应用被激活,则使所述资源管理线程分别向所述前端数据库、后端数据库发送资源获取请求,所述资源获取请求包括获取任意所述应用的所有资源;若监测先获取到任一数据库的所有资源,则终止另一数据库的所述资源获取请求,并解析获取到的所有资源以渲染所述应用。这样,一方面,通过多线程下载提高了数据下载的效率,减少了响应时间,另一方面,将下载的应用数据批量存储到前端数据库的不同数据表,实现了数据的分类管理和高效访问;另一方面,通过前后端获取策略确保了应用资源的快速响应和加载,同时减少了不必要的资源加载,提高了用户体验;还有,采用先到先用策略避免了资源的重复加载和浪费,也减少了服务器的负载和网络带宽的消耗。

[0139] 在另一些实施例中,本公开实施例还提供了一种电子设备,包括:处理器及存储器;存储器用于存储计算机程序,处理器用于执行存储器存储的计算机程序,以使电子设备执行上述的方法。

[0140] 图7示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。需要说明的是,图7示出的电子设备的计算机系统700仅是一个示例,不应对本申请实施例的功能和使用范围带来任何限制。

[0141] 如图7所示,计算机系统700包括中央处理单元(Central Processing Unit,CPU)701,其可以根据存储在只读存储器(Read-Only Memory,ROM)702中的程序或者从储存部分708加载到随机访问存储器(Random Access Memory,RAM)703中的程序执行各种适当的动作和处理,例如执行上述实施例中的方法。在随机访问存储器703中,还存储有系统操作所需的各种程序和数据。中央处理单元701、只读存储器702以及随机访问存储器703通过总线704彼此相连。输入 / 输出(Input / Output,I / O)接口705也连接至总线704。

[0142] 以下部件连接至输入 / 输出接口705:包括键盘、鼠标等的输入部分706;包括诸如阴极射线管(Cathode Ray Tube,CRT)、液晶显示器(Liquid Crystal Display,LCD)等以及扬声器等的输出部分707;包括硬盘等的储存部分708;以及包括诸如LAN(Local AreaNetwork,局域网)卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至输入 / 输出接口705。可拆卸介质711,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器710上,以便于从其上读出的计算机程序根据需要被安装入储存部分708。

[0143] 特别地,根据本申请的实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本申请的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中,该计算机程序可以通过通信部分709从网络上被下载和安装,和 / 或从可拆卸介质711被安装。在该计算机程序被中央处理单元701执行时,执行本申请的系统中限定的各种功能。

[0144] 以上描述和附图充分地示出了本公开的实施例,以使本领域的技术人员能够实践它们。其他实施例可以包括结构的、逻辑的、电气的、过程的以及其他的改变。实施例仅代表可能的变化。除非明确要求,否则单独的部件和功能是可选的,并且操作的顺序可以变化。一些实施例的部分和子样本可以被包括在或替换其他实施例的部分和子样本。而且,本申请中使用的用词仅用于描述实施例并且不用于限制权利要求。如在实施例以及权利要求的描述中使用的,除非上下文清楚地表明,否则单数形式的"一个”(a)、"一个”(an)和"所述”(the)旨在同样包括复数形式。类似地,在本申请中所使用的术语"和 / 或”是指包含一个或一个以上相关联的列出的任何以及所有可能的组合。另外,当用于本申请中时,术语"包括”(comprise)及其变型"包括”(comprises)和 / 或包括(comprising)等指陈述的子样本、整体、步骤、操作、元素,和 / 或组件的存在,但不排除一个或一个以上其它子样本、整体、步骤、操作、元素、组件和 / 或这些的分组的存在或添加。在没有更多限制的情况下,由语句"包括一个…”限定的要素,并不排除在包括要素的过程、方法或者设备中还存在另外的相同要素。本文中,每个实施例重点说明的可以是与其他实施例的不同之处,各个实施例之间相同相似部分可以互相参见。对于实施例公开的方法、产品等而言,如果其与实施例公开的方法部分相对应,那么相关之处可以参见方法部分的描述。

[0145] 本领域技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,可以取决于技术方案的特定应用和设计约束条件。技术人员可以对每个特定的应用来使用不同方法以实现所描述的功能,但是这种实现不应认为超出本公开实施例的范围。技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。

[0146] 本文所披露的实施例中,所揭露的方法、产品(包括但不限于装置、设备等),可以通过其他的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,单元的划分,可以仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些子样本可以忽略,或不执行。另外,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其他的形式。作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例。另外,在本公开实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。

[0147] 附图中的流程图和框图显示了根据本公开实施例的方法、系统和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这可以依所涉及的功能而定。在附图中的流程图和框图所对应的描述中,不同的方框所对应的操作或步骤也可以以不同于描述中所披露的顺序发生,有时不同的操作或步骤之间不存在特定的顺序。例如,两个连续的操作或步骤实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这可以依所涉及的功能而定。框图和 / 或流程图中的每个方框,以及框图和 / 或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。< / script>

Claims

1. A micro front-end base resource processing method, characterized in that: include: In response to the application table determining each application data to be downloaded, creating a resource download thread to download each application data in parallel, wherein the application table is configured by the micro front-end base; After downloading, each of the application data is stored in batches in different data tables of the front-end database; If it is detected that any of the applications is activated, the resource management thread is caused to send a resource acquisition request to the front-end database and the back-end database respectively, wherein the resource acquisition request includes acquiring all resources of any of the applications; If the monitoring obtains all resources of any database first, the resource acquisition request of the other database is terminated, and all acquired resources are parsed to render the application.

2. The method according to claim 1, characterized in that: Before determining the application data to be downloaded in response to the application table, the method further includes: Open the micro front-end base, and determine whether the front-end database exists in the micro front-end base; If it exists, then connect to the front-end database; if it does not exist, then create the front-end database; In response to the table creation instruction of the micro front-end base, the application table is newly created according to the application name of the table creation instruction. The application table carries basic application information, and each application has a corresponding data table.

3. The method according to claim 1 or 2, characterized in that: Before storing each of the application data in batches into different data tables of the front-end database, the method further includes: According to the state of the thread, the thread corresponding to the application data after downloading is released, and the thread with abnormal state is cleared, and storage events for batch storage to the front-end database are generated, and each of the application data is sent to the micro front-end base; In response to the storage event, each of the received application data is sent to the front-end database for batch storage.

4. The method according to claim 3, characterized in that Creating a resource download thread to download each of the application data in parallel includes: Create a multi-threaded resource download thread, and configure the application download priority and download quantity rule of the resource download thread, wherein the application download priorities are, from high to low, new applications, version update applications, and applications for which resources have not been downloaded, and the download quantity rule determines the number of application downloads due to the differences in the number of threads and parallelism of different platforms; Determine the target application according to the application data carried by the application table and the download quantity rule; The download order of the target application is determined according to the application download priority, and each application data is downloaded in parallel by using one resource download thread through one application in turn according to the download order.

5. The method according to claim 1, characterized in that If it is detected that any of the applications is activated, the resource management thread is caused to send a resource acquisition request to the front-end database and the back-end database respectively, including: In response to an application activation request, starting the corresponding application and determining the activation state of the application, wherein the application activation request includes unique identification information of the application to be activated; Determining the activated application according to the activation state of the application and the identification information; Based on the activated application, the resource management thread sends a first resource acquisition request to the front-end database and sends a second resource acquisition request to the back-end database, and both the first resource acquisition request and the second resource acquisition request include identification information of the activated application.

6. The method according to claim 1, characterized in that If the monitoring obtains all resources of any database first, the resource acquisition request of the other database is terminated, and all acquired resources are parsed to render the application, including: Monitoring in real time the response information of the resource acquisition request of any of the applications, wherein the response information includes all the resources of any of the applications; If the monitoring obtains all resources from the front-end database first, then the resource acquisition request of the back-end database is terminated, and all resources of any current application are parsed to render the application; or If the monitoring obtains all the resources from the back-end database first, the resource acquisition request of the front-end database is terminated, and all the resources of any current application are parsed to render the application.

7. The method according to claim 1, characterized in that And parse all the acquired resources to render the application, including: Execute resource loading and parsing operations, and store the parsed resources in the cache; confirm the application to be rendered, obtain the resources to be rendered required by the application to be rendered from the cache, and render the resources to be rendered to the application to be rendered; execute the business logic code in response to the application.

8. The method according to claim 1, characterized in that: After storing each of the application data in batches into different data tables of the front-end database, the method further includes: If the cached application resources in the front-end database are monitored to reach a preset data volume, determining the application cache order in which the front-end database stores the application; For each of the applications cached in the front-end database, a portion of application resources that are cached first are cleared according to the application cache order to release cache space for application resources.

9. A micro front-end base resource processing system, characterized in that: include: An application download module, for determining each application data to be downloaded in response to the application table, and creating a resource download thread to download each application data in parallel, wherein the application table is configured by the micro front-end base; A batch storage module, used for storing each of the application data in batches into different data tables of the front-end database after downloading; A resource acquisition module, configured to enable the resource management thread to send a resource acquisition request to the front-end database and the back-end database respectively if any of the applications is detected to be activated, wherein the resource acquisition request includes acquiring all resources of any of the applications; The resource processing module is used to terminate the resource acquisition request of another database if all resources of any database are acquired first through monitoring, and parse all acquired resources to render the application.

10. An electronic device, characterized in that: include: Processor and memory; The memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the electronic device executes the method according to any one of claims 1 to 8.