System and method for front-end WEB application creation for cloud computing platform

Abstract

The invention relates to a system and method for creating and integrating front-end microservice applications to a host platform. The system and the method can comprise the following steps: transmitting a demand packet corresponding to a micro-service front-end application to a UX development platform; generating a model package based on the demand package through the UX development platform; transmitting the model package to a micro-service front-end development platform to generate a micro-service front-end application; generating a micro-service front-end application package based on the model package through the micro-service application development platform; and integrating a micro-service front-end application package, in which supplier applications are integrated using the micro-service front-end application based on the demand package.

Description

[0001] Priority application This application claims the benefit of U.S. Patent Application No. 18 / 089,082, filed December 27, 2022, which is a continuation-in-part (CIP) of U.S. Patent Application Serial No. 17 / 824,563, filed May 25, 2022, the disclosure of which is incorporated herein by reference. Technical Field

[0002] This invention relates to methods and standards for application packaging and integration, and more specifically to integrating and deploying application resources in the cloud. Background Technology

[0003] There are certain challenges in developing and installing updates and patches for hosted web applications on computer systems. Vendors use specialized delivery packages to integrate Software as a Service (SaaS) web applications into the system. However, if the vendor needs to integrate / deploy their application (App) to the cloud, all integration operations must be repeated multiple times for each host or hosting platform. Both host and hosting platforms have applications that control them. These applications further complicate and increase the cost of integrating external (third-party) applications or web services.

[0004] Currently, applications are integrated into hosting and hosting platforms through control implementations. In the case of cloud systems, the cloud (or cloud server) is a combination of hardware and software from a hosting provider that provides functionality for external applications within client accounts.

[0005] In the cloud computing platform field, the combination of client application creation and deployment with platform-based operations presents inefficiencies. For example, cloud computing platforms may face issues related to effective application development and / or host deployment. The development of Software as a Service (SaaS) web applications is typically closely tied to the platform host. All processes related to developing new applications are tightly linked to the deployment of the platform host stack. This approach also requires addressing application-related background issues at the core level, leading to inconvenience and time losses.

[0006] The main drawback of conventional technologies is that during the creation and deployment of new applications, the platform host needs to communicate with the application package during application development, while the package contains an uncertain testing environment. Furthermore, conventional technologies require excessively long deployment times and a continuous internet connection during application creation. Therefore, there is an urgent need in the field for a highly efficient and low-cost method to integrate the application itself, application updates, and patches into the cloud platform host. Summary of the Invention

[0007] The embodiments described herein provide Front-end Microservice Development (FMD). Specifically, this disclosure provides a system and method for creating and integrating front-end microservice applications into a host platform. The system and method may include: transmitting a requirement package corresponding to the microservice front-end application to a UX development platform; generating a model package based on the requirement package through the UX development platform; transmitting the model package to the microservice front-end development platform to generate the microservice front-end application; generating a microservice front-end application package based on the model package through the microservice application development platform; and integrating the microservice front-end application package, wherein the vendor application is integrated using the microservice front-end application based on the requirement package.

[0008] Traditionally, front-end developers may encounter several challenges when developing microservices that operate independently of the entire platform, used as part of a multi-microservice environment within the platform host. Developing microservices through the platform host increases development costs, including deployment and sandboxing adjustments (i.e., adjustments to the stack and the platform host). Even minor changes to the microservice code may require redeploying all code to the stack, resulting in transport losses. Front-end developers often receive requests for user interface (UI) elements (buttons, fonts, colors, etc.), which must be implemented from scratch each time. Beyond writing the core of the business logic itself, developers must consider many aspects: how the microservice should be presented relative to the application itself, how the microservice should be displayed and run in the common interface (platform host), and how to maintain a unified user experience.

[0009] In some embodiments, the FMD method and system may include a local microservice development model that runs independently of the platform host, as detailed in U.S. Patent Application No. 17 / 824,563, the entire contents of which are incorporated herein by reference. In some embodiments, the FMD method and system may additionally include mockup and tokenization processes, i.e., tokens maintained in a unified widget library, for example, a library that is application-independent and available to front-end developers. In some embodiments, the FMD method and system may also include interactions between microservices and the external world. For example, the FMD method and system can enable communication between front-end microservices and other microservices during development, including the host itself, Representational State Transfer (REST) ​​request systems, unit testing, application debugging, and communication simulation before host deployment.

[0010] In some embodiments, the FMD method and system may further include providing front-end developers with all the resources they need as part of the process using a specific cloud framework, and returning the results as an application as an integrated part of the process. This framework initially divides the new microservices (web applications) into specific application layers. According to the embodiments described herein, the above tasks are effectively addressed in general by well-organizing communication between the different "blocks" involved in the web application creation process. Therefore, it is possible to accelerate application readiness, improve testing and debugging, and reduce application development costs.

[0011] This approach allows for a reduction in the time front-end developers spend on new microservices and lowers the skill requirements for them. The FMD system and methodology only require developers to assemble the software layers, perform the debugging process, and further deploy viable microservices to the stack and platform hosts. Specific REST-Store vertical architecture details provide effective front-end-back-end connectivity for microservices, allowing developers to use the same code across different modes, such as local development (using simulated data transfer levels), unit testing, and production (runtime).

[0012] According to embodiments of the present invention, a system and method for front-end microservice development (FMD) are provided to improve the application development process. The FMD solution effectively solves the aforementioned technical problems, providing an independent application creation process at the platform host core level, efficiently deploying applications to the platform host, thereby minimizing downtime.

[0013] This invention provides an FMD system and method for creating, sharing, and integrating vendor applications. The application development and deployment system and method may include: a host platform communicating a framework package corresponding to the application framework, the framework package including software abstractions to provide general functionality when developing vendor applications; the host platform receiving an application package corresponding to the vendor application, the application package including multiple metadata files, control method descriptions, and content files; and integrating the application packages to generate the vendor application based on the application framework.

[0014] According to some embodiments, the FMD system and method differ from existing technologies in that, during application development, the hard connection between the application and the host is broken. The host "adopts" an already running application, making it easy to deploy. In this scenario, even during application development, a continuous internet connection is not required. Due to host operation, conventional systems and methods require several hours just to develop a new application. According to exemplary embodiments, separating the platform host from the application development process brings many technical advantages. New applications can be created and tested before host deployment, resulting in reliable applications upon deployment. Furthermore, during application development, there is no need to fix faults caused by the host core layer, thus solving other problems in conventional technologies. The FMD system and method achieve efficient application creation in terms of speed, reliability, and resource conservation. Attached Figure Description

[0015] Figure 1 An example operating environment for a system used for front-end microservice development (FMD) according to some embodiments is shown.

[0016] Figure 2 An FMD system according to some embodiments is shown.

[0017] Figure 3 Methods for developing and delivering microservice front-ends in an FMD system are illustrated according to some embodiments.

[0018] Figure 4 The model and tokenization in FMD are shown according to some embodiments.

[0019] Figure 5 An FMD system according to some embodiments is shown.

[0020] Figure 6 The integration of applications presented via a platform host in an FMD system is illustrated according to some embodiments.

[0021] Figure 7 An example computing device according to an exemplary embodiment is shown. Detailed Implementation

[0022] To facilitate understanding of the principles of this disclosure, the embodiments are described below in specific language with reference to the accompanying drawings. However, it should be understood that this is not intended to limit the scope of protection of this disclosure.

[0023] Embodiments of this disclosure can be implemented through hardware, firmware, software, or any combination thereof. Embodiments of this disclosure can also be implemented as instructions stored on a machine-readable medium, readable and executable by one or more processors. A machine-readable medium can include any mechanism that stores or transmits information in a machine-readable form (e.g., a computing device). For example, a machine-readable medium can include read-only memory (ROM); random access memory (RAM); disk storage media; optical storage media; flash memory devices, etc. Furthermore, firmware, software, routines, and instructions herein can be described as performing certain actions. However, it should be understood that such descriptions are for ease of description only, and such actions actually arise from the execution of firmware, software, routines, instructions, etc., by a computing device, processor, controller, or other device.

[0024] It should be understood that the operations shown in the exemplary methods are not exhaustive, and other operations may be performed before, after, or in between any of the shown operations. In some embodiments of this disclosure, operations may be performed in different orders and / or in different ways.

[0025] Microservice Creation The FMD methods and systems described in this document may include a local microservice development model that runs independently of the platform host, as detailed in U.S. Patent Application No. 17 / 824,563, the entire contents of which are incorporated herein by reference. In some embodiments, the FMD methods and systems may additionally include a model building and tokenization process, i.e., tokens maintained in a unified widget library, for example, a library that is supported independently of a specific application and available to front-end developers. In some embodiments, the FMD methods and systems may also include interactions between microservices and the external world. For example, the FMD methods and systems can enable communication between front-end microservices and other microservices during development, including the host itself, a Representational State Transfer (REST) ​​request system, unit testing, application debugging, and communication simulation before host deployment.

[0026] To address the aforementioned technical problems, this invention provides a Front-End Microservice Development (FMD) system and method. The FMD system and method provide a specific layer for the front-end of vendor microservice applications, offering front-end developers all the resources needed to integrate the application as part of the process. FMD improves task efficiency by effectively organizing and implementing communication between different components in the web application creation process. The FMD system and method enable timely application readiness and testing and debugging improvements. Therefore, it enhances the operability of end-user applications while reducing application development costs. Front-end developers can specifically combine software layers and perform debugging and deployment processes, minimizing the time and effort required to develop new microservices. The FMD system and method include specific REST-Store vertical architecture details to provide more efficient front-end and back-end connections for microservices, allowing developers to support modes such as local development (including simulated data transfer level), unit testing, and runtime (i.e., production) with only a single code compilation.

[0027] Figure 1 An FMD system according to some embodiments is shown. For example... Figure 1 As shown, the FMD system 100 provides a multi-project ecosystem where projects can be separated based on factors such as function, responsibility, and team. The FMD system 100 includes the implementation of a microservice requirements package 110, a UX development platform 120, a microservice platform 130, and a platform host 140 (for end users).

[0028] like Figure 1 As shown, the UX development platform 120 can receive application microservice requirements 110 corresponding to microservice applications such as new applications. The UX system 100 can transmit the requirements to the UX development team 122. The UX development platform enables the UX development team 122 to generate one or more models 124 associated with the application microservice requirements 110. This approach differs from traditional post-model generation methods. According to embodiments of the invention, independent style sheet language variables, such as Cascading Style Sheets (CSS) variables, can be initially implemented in the model and then physically imported into the UI toolkit and microservice application. According to embodiments of the invention, independent SASS CSS (SCSS) variables can be implemented and imported. Accordingly, such embodiments enable consistency between the resulting layout and the model.

[0029] The UX development platform 120 enables the creation of a set of design tags, namely variable constants about specific components and their use cases. Operation 310 includes creating variable constants that may have already been used in reference component handover libraries (visual appearance and sensory documentation). See, for example, [link to relevant documentation]. Figure 4An exemplary model including design markup is shown. This model is configured for page-by-page development as an application. UX development platform 120 enables developers to easily and intuitively create, view, and modify variable constants, which can be based on a reference component handover library. According to embodiments of the present invention, FMD system 100 facilitates customization and skinning, where skinning refers to the process of applying one or more sets of specific user experience (UX) elements to each consumer. For example, skinning can involve the application of specific markup, colors, icons, etc.

[0030] The FMD system 100 enables one or more models 124 to be transmitted to and / or retrieved by the microservice platform 130. The microservice development platform 130 enables one or more developers 132 to use the models 124 to generate microservice front-end applications 134 associated with application microservice requirements 110. The microservice development platform 130 performs page-by-page microservice design and development. The microservice development platform 130 includes a testing module 136 that further enables developers 132 to perform unit testing, end-to-end (e2e) testing, and debugging of the microservice front-end applications 134.

[0031] As shown in the figure, the creation of microservice front-end applications in development platform 110 is separate from the platform host 140 itself. According to an exemplary embodiment, one or more frameworks associate the applications on development platform 110 with the (production) applications on platform host 130. That is, the frameworks interconnect the respective applications. The frameworks include basic templates required for applications and testing on development platform 110. The frameworks also include the necessary specific means for integrating and deploying applications in platform host (hosted cloud) 130.

[0032] In an exemplary embodiment, the microservice development platform 130 is capable of generating a microservice front-end application 134 based on application code 134a and framework 134b. Application code 134a may include code written by developers. Framework 134b (e.g., Vue) can provide software abstractions to offer general functionality that can be selectively adapted and implemented by application code 134a, thereby providing application-specific software for building user interfaces, etc. Framework 134b can provide this abstraction based on standard programming languages ​​(e.g., HTML, CSS, JavaScript, etc.), thereby providing a component-based declarative programming model that allows for the efficient development of application-specific software (such as user interfaces, whether simple or complex).

[0033] When FMD 100 is configured to deploy application 134, development platform 110 can generate an application bundle that implements application 134 and framework 104 as a single, all-in-one container. According to an exemplary embodiment, developer 132 (e.g., a cloud application provider) can bundle application code 134a and framework 134b according to APS. The bundling format depends on the recipient, such as platform host 130. If the recipient is a standard Windows desktop, standard installer packaging software can be used, with file extensions *.exe or *.msi. The installer includes unpacking rules, including user dialogs, registry writes, and update checks. For APS purposes, the bundle extension can be app.zip, and it includes metadata, scripts, and the software code itself.

[0034] An exemplary application 102 is delivered to platform host 140 via an application bundle. A microservice frontend application 134 is generated internally on platform host 140 based on frontend application 134a and framework 134b. Platform host 140 may include a controller, namely an application packaging controller, whose runtime module is configured to distribute microservice frontend application 134 to one or more end users. APS is a specification defining the lifecycle of microservice frontend application 134 in the cloud. The application lifecycle includes packaging, delivery to the cloud, integration (and unpacking / deployment) to the cloud, distribution to clients, licensing, features, updates, and deletion. APS may include an application programming interface (API) for accessing APS functionality via program code or via HTTP / HTTPS requests. APS provides efficient integration of SaaS web applications (such as microservice frontend application 134) into the cloud. According to an exemplary embodiment, to enable the application to run according to APS, an APS module 138 (i.e., a control) is integrated into the software hosting platform (platform host 140) of the managed cloud. APS module 138 serves as a connector for controlling microservice frontend application 134.

[0035] Model generation Figure 2 A UX development platform 120 for an FMD system 100 according to some embodiments is shown. For example... Figure 2 As shown, the FMD system 100 provides a multi-project ecosystem where projects can be separated based on factors such as function, responsibility, and team. The FMD system 100 includes the implementation of a microservice requirements package 110, a UX development platform 120, a microservice platform 130, and a platform host 140 (for end users).

[0036] like Figure 2As shown, the UX development platform 120 can receive application microservice requirements 110 corresponding to microservice applications such as new applications. The UX development platform is able to implement one or more design tags 210 based on the microservice requirements 110. Tagging refers to variable constants about components and use cases (conditions). Tag design sets are created and interconnected with design components. These tag design sets can be used in other projects and can be replicated based on changes in the project.

[0037] The UX development platform 120 includes a handover document 230, which may include a reference component library. The UX development platform 120 can enable handover mode on the model to facilitate the sharing of detailed information about the design markers used in the model. The handover 230 may include every detail and digital asset needed by the development team to implement the microservice front-end design.

[0038] The UX development platform 120 enables one or more UX-UI themes 220 to work in conjunction with the interface 230 to implement one or more UX-UI theme kits 240 based on microservice requirements 110. SCSS variables can be physically imported into the UI theme kit 240 to minimize inconsistencies in the model, resolve design issues, and allow for customization and skinning.

[0039] The UX development platform enables the implementation of one or more design Storybooks 250. Storybook 250 allows UX developers to develop components, document components for reuse, visually test these components, and capture component state to identify inconsistencies. Furthermore, the FMD system 100 enables the UX development platform 120 to publish Storybook 250 as one or more models 124 for implementation by the microservice development platform 140.

[0040] Figure 3 An FMD method 300 for developing and integrating new front-end microservices to be integrated at runtime is illustrated. By utilizing a framework that includes front-end development tools, new applications can be created and deployed in a cloud computing environment. According to embodiments of the present invention, FMD method 300 enables new and old applications to work simultaneously and in parallel.

[0041] like Figure 3 As shown, in operation 305, the front-end development computer 130 can receive application microservice requirements corresponding to microservice applications such as new applications. In operation 310, the FMD system 100 can transmit the requirements to the UX development team.

[0042] In operation 315, page-by-page microservice design and development are performed. Operation 315 may include generating a model associated with the microservice design. This approach differs from traditional post-model generation methods. According to embodiments of the invention, independent CSS variables can be initially implemented in the model and then physically imported into the UI toolkit and microservice application. Accordingly, such embodiments enable consistency between the resulting layout and the model. Furthermore, operation 315 allows designers to solve design problems independently. These embodiments also offer advantages in facilitating customization and skinning, where skinning refers to the process of applying a specific set of user experience (UX) rules to each consumer. For example, skinning may involve the application of specific tags, colors, icons, etc.

[0043] Operation 315 includes one or more procedures for creating a set of design tags (i.e., variable constants about a specific component and its use cases). Operation 310 includes creating variable constants that may have been used in a reference component handover library (visual appearance and sensory documentation). See, for example, [link to relevant documentation]. Figure 4 An exemplary model including design tags is shown.

[0044] Operation 315 can include integrating design markup into theme projects, UI element overlays, and framework UI project toolkits. Markup can be used within the main project (framework), as part of a framework project within a UI toolkit project, and ultimately in microservices. A markup approach is used to create markup design sets that interconnect with design components, then use them in other projects and reconfigure them based on changes within those projects. Markup defines one or more sets of variable constants. For example, as shown in the diagram below, markup defines one or more sets of variable constants for components and their use cases (conditions).

[0045] When one or more tags change, they are propagated to the web application and the rendering is altered without requiring additional work from the developers. Using tokenized subprocesses allows designers and developers to implement these changes without hard-coding the widget's style (color, font size, margins, etc.). Furthermore, one or more default values ​​can be provided for one or more tags to allow microservice applications to be executed locally during development.

[0046] In some embodiments, each design markup may be provided in a single file that includes all such design marksup. Any markup update may include performing the following subprocesses: (1) automatically updating the designer widget library; (2) automatically updating the developer theme package; and (3) updating the product with the new style based on the design markup.

[0047] Each model can be implemented by developers in a "handover" mode. In handover mode, information about the design markup used in the model can be transferred. Design markup can be further integrated into theme projects, UI element overlays, and framework UI project toolkits. Markup can be used within the main project (framework), as part of the framework project in the UI toolkit project, and in the final microservices.

[0048] Operation 320 executes front-end microservice development. Operation 320 may include one or more subprocesses for generating microservices. Operation 320 may include one or more subprocesses for page-by-page microservice development, involving the development of microservice software code. Page-by-page microservice development can be configured to begin after the model for each web page view is created. Each page is developed based on an associated model. The model can define the common positioning of elements-components and the components themselves. Using this approach, developers only need to perform the following steps: assembling block component pages, adjusting individual components as needed, and integrating necessary specific parameters. Each component already has functionality and representation specifications (handover, Storybook), requiring no additional development. Operation 320 may also include one or more subprocesses for developing the back-end communication code layer. Furthermore, Operation 320 may include one or more subprocesses for debugging and testing (e.g., creating unit tests, end-to-end tests, etc.).

[0049] In operation 325, the front-end microservice is delivered. Operation 325 may include integrating the front-end microservice and delivering it to the end user, as described below.

[0050] Integration Figure 5 This illustrates a method 500 for deploying new workloads to an integrated FMD framework during APS runtime. Using specific description parameters, new applications can be deployed within a framework that includes APS integration mechanisms. According to embodiments of the invention, FMD method 500 allows new and legacy applications to work simultaneously in parallel.

[0051] like Figure 5 As shown, platform host 530 can receive application metadata corresponding to an application (such as an APS application). Platform host 230 can determine whether to load a framework. Based on this determination, the platform host (e.g., in UX framework module 540) can retrieve and launch a framework as a supplementary layer, which may include a basic abstraction of the operating environment. Therefore, platform host 320 is configured to maintain supplementary support at runtime, including support for application architectures under development. These supplementary features enable a convenient troubleshooting process and minimize downtime for production applications (such as the APS runtime).

[0052] The FMD system 400 can include containers as controls, using a set of web components to represent the application. For example... Figure 6 As shown, in order to present application 610 to a client (e.g., client 160), application 610 itself is represented as a set of web components, such as route 620.

[0053] System 600 includes one or more containers used as controls 615, including a component / route repository for application 610. The route repository 615 acts as a layer above one or more web components, configured to organize the flow and operation of other web components (i.e., routes 620). Routes 620 are available web components whose organizational structure can be implemented by controls 615. The route array 620 includes one or more routes, providing a library of page navigation (routing) within the application (e.g., a web application). Each route 620 is another view that the web application 610 can render (e.g., the current route 622) or hide upon request, such as user navigation. Application 610 may include a specific representation with an internal physical structure. Thus, application 610 itself represents a web component configured to control other web components, i.e., routes 620.

[0054] The routing repository 615 is configured, for example, to connect to the REST-Store layer 630 via an API and act as a layer above one or more web components to organize the processes and operations of other web components. The REST layer 630 can be configured to connect the microservice backend application 640 and the Application Packaging Standard (APS) bus 645. The REST layer 630 can be configured to initiate data requests to and retrieve data from the microservice backend application 640 and the APS bus 645.

[0055] This environment includes a supplementary framework (FW) layer. The FW includes all the resources a new application needs in an isolated stack configuration. Additionally, the same single FW can also be used to create unit tests.

[0056] New application integration may also include creating a compiled bundle for dynamic download to the platform host. The file download to the platform host is also optimized. The file is prepared as a set of asynchronous web components, which can be downloaded piecemeal as a new page representation of the application is opened. Furthermore, the final bundle file does not contain code from the primary vendor library. This code is downloaded directly from the firewall to the host. In some embodiments, the final bundle file includes specific business-layer code that provides only a minimal bundle. This process organization provides optimal and efficient platform host deployment.

[0057] Web components provide an application isolation layer between new and legacy applications and the platform host. This way, new applications do not affect legacy applications; new and legacy applications coexist, achieving optimal platform host load. Debugging can be performed using specific real-time tools, such as Vue DevTools. After generating the microservice frontend, developers receive a feasible draft for future application development, which defines the application structure, development patterns and principles, and unit tests using the framework. Microservice applications can have a strict structure consisting of at least the following components: Coverage - Code coverage information, used to send to SonarQube, and is automatically created after the project is built; Dist - Contains all application artifacts and is automatically created after the project is built; node_modules - All application dependencies; Public - All static files applied: i18n, images, etc.; SRC - Application source code, main working directory; Tests - Application Tests, secondary working directory; Supplementary files from root - Contains various configuration files for application development components (such as Babel, Jason, Config).

[0058] For example, a microservice application under development can specify the following parts: System - These project objects should not be changed; Semi-systemic - These project objects can have their file contents modified in add mode, but their original contents must not be changed; User - These project objects can be modified by the developers at their discretion. Consistency across all applications on the platform can be ensured by simply following general guidelines.

[0059] At runtime, a layer can be provided for communicating with the microservice backend. Specifically, a REST-Store layer can be provided as the application's software and technology layer to interact with the application backend. The REST-Store layer can perform interactions and provide the component's own structure.

[0060] The REST-Store layer can be implemented in different environments. In the local development model, a simulated transport layer is used for development and further unit testing (plugins). The transport layer is a REST (Representational State Transfer) service responsible for executing REST methods such as GET and POST. In production (runtime), a physical transport layer can be utilized. Therefore, developers can use the same code at different stages without having to work differently for different models. This vertical architecture provides greater speed and accuracy for the front-end-back-end connections of applications (microservices), allowing them to operate in the most efficient way.

[0061] This next layer describes all the data for the MOCK system operation, enabling local development without any network access (Internet, corporate network). This layer simulates a connection to the backend, thus allowing local development.

[0062] Testing To ensure code quality, coverage is achieved through testing. Tests can be grouped based on topics (i.e., test objects, test cases, etc.): • Test UI components (components that perform UI tasks - such as rendering some content based on input parameters, and / or performing actions internally and reporting to the outside world, based on internal logic and not dependent on the outside). • Form validation testing; • Storage testing: for components and views; • Use storage testing components: business components, router components; these tests have two variations: ◦ Use component-level mock storage - to isolate the logic of the test component itself; ◦ Simulate complete communication between components and the backend (component-storage bundled integration) - used to test both component logic and storage logic simultaneously.

[0063] For mock types, the same mock system used in local development is employed. Additionally, there is a framework-level testing section, which provides all the resources needed to prepare the testing environment, offering all its features, methods, and approaches. Furthermore, there are helper methods and various utility methods for testing specific underlying components.

[0064] Debugging If necessary, the DevTools standard for views can be used to debug applications, which greatly facilitates and speeds up the process itself. At runtime (platform host), DevTools operates in a constrained mode, due to the deployment and operational architecture of finished applications in this environment.

[0065] For the local development process, a prompting system has been created to collaborate with the mock system: when accessing data backups that do not yet have mocks, no error occurs; instead, a debug message is issued to the console, indicating which REST method, which REST service, and which parameters were called. Mock data for specific REST methods can then be easily created, allowing development to continue in a working environment that fully simulates real conditions. The embodiments described in this document improve the transparency, linearity, and clarity of the development process. All specific development scenarios have been considered for each stage.

[0066] All of this allows engineers to focus solely on creating the core business logic of the application, without being distracted by secondary activities such as component creation, the overall architecture of the application, and the design of its layers (e.g., layers communicating with the backend). These problems are solved systematically, and developers simply need to use it. With this application development approach, vulnerabilities are confined to specific technical layers, making them easy to find quickly and fix based on their nature. Therefore, the development process is extremely efficient.

[0067] For example, one or more computer systems (such as...) can be used. Figure 7 The computer system 700 shown herein is used to implement various embodiments. One or more computer systems 700 can be used, for example, to implement any of the embodiments described herein and combinations and sub-combinations thereof. For example, computer system 700 can be used to implement system 100 for front-end microservice application development and deployment (system 100 includes...). Figure 1 The model 124 and framework 134b), the method 400 for performing microservice front-end development, and / or any other implementation of the embodiments of this disclosure.

[0068] Computer system 700 may include one or more processors (also known as central processing units or CPUs), such as processor 704. Processor 704 may be connected to communication infrastructure or bus 706.

[0069] The computer system 700 may also include user input / output devices 703, such as monitors, keyboards, pointing devices, etc., which can communicate with communication infrastructure 706 through user input / output interfaces 702.

[0070] One or more processors 704 may be graphics processors. In some embodiments, a GPU may be a processor, i.e., a special-purpose electronic circuit designed to process mathematically intensive applications. A GPU may have a parallel architecture, efficiently processing large blocks of data (such as mathematically intensive data common in computer graphics applications), images, videos, etc. in parallel.

[0071] The computer system 700 may also include main memory or primary memory 708, such as random access memory (RAM). Main memory 708 may include one or more levels of cache. Control logic (i.e., computer software) and / or data may be stored in main memory 708.

[0072] The computer system 700 may also include one or more secondary storage devices or memories 710. Secondary memories 710 may include, for example, hard disk drives 712 and / or removable storage devices or drives 714. Removable storage drives 714 may be floppy disk drives, magnetic tape drives, optical disk drives, optical storage devices, backup devices, and / or any other storage devices / drives.

[0073] The portable storage drive 714 can interact with the portable storage unit 718. The portable storage unit 718 may include a computer-usable or readable storage device storing computer software (control logic) and / or data. The portable storage unit 718 may be a floppy disk, magnetic tape, optical disc, DVD, optical storage disc, and / or other arbitrary computer data storage device. The portable storage drive 714 can read from and / or write to the portable storage unit 718.

[0074] Secondary memory 710 may include other means, devices, components, tools, or other means that allow computer system 700 to access computer programs and / or other instructions and / or data. Such means, devices, components, tools, or other means may include, for example, removable storage unit 722 and interface 720. Examples of removable storage unit 722 and interface 720 may include a program box and box interface (such as a program box and box interface in a video game device), a removable memory chip (such as an EPROM or PROM) and associated slot, a memory stick and USB port, a memory card and associated memory card slot, and / or any other removable storage unit and associated interface.

[0075] Computer system 700 may also include a communication or network interface 724. Communication interface 724 enables computer system 700 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively labeled with reference numeral 728). For example, communication interface 724 may allow computer system 700 to communicate with external or remote device 728 via communication path 726, which may be wired and / or wireless (or a combination thereof), and may include any combination of LAN, WAN, Internet, etc. Control logic and / or data may be transmitted to / from computer system 700 via communication path 726.

[0076] The computer system 700 can also be any personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet computer, smartphone, smartwatch or other wearable device, appliance, local Internet of Things and / or embedded system (to name just a few non-limiting examples) or any combination thereof.

[0077] Computer system 700 can be a client or server that accesses or hosts any application and / or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; on-premises or internal software (“internal” cloud solutions); “as-a-service” models (e.g., Content as a Service (CaaS), Digital Content as a Service (DCaaS), Software as a Service (SaaS), Managed Software as a Service (MSaaS), Platform as a Service (PaaS), Desktop as a Service (DaaS), Framework as a Service (FaaS), Backend as a Service (BaaS), Mobile Backend as a Service (MBaaS), Infrastructure as a Service (IaaS), etc.); and / or hybrid models, including any combination of the foregoing examples or other service or delivery paradigms.

[0078] Any available data structures, file formats, and schemas in the computer system 700 may be derived from standards including, but not limited to, JavaScript Object Notation (JSON), Extensible Markup Language (XML), YAML, Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), message packets, XML User Interface Language (XUL), or any other functionally similar representation (alone or in combination). Alternatively, proprietary data structures, formats, or schemas may be used individually or in combination with known or open standards.

[0079] In some embodiments, a tangible non-transitory device or article of manufacture that includes a tangible non-transitory computer-usable or readable medium storing control logic (software) may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 700, main memory 708, secondary memory 710, and mobile storage units 718 and 722, as well as tangible articles of manufacture implementing any combination thereof. When such control logic is executed by one or more data processing devices (such as computer system 700), it can cause such data processing devices to operate as described herein.

[0080] It should be understood that the operations shown in the exemplary methods are not exhaustive, and other operations may be performed before, after, or in between any of the shown operations. In some embodiments of this disclosure, operations may be performed in different orders and / or in different ways.

[0081] It should be understood that the detailed description section, rather than the summary and abstract section, is intended to interpret the claims. The summary and abstract section may set forth one or more, but not all, exemplary embodiments of the invention conceived by the inventors, and is therefore not intended to limit the invention or the appended claims in any way.

[0082] The invention has been described above by way of illustrating the functional building blocks that implement specified functions and their relationships. For ease of description, the boundaries of these functional building blocks are arbitrarily defined herein. Alternative boundaries can be defined as long as the specified functions and their relationships are properly performed.

[0083] The specific embodiments described above will fully reveal the overall nature of the invention. Without departing from the overall concept of the invention, others can easily modify and / or adapt them for various applications (such as the specific embodiments) by applying the common knowledge of those skilled in the art, without excessive experimentation. Therefore, based on the teachings and guidance presented herein, such modifications and adaptations are intended to fall within the meaning and scope of equivalents of the embodiments disclosed herein. It should be understood that the wording or terminology herein is for descriptive purposes and not restrictive, and thus the terminology or terminology in this specification should be interpreted by those skilled in the art based on the teachings and guidance.

[0084] The breadth and scope of this invention should not be limited by any of the exemplary embodiments described above, but should be defined solely by the appended claims and their equivalents.

Claims

1. A method for creating and integrating a frontend microservice application to a host platform, wherein the microservice applications of the host platform including the frontend microservice application and backend microservice applications, the method comprising: communicating a requirement package corresponding to the microservice frontend application to a UX development platform; generating a model package by the UX development platform based on the requirement package; communicating the model package to a microservice frontend development platform to generate a microservice frontend application; generating a microservice frontend application package by the microservice application development platform based on the model package; and integrating the microservice frontend application package, wherein the application is integrated with the microservice frontend application based on the requirement package.

2. The method of claim 1, wherein, Generating the model package based on the requirement package further comprises generating a token package including one or more reusable design tokens.

3. The method of claim 2, wherein, The token package is configured to be utilized by one or more other frontend microservice applications.

4. The method of claim 1, wherein, Generating the model package based on the requirement package further comprises generating handoff documents corresponding to a reference component library.

5. The method of claim 1, wherein, Generating the microservice frontend application package based on the model package further comprises implementing microservice code with one or more framework documents.

6. The method of claim 1, wherein, Generating the model package based on the requirement package further comprises generating one or more Storybooks by the UX development platform based on the requirement package.

7. The method of claim 6, wherein, Generating the model package based on the requirement package further comprises publishing the Storybooks by the UX development platform.

8. A system for creating and integrating a front-end microservice application to a host platform, wherein, the microservice applications of the host platform including the frontend microservice application and backend microservice applications, the system comprising a processing system, one or more processors of the processing system executing computer executable instructions, the computer executable instructions causing the processing system to: communicate a requirement package corresponding to the microservice frontend application to a UX development platform; generate a model package by the UX development platform based on the requirement package; communicate the model package to a microservice frontend development platform to generate a microservice frontend application; generate a microservice frontend application package by the microservice application development platform based on the model package; and integrate the microservice frontend application package, wherein the application is integrated with the microservice frontend application based on the requirement package. The computer executable instructions cause the processing system to generate a token package including one or more reusable design tokens.

9. The system of claim 8, wherein, The token package is configured to be utilized by one or more other frontend microservice applications.

10. The system of claim 9, wherein, The computer executable instructions cause the processing system to generate handoff documents corresponding to a reference component library.

11. The system of claim 8, wherein, The computer executable instructions cause the processing system to implement microservice code with one or more framework documents.

12. The system of claim 8, wherein, The computer executable instructions cause the processing system to generate one or more Storybooks by the UX development platform based on the requirement package.

13. The system of claim 8, wherein, The computer executable instructions cause the processing system to publish the Storybooks by the UX development platform.

14. The system of claim 13, wherein, ​ 15. A computer program product for creating and integrating a frontend microservice application to a host platform, the computer program comprising computer readable program code executable by at least one processor when retrieved from a non-transitory computer readable medium, the program code containing instructions configured to cause the processor to: communicate a requirements package corresponding to the microservice frontend application to a UX development platform; generate a model package based on the requirements package by the UX development platform; communicate the model package to a microservice frontend development platform to generate a microservice frontend application; generate a microservice frontend application package based on the model package by the microservice application development platform; and integrate the microservice frontend application package, wherein the microservice frontend application is utilized to integrate an application based on the requirements package. the computer executable instructions cause the processing system to generate a token package comprising one or more reusable design tokens.

16. The computer program product of claim 16, wherein, the token package is configured to be utilized by one or more other frontend microservice applications.

17. The computer program product of claim 15, wherein, the computer executable instructions cause the processing system to implement microservice code with one or more framework documents.

18. The computer program product of claim 15, wherein, the computer executable instructions cause the processing system to generate one or more Storybooks based on the requirements package by the UX development platform.

19. The computer program product of claim 15, wherein, the computer executable instructions cause the processing system to publish the Storybooks by the UX development platform.

20. The computer program product of claim 19, wherein, ​

Images