SYSTEM AND METHOD FOR CREATING FRONT-END WEB APPLICATIONS FOR CLOUD COMPUTING PLATFORMS - Patent application writer

Abstract

A system and method for creating and integrating a microservices front-end application into a host platform, the system and method may include communicating a requirements package corresponding to the microservices front-end application to a UX development platform, generating, by the UX development platform, a mockup package based on the requirements package, communicating the mockup package to a microservices front-end development platform, the microservices front-end application, generating, by the microservices application development platform, a microservices front-end application package based on the mockup package, and integrating the microservices front-end application package, wherein a vendor application is integrated using the microservices front-end application based on the requirements package.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) 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 No. 17 / 824,563, filed May 25, 2022, the disclosure of which is incorporated herein by reference.

[0002] The present invention relates to methods and standards for application packaging and integration, and more particularly to application resource integration and deployment to the cloud.

[0003] (background) Computer systems present several challenges when it comes to developing and installing updates and patches for hosted web applications. Software-as-a-Service (SaaS) web applications are integrated into the system by the vendor using special delivery and installation packages. However, if the vendor needs to integrate / deploy the application to the cloud, all of the integration work must be repeated several times for each host or hosting platform. Hosts and hosting platforms have applications that control the host or hosting platform. These applications make integrating external (third-party) applications or web services very difficult and expensive.

[0004] Currently, the host and integration of applications into the hosting platform is performed by the controller. In the case of cloud systems, the cloud (or cloud server) is the combination of the host provider's software and hardware, which provides the functionality of external applications within the client's account.

[0005] In the field of cloud computing platforms, inefficiencies exist in creating and deploying client applications in conjunction with platform-style operations. For example, cloud computing platforms may encounter issues related to efficient application development and / or host deployment. Software-as-a-Service (SaaS) web applications are typically developed in close coordination with the platform host. All processes related to a new application being developed are tightly coupled to the deployment of the platform host stack. Such an approach has resulted in inconveniences and time losses common to the context related to the need to solve application problems at a core level.

[0006] A major drawback of the prior art is that creating and deploying new applications requires the platform host to communicate packages that have an indeterminate test environment within the package during application development. Furthermore, the prior art requires excessive deployment time and requires a continuous internet connection during application creation. Therefore, there is a need in the art for an efficient and inexpensive way to integrate applications, application updates, and patches into a cloud platform host. Summary of the Invention

[0007] Embodiments described herein provide for front-end microservices application development. Specifically, embodiments disclose systems and methods for creating and integrating a microservices front-end application into a host platform. The systems and methods can include communicating a requirements package corresponding to the microservices front-end application to a UX development platform, generating, by the UX development platform, a mockup package based on the requirements package, communicating the mockup package to a microservices front-end application development platform, generating, by the microservices front-end application development platform, a microservices front-end application package based on the mockup package, and integrating the microservices front-end application package, wherein a vendor application is integrated using the microservices front-end application based on the requirements package.

[0008] Traditionally, front-end developers can encounter several challenges when developing microservices in isolation from the overall platform host for use on a platform host as part of a multi-microservice environment. Developing microservices through a platform host incurs additional development costs, including deployment and sandbox adjustments (i.e., for the stack and the platform host). Even minor changes to the microservice code can require deploying all code to the stack again, resulting in transfer losses. Front-end developers are typically provided with requirements for UI (user interface) elements (buttons, fonts, colors, and other things) and must implement them from scratch each time. Developers must consider many aspects, including how the microservices should appear in relation to the core business task itself—i.e., the application itself—and how the microservices can appear and function in a common interface (platform host) and conform to a single experience.

[0009] In some embodiments, the FMD method and system can include a local microservice development mode that functions independently of the platform host, as described in detail in U.S. Patent Application No. 17 / 824,563, which is incorporated herein by reference in its entirety. In some embodiments, the FMD method and system can additionally include a process for mockup and tokenization, i.e., tokens maintained in a unified library of widgets that are supported independently of a specific application and available to front-end developers. In some embodiments, the FMD method and system can further include interactions between microservices and the outside world. For example, the FMD method and system can enable communication between front-end microservices under development and other microservices, the host itself, a representational state transfer (REST) ​​request system, unit testing, application debugging, simulation of communication before host deployment, etc.

[0010] In some embodiments, the FMD method and system may further include the use of a specific cloud framework to provide front-end developers with everything they need as an integrated part of the process and achieve the resulting application. The framework pre-separates new microservices (web applications) into specific program layers. According to the embodiments described herein, task resolution is effectively achieved by well-organizing communication between the different "blocks" involved in the entire web application creation process. This results in faster application preparation, improved testing and debugging, and reduced application development costs.

[0011] Such an approach reduces the time that front-end developers spend on new microservices and allows developers with lower skills to work on them. The FMD system and method only require developers to combine software layers, perform the debugging process, and then deploy executable microservices to the stack and platform host. The vertical integration details of a specific REST store provide an efficient connection between the front-end and back-end of developed microservices, as described below, and allow developers to use the same code in modes such as local development (through data transfer level emulation), unit testing, and production (runtime).

[0012] According to an embodiment of the present invention, a system and method for front-end microservices development (FMD) are provided to improve the application development process. The FMD solution effectively addresses the above-mentioned technical challenges and provides, at the core level of the platform host, an independent application creation process and efficient application deployment to the platform host with minimal downtime.

[0013] An FMD system and method are provided for creating, sharing, and integrating vendor applications. The system and method for application development and deployment can include communicating, by a host platform, a framework package corresponding to an application framework, the framework package including software abstractions for providing generic functionality in the development of the vendor application, receiving, by the host platform, an application package corresponding to the vendor application, the application package including a plurality of metadata files, control method descriptions, and content files, and integrating the application package to generate an integration of the vendor application based on the application framework.

[0014] According to some embodiments, the FMD system and method differ from the prior art in that the tight connection between the application and the host is broken during application development. The host "adopts" an already operational application that is easily deployed. In such a scenario, a constant Internet connection during application development is not required. Due to the operation of the host, prior systems and methods can require several hours just to begin the process of developing a new application. According to exemplary embodiments, the platform host is decoupled from the labor-intensive application development process. New applications can be created and tested before deployment to the host, enabling the creation of reliable applications at the time of deployment. Furthermore, the need to fix defects at the host's core level during application development is eliminated, solving another problem in the prior art. The FMD system and method enables efficient application creation in terms of speed, reliability, and resource conservation. [Brief explanation of the drawings]

[0015] [Figure 1] 1 illustrates an example operating environment for a system for front-end microservices development (FMD), according to some embodiments. [Figure 2] 1 illustrates an FMD system according to some embodiments. [Figure 3] 1 illustrates a methodology for developing and delivering microservice front-ends in an FMD system, according to some embodiments. [Figure 4] 1 illustrates mockup and tokenization in an FMD, according to some embodiments. [Figure 5] 1 illustrates an FMD system according to some embodiments. [Figure 6] 1 illustrates the integration of platform-hosted applications within an FMD system, according to some embodiments. [Figure 7] 1 illustrates an example of a computing device in accordance with an illustrative embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0016] For the purposes of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same, it being understood, however, that no limitation of the scope of the disclosure is intended thereby.

[0017] The present embodiments may be implemented in hardware, firmware, software, or any combination thereof. The present embodiments may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and others. Furthermore, firmware, software, routines, and instructions may be described herein as performing particular actions. However, it should be understood that such description is merely for convenience and that such actions are actually the results obtained by a computing device, processor, controller, or other device executing the firmware, software, routines, instructions, etc.

[0018] It should be understood that the acts shown in the example methods are not exhaustive and that other acts may similarly be performed before, after, or between any of the acts shown. In some embodiments of the present disclosure, acts may be performed in different orders and / or variations.

[0019] (Microservice creation) The embodiments described herein relate to FMD methods and systems that can include a local microservice development mode that functions independently of the platform host, as described in detail in U.S. Patent Application No. 17 / 824,563, which is incorporated herein by reference in its entirety. In some embodiments, the FMD methods and systems can additionally include processes for mockup and tokenization, i.e., tokens maintained in a unified library of widgets that are supported independently of a specific application and available to front-end developers. In some embodiments, the FMD methods and systems can further include interactions between microservices and the outside world. For example, the FMD methods and systems can enable communication between a front-end microservice under development and other microservices, the host itself, a Representational State Transfer (REST) ​​request system, unit testing, application debugging, communication simulation before host deployment, and the like.

[0020] To address the above-mentioned technical problems, a front-end microservice development (FMD) system and method are provided. The FMD system and method provide a specific layer for vendor microservice application front-ends, providing front-end developers with all the necessary resources and returning the application as an integrated part of the process. FMD facilitates task resolution and effectively organizes and enables communication between different components of the web application creation process. The FMD system and method enable timely application preparation and improved testing and debugging. Thus, better end-user application operability is achieved while reducing application development costs. Front-end developers are enabled to properly combine software layers, perform debugging processes, and deploy, while minimizing the time and effort spent on developing new microservices. The FMD system and method includes vertical integration details for a specific REST store to provide a more effective connection between the front and back ends of microservices, allowing developers to use a single code compilation for modes such as local development (at an emulated data transfer level), unit testing, and runtime (i.e., production environment).

[0021] Figure 1 illustrates an FMD system according to some embodiments. As shown in Figure 1, FMD system 100 provides an ecosystem for multiple projects that can be separated based on functionality, responsibilities, and teams, for example. FMD system 100 comprises a microservice requirements package 110, a UX development platform 120, a microservices platform 130, and implementation (to the end user) by a platform host 140.

[0022] As shown in FIG. 1 , a UX development platform 120 can receive application microservice requirements 110 corresponding to a microservice application, such as a new application. The UX system 100 can send the requirements to a UX development team 122. The UX development platform enables the UX development team 122 to generate one or more mockups 124 associated with the application microservice requirements 110. This is a different approach than traditional methodologies for generating mockups post hoc. According to embodiments, separate stylesheet language (e.g., Cascading Style Sheets, or CSS) variables can be implemented in the mockup first and then physically imported into the UI kit and into the microservice application. According to embodiments, separate SASS CSS (SCSS) variables can be implemented and imported. Thus, such embodiments enable parity between the resulting layout and the mockup.

[0023] The UX development platform 120 enables the creation of a set of design tokens, i.e., variables-constants, for specific components and their use cases. Operation 310 includes the creation of variables-constants that can already be used in a handoff (visual look-and-feel document) gallery of reference components. For example, referring to FIG. 4 , an exemplary mockup including design tokens is illustrated. The mockup is configured to be developed as a page-by-page application. The UX development platform 120 enables developers to easily and intuitively create, view, and modify variables-constants, which can be based on the handoff gallery of reference components. According to an embodiment, the FMD system 100 facilitates customization and skinning, where skinning refers to the process of applying one or more specific user experiences (UX) for each consumer. For example, skinning can involve applying specific tokens, colors, icons, etc.

[0024] The FMD system 100 allows one or more mockups 124 to be submitted to and / or retrieved from a microservices platform 130. The microservices development platform 130 allows one or more developers 132 to utilize the mockups 124 to generate a microservices front-end application 134 related to the application microservice requirements 110. The microservices development platform 130 performs page-by-page microservice design and development. The microservices development platform 130 includes a testing module 136 that further enables the developers 132 to perform unit testing, end-to-end (e2e) testing, etc., and debug the microservices front-end application 134.

[0025] As shown, the creation of microservices front-end applications on the development platform 130 is separate from the platform host 140 itself. According to an exemplary embodiment, one or more frameworks link applications on the development platform 110 to applications on the platform host (130) (production environment). That is, the frameworks connect the respective applications to each other. The frameworks provide the basic templates needed for application and testing on the development platform 110. The frameworks also provide the specific means needed to integrate and deploy applications on the platform host (hosting cloud) 130.

[0026] In an exemplary embodiment, the microservices development platform 130 enables the generation of a microservices front-end application 134 based on application code 134a and a framework 134b. The application code 134a may include code written by a developer. The framework 134b (e.g., VUE) may provide a software abstraction for providing general-purpose functionality that can be selectively adapted and implemented by the application code 134a to provide application-specific software, such as for building a user interface. The framework 134b may provide this abstraction built on top of standard programming languages ​​(e.g., HTML, CSS, JavaScript, etc.) to provide a declarative, component-based programming model that permits the efficient development of application-specific software, such as user interfaces, whether simple or complex.

[0027] When the FMD 100 is configured to deploy an application 134, the development platform 110 can generate an application bundle that implements the application 134 and framework 104 as a standalone, all-in-one container. According to an exemplary embodiment, a developer 132 (e.g., a cloud application vendor) can bundle the application code 134a and framework 134b according to the APS. The format of the bundle depends on the recipient, such as the platform host 130. If the recipient is a standard Windows desktop, the software can be packaged using a standard installer, with the file having the extension *.exe or *.msi. The installer includes unpacking rules, such as user dialogs, registry writes, update checks, etc. In the case of the APS, the bundle can have the extension app.zip and include metadata, scripts, and the software code itself.

[0028] The exemplary development application 102 is transferred to the platform host 140 via an application bundle. The microservice front-end application 134 is generated within the platform host 140 based on the front-end application 134a and the framework 134b. The platform host 140 may include a controller, i.e., an application packaging controller, having a runtime module configured to distribute the microservice front-end application 134 to one or more end users. The APS is a specification that defines the lifecycle of the microservice front-end 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, functionality, update, and deletion. The APS may include an application programming interface (API) for accessing APS functionality from program code or via http / https requests. The APS provides efficient integration of SaaS web applications, such as the microservice front-end application 134, into the cloud. According to an exemplary embodiment, an APS module 138 (i.e., a controller) is integrated into the software hosting platform of the hosting cloud (platform host 140) to enable the application to function according to the APS. The APS module 138 acts as a connector for controlling the microservice front-end application 134 .

[0029] (Mockup generation) 2 illustrates a UX development platform 120 of the FMD system 100, according to some embodiments. As shown in FIG. 2, the FMD system 100 provides an ecosystem for multiple projects that can be separated based on functionality, responsibilities, teams, for example. The FMD system 100 comprises a microservices requirements package 110, a UX development platform 120, a microservices platform 130, and an implementation (to the end user) 140.

[0030] As shown in Figure 2, a UX development platform 120 can receive application microservice requirements 110 corresponding to a microservice application, such as a new application. Based on the microservice requirements 110, the UX development platform enables the implementation of one or more design tokens 210. Tokenization refers to the variable-constant relationship between components and cases (conditions). A set of token designs is created that are interconnected with the design components, which can then be used for other projects and re-executed based on changes in the project.

[0031] The UX development platform 120 includes a handoff 230 document, which may include a gallery of reference components. The UX development platform 120 can enable a handoff mode in a mockup to facilitate sharing details about design tokens used in the mockup. The handoff 230 can include each detail and digital asset needed for the development team to realize the microservices front-end design.

[0032] The UX development platform 120 enables one or more development UX-UI themes 220 to be utilized at handoff 230 when implementing one or more development UX-UI theme kits 220 based on the microservice requirements 110. SCSS variables can be physically imported into the UI theme kits 220 to minimize mockup inconsistencies, address design issues, and allow customization and skinning.

[0033] The UX development platform enables the implementation of one or more design storybooks 250. The storybooks 250 allow UX developers to develop components, document the components for reuse, visually test such components, and capture state to discover inconsistencies. Additionally, the FMD system 100 enables the UX development platform 120 to publish the storybooks 250 as one or more mockups 124 that are published to be implemented by the microservices development platform 140.

[0034] 3 illustrates an FMD methodology 300 for developing and integrating new front-end microservices that are integrated at runtime. By utilizing a framework that provides a means for front-end development, new applications can be created and deployed in cloud computing environments. According to an embodiment, the FMD method 300 allows new and old applications to run simultaneously in parallel.

[0035] 3, in operation 305, the front-end development computer 130 may receive application microservice requirements corresponding to a microservices application, such as a new application. In operation 310, the FMD system 100 may send the requirements to a UX development team.

[0036] In operation 315, page-by-page microservice design development occurs. Operation 315 can include generating mockups related to the microservice design. This is a different approach from traditional methodologies for generating mockups later. According to embodiments, separate SCSS variables can be implemented in the mockup first and then physically imported into the UI kit and into the microservice application. Thus, such embodiments enable parity between the resulting layout and the mockup. Additionally, operation 315 can allow designers to address design issues themselves. Embodiments provide another advantage by facilitating customization and skinning, which refers to the process of applying a specific set of user experience (UX) rules unique to each consumer. For example, skinning can involve applying specific tokens, colors, icons, etc.

[0037] Act 315 involves one or more processes for creating a set of design tokens, i.e., variables-constants for specific components and their use cases. Act 310 involves creating variables-constants that can already be used in the handoff (visual look and feel document) gallery of the referenced component. For example, referring to Figure 4, an exemplary mockup including design tokens is illustrated.

[0038] Operation 315 may include integrating the design tokens into theme projects, UI element overrides, and framework UI project KIT. Tokens can be used in the main project (framework), in UI KIT projects as part of the framework project, and ultimately in microservices. Tokenization techniques are used to create and interconnect design components, which can then be used for other projects and reconfigured based on project changes. Tokens define one or more variable-constant sets. For example, as illustrated (see image below), tokens define one or more variable-constant sets for components and the cases (conditions) in which they are used.

[0039] When one or more tokens are changed, they are sent to the web application and the representation is changed without any developer intervention. The use of the tokenization subprocess allows designers and developers to implement these changes without hard-coding widget styles (color, font size, margins, etc.). Additionally, one or more tokens can have one or more default values, allowing microservice applications to run locally during development.

[0040] In some embodiments, each design token can be provided in a single file containing all such design tokens. Token updates can include the following sub-processes: (1) automatically updating the designer widget library, (2) automatically updating the developer theme package, and (3) performing product updates with new styles according to the design tokens.

[0041] Each mockup can be implemented in "hands-off" mode by a developer, who can communicate information about the design tokens used in the mockup. The design tokens can be further integrated into theme projects, UI element overrides, and framework UI project KIT. The tokens are used in the main project (framework), in the UI KIT project as part of the framework project, and finally in the microservices.

[0042] In operation 320, development of a front-end microservice occurs. Operation 320 can include one or more subprocesses for microservice generation. Operation 320 can include one or more subprocesses for page-by-page development of a microservice, which involves developing software code for the microservice. Page-by-page microservice development can be configured to begin after mockups are created for each web screen view. Each page is developed based on the associated mockup. The mockup can define common positioning of elements—components—and the components themselves. According to this methodology, developers only need to build a page of blocks—components, adjust each component according to requirements, and perform steps to integrate specific parameters as needed. Each component already has functionality and representation (handoff, storybook), and no additional development is required. Operation 320 can also include one or more subprocesses for developing a code layer for communication with the backend. In addition, operation 320 can include one or more subprocesses for debugging and testing (e.g., creating unit tests, end-to-end tests, etc.).

[0043] The delivery of the front-end microservices occurs in operation 325. Operation 325 may include integrating and delivering the front-end microservices to end users, as described below.

[0044] (Integrated) 5 illustrates an FMD methodology 500 for deploying new workloads to a target at runtime. Using specific description parameters, new applications can be deployed using a framework that provides a means for APS integration. According to an embodiment, the FMD method 500 allows new and old applications to run simultaneously in parallel.

[0045] As shown in FIG. 5, the platform host 530 can receive application metadata corresponding to an application, such as an APS application. The platform host 530 can determine whether a framework is loaded. Based on the determination, the platform host (e.g., the UX framework module 540) can retrieve and launch the framework as an additional layer that can include a basic abstraction of the operating environment. Thus, the platform host 320 is configured to maintain additional support at runtime, including support for application architectures under development. These additional capabilities enable a convenient debugging process and minimize downtime for production applications, such as the APS runtime.

[0046] The FMD system 400 can include a container as a controller that represents an application that utilizes a set of web components. As shown in Figure 6, to render an application 610 to a client (e.g., client 160), the application 610 represents itself as a set of web components, such as a route 620.

[0047] The system 600 includes one or more containers that function as a controller 615, which includes a component / route store for the application 610. As a root store, the controller 615 acts as a top layer for one or more web components configured to organize the flow and behavior of other web components, i.e., roots 620. A root 620 is a web component that can be provided with the organization implemented by the controller 615. The root array 620 includes one or more roots and provides a library for page navigation (roots) in an application, e.g., a web application. Each root 620 is a separate view that the web application 610 can render or hide (e.g., current root 622) as required, e.g., by user navigation. The application 610 can include a specific representation with an internal physical structure. Thus, the application 610 itself represents a web component, i.e., a root 620, configured to control other web components.

[0048] The root store 615 is configured to connect to a REST store layer 630, for example via an API, and serve as a super layer for one or more web components configured to orchestrate the flow and behavior of other web components. The REST layer 630 can be configured to connect to a microservices backend application 640 and an application packaging standard (APS) bus 645. The REST layer 630 can be configured to make data requests to and retrieve data from the microservices backend application 640 and the application packaging standard (APS) bus 645.

[0049] This environment comes with an additional framework (FW) layer that provides everything needed for a new application in a decoupled stack, plus the same single FW can be used for creating unit tests.

[0050] The integration of a new application can further include creating a compiled bundle file that is dynamically downloaded to the platform host. Furthermore, file download to the platform host is optimized. The file is prepared as a set of asynchronous web components that can be downloaded piece by piece when opening a new page representation of the application. At the same time, the final bundle file does not include code from primary vendor libraries. This code is downloaded directly from the FW to the host. In some embodiments, the final bundle file includes only specific business layer code, achieving the smallest bundle file size. Such process orchestration provides optimal and efficient platform host deployment.

[0051] The use of web components provides a new layer of application that is decoupled from the old application and from the platform host. In this way, the new application does not affect the old application and exists under the optimal platform host load. The debugging process can be done through the use of specific real-time means such as Vue Devtools. After the microservice frontend is generated, developers can obtain a executable draft for future application development, which determines the application structure, development patterns and principles, and unit testing through the use of frameworks. A microservice application can have a solid structure consisting of at least the following elements: Coverage - Code coverage information, used to send to SonarQube. Created automatically after building the project. Dist - Contains all the artifacts of the application. It is created automatically after building the project. node_modules - All your application's dependencies. Public - All application static files. i18n, images, etc. SRC - Application source code. Main working folder. Tests - Application tests. Secondary main working folder. Additional files from the root - Contains various configuration files for application development components (e.g., Babel, Jason, Config).

[0052] For example, a microservices application under development can specify the following parts: System - These project objects should not be modified. Semi-systemic - These project objects can modify the contents of files in append mode, but cannot modify the original. User - These project objects can be modified at the developer's discretion. There are only general guidelines that can be followed to ensure consistency across all applications in the platform.

[0053] At runtime, there can be a layer for communicating with the microservices backend. Specifically, the software and technology layer of the application can be a REST store layer that provides the interaction with the application backend and can provide the structure for the components themselves.

[0054] The REST store layer can be implemented in different environments. In local development mode, an emulated transport level is used for development and further unit testing (plugging). The transport level is a REST (Representational State Transfer) service responsible for executing REST methods such as GET, POST, etc. In the production environment (runtime), the physical transport level can be utilized. Thus, developers can use the same code at different stages without the need to do things in different modes, different ways. Such vertical integration provides faster speed and greater accuracy in connecting the front end and back end of an application (microservices), and does it in the most efficient way.

[0055] After the local environment is set up, the MOCK system contains all the data and configuration necessary to support full local development without requiring a network connection (e.g., to the Internet or a corporate backend). This layer simulates a connection to the backend, enabling local development.

[0056] (test) To ensure the quality of the code, it needs to be covered by tests. Tests can be categorized into several groups based on what they cover (e.g. test subjects, cases, etc.). UI Component Testing {Components that perform a UI task - for example, render something according to input parameters and / or take some action internally and report it to the external world, following their internal logic and having no external dependencies. · Testing formats with validation Store testing: for components and views Testing components with stores: business components, router components. These come in two variations. By mocking the store at the component level - used to test the logic of the component itself in isolation. By simulating the entire communication between the component and the backend (component store bundle integration) - used to test both the component logic and the store logic together with each other.

[0057] Mock types use the same mocking system as for local development. There is also a section for testing at the framework level, which has everything to prepare the environment for testing. This environment provides all the features, methods and techniques. In addition, there are various utility methods, as well as support methods for testing some specific basic components.

[0058] (debugging) If desired, applications can be debugged using common development tools for the views, which greatly simplifies and speeds up the process. At runtime (platform host), development tools operate in a limited mode due to the architecture of application deployment and operation completed in this environment.

[0059] For the local development process, a prompt system is created to work with the mock system, so that accessing a data backup for which no mock exists yet does not result in an error, but instead a debug message is issued to the console for which REST method and which REST service was started and with which parameters, and then mock data for the specific REST method can be created to facilitate continuing development with a complete simulation of working in a real situation. The embodiments described herein improve the transparency, linearity, and clarity of the development process. For each stage, all specific development cases are considered.

[0060] All this allows engineers to focus solely on creating the application's core business logic, without being distracted by secondary activities such as creating components, designing the application's overall architecture, and its individual layers (for example, layers for communication with the backend). All of this has already been systematically solved, all that remains is to use it. In such an application development approach, bugs are localized to specific technology layers, making them easier to find quickly and fix according to their nature. This makes the development process highly efficient.

[0061] Various embodiments may be implemented using one or more computer systems, such as, for example, computer system 700 shown in FIG. 7. One or more computer systems 700 may be used, for example, to implement any of the embodiments described herein, as well as combinations and subcombinations thereof. For example, computer system 700 may be used to implement system 100 for developing and deploying microservices front-end applications, including mockup 124 and framework 134b of FIG. 1, method 400 for performing microservices front-end development, and / or other implementations of the disclosed embodiments.

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

[0063] The computer system 700 may also include user input / output devices 708 , such as a monitor, keyboard, pointing device, etc., which may communicate with the communications infrastructure 706 through the user input / output interface 702 .

[0064] One or more of the processors 704 may be a graphics processing unit (GPU). In some embodiments, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. A GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common in computer graphics applications, images, video, etc.

[0065] The computer system 700 may also include a main or primary memory 708, such as random access memory (RAM). The main memory 708 may include one or more levels of cache. The main memory 708 may store control logic (i.e., computer software) and / or data.

[0066] Computer system 700 may also include one or more secondary storage devices or memories 710. Secondary memory 710 may include, for example, a hard disk drive 712 and / or a removable storage device or drive 714. Removable storage drive 714 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, a tape backup device, and / or other storage device / drive.

[0067] The removable storage drive 714 may interact with a removable storage unit 718. The removable storage unit 718 may include a computer-usable or readable storage device having computer software (control logic) and / or data stored thereon. The removable storage unit 718 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and / or other computer data storage device. The removable storage drive 714 may read from and / or write to the removable storage unit 718.

[0068] Secondary memory 710 may include other means, devices, components, means, or other approaches for allowing computer programs and / or other instructions and / or data to be accessed by computer system 700. Such means, devices, components, means, or other approaches may include, for example, removable storage unit 722 and interface 720. Examples of removable storage unit 722 and interface 720 may include a program cartridge and cartridge interface (such as found in a video game device), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and / or other removable storage unit and associated interface.

[0069] Computer system 700 may further include a communications or network interface 724. Communications interface 724 may enable computer system 700 to communicate and interact with a combination of external devices, external networks, external entities, etc. (individually and collectively referred to by reference numeral 728). For example, communications interface 724 may enable computer system 700 to communicate with external or remote devices 728 via communications path 726, which may be wired and / or wireless (or a combination thereof) and may include a combination of a LAN, a WAN, the Internet, etc. Control logic and / or data may be transmitted to and from computer system 700 via communications path 726.

[0070] Additionally, computer system 700 may be a personal digital assistant (PDA), a desktop workstation, a laptop or notebook computer, a netbook, a tablet, a smartphone, a smartwatch or other wearable, an appliance, part of the Internet of Things, and / or an embedded system, or any combination thereof, to name a few non-limiting examples.

[0071] The computer system 700 may be a client or server that accesses or hosts applications and / or data through a delivery paradigm, including, but not limited to, remote or distributed cloud computing solutions, local or on-premise software ("on-premise" cloud-based 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)), and / or hybrid models including combinations of the foregoing examples or other service or delivery paradigms.

[0072] Applicable data structures, file formats, and schemas in computer system 700 may be derived from standards including, but not limited to, JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or other functionally similar representations, alone or in combination. Alternatively, proprietary data structures, formats, or schemas may be used, either exclusively or in combination with known or open standards.

[0073] In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer-usable or readable medium upon which control logic (software) is stored may also be referred to herein as a computer program product or program storage device, including, but not limited to, computer system 700, main memory 708, secondary memory 710, and removable storage units 718 and 722, as well as tangible articles of manufacture embodying combinations of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 700), may cause such data processing devices to operate as described herein.

[0074] It should be understood that the acts shown in the example methods are not exhaustive and that other acts may similarly be performed before, after, or between any of the acts shown. In some embodiments of the present disclosure, acts may be performed in a different order and / or altered.

[0075] It is understood that the Detailed Description section, and not the Abstract, is intended to be used to interpret the claims. The Abstract section may describe one or more, but not all, example embodiments of the invention as contemplated by the inventors, and is therefore not intended to limit the invention and the appended claims in any way.

[0076] The present invention has been described above with the aid of functional building blocks illustrating the implementation of certain functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for convenience of description. Alternative boundaries may be defined so long as the certain functions and relationships thereof are properly performed.

[0077] The foregoing description of specific embodiments fully discloses the general nature of the present invention, and by applying the knowledge of those skilled in the art, such specific embodiments can be readily modified and / or adapted for various uses without undue experimentation and without departing from the general concept of the present invention. Such adaptations and modifications are therefore intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It should be understood that the phraseology or terminology used herein is for the purpose of description and not of limitation, and should therefore be interpreted in light of the teaching and guidance provided by those skilled in the art.

[0078] The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

1. 1. A method for creating and integrating a microservices front-end application into a host platform, the microservices application of the host platform comprising the microservices front-end application and a back-end microservices application, the method comprising: Communicating a requirements package corresponding to the microservices front-end application to a UX development platform; generating, by the UX development platform, a mockup package based on the requirements package; Communicating the mockup package to a microservices front-end development platform, a microservices front-end application; generating, by the microservice application development platform, a microservice front-end application package based on the mockup package; integrating the microservices front-end application package, wherein an application utilizes and integrates the microservices front-end application based on the requirements package.

2. The method of claim 1 , wherein generating the mockup package based on the requirements package further comprises generating a token package comprising one or more reusable design tokens.

3. 3. The method of claim 2, wherein the token package is configured to be usable by one or more other microservice front-end applications.

4. The method of claim 1 , wherein generating the mockup package based on the requirements package further comprises generating a handoff document corresponding to a gallery of reference components.

5. 10. The method of claim 1, wherein generating the microservice front-end application package based on the mockup package comprises implementing microservice code with one or more framework documents.

6. The method of claim 1 , wherein generating the mockup package based on the requirements package further comprises generating, by the UX development platform, one or more storybooks based on the requirements package.

7. The method of claim 6 , wherein generating the mockup package based on the requirements package further comprises publishing the storybook by the UX development platform.

8. 1. A system for creating and integrating a microservices front-end application into a host platform, wherein the microservices application of the host platform comprises the microservices front-end application and a back-end microservices application, the system comprising: Communicating a requirements package corresponding to the microservices front-end application to a UX development platform; generating, by the UX development platform, a mockup package based on the requirements package; Communicating the mockup package to a microservices front-end development platform, a microservices front-end application; generating, by the microservice application development platform, a microservice front-end application package based on the mockup package; a processing system having one or more processors that execute computer-executable instructions that cause the processing system to integrate the microservices front-end application package, wherein an application utilizes and integrates the microservices front-end application based on the requirements package.

9. The system of claim 8 , wherein the computer-executable instructions cause the processing system to generate a token package comprising one or more reusable design tokens.

10. 10. The system of claim 9, wherein the token package is configured to be usable by one or more other microservices front-end applications.

11. The system of claim 8 , wherein the computer-executable instructions cause the processing system to generate a handoff document corresponding to a gallery of referenced components.

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

13. The system of claim 8 , wherein the computer-executable instructions cause the processing system to generate, with the UX development platform, one or more storybooks based on the requirements package.

14. The system of claim 13 , wherein the computer-executable instructions cause the processing system to publish the storybook via the UX development platform.

15. 1. A computer program product for creating and integrating a microservices front-end application into a host platform, the computer program comprising: computer readable program code executable by at least one processor upon retrieval from a non-transitory computer readable medium, the program code comprising: Communicating a requirements package corresponding to the microservices front-end application to a UX development platform; generating, by the UX development platform, a mockup package based on the requirements package; Communicating the mockup package to a microservices front-end development platform, a microservices front-end application; generating, by the microservice application development platform, a microservice front-end application package based on the mockup package; integrating the microservices front-end application package, wherein an application utilizes and integrates the microservices front-end application based on the requirements package.

16. 17. The computer program product of claim 16, wherein the computer-executable instructions cause the processing system to generate a token package comprising one or more reusable design tokens.

17. 16. The computer program product of claim 15, wherein the token package is configured to be usable by one or more other microservices front-end applications.

18. 16. 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.

19. 16. The computer program product of claim 15, wherein the computer-executable instructions cause the processing system to generate, with the UX development platform, one or more storybooks based on the requirements package.

20. 20. The computer program product of claim 19, wherein the computer-executable instructions cause the processing system to publish the storybook via the UX development platform.

Images