TECHNICAL FIELD

This specification relates to a computing architecture that enables users to develop applications using building blocks that include micro frontends.

BACKGROUND

Software developers often attempt to develop software components that can be reused to build new software. This can save time and reduce errors and testing time for the new software applications. One example of such reuse is a microservice architecture that structures applications as a group of services that can each be reused in other applications. Another example of reuse is a micro frontend architecture that structures user interfaces as a group of frontend components that can be reused in other user interfaces of other applications.

SUMMARY

This specification generally describes a computing architecture that enables users to develop applications using building block user interface elements (“building blocks”) that include micro frontends that have a model-based state. A micro frontend can be in the form of one or more frontend components that can be included in a page, e.g., a web page or application page. Each micro frontend can have its own independent backend, e.g., in the form of a microservice, that is part of a building block, e.g., a business component, that includes the micro frontend. In this way, independent teams can develop building blocks that can be inserted into multiple user interfaces, e.g., multiple pages.

The backend for a micro frontend can be connected to the user interface components of the micro fronted using declarative bindings, e.g., using JavaScript Object Notation (JSON). The use of declarative bindings enables the user interface components to be decoupled from the physical backend implementation and enables decoupling from specific user interface technologies. In this way, the user interface can optimize the rendering on specific user interface technologies. The micro frontends of a user interface can also be connected using declarative bindings that enable the micro frontends to communicate, e.g., using messages that include actions.

A micro frontend can include a globally-managed model-based state that is changed based on actions received from the user interface or another micro frontend. For example, a micro frontend can include a global store, which can be implemented on the frontend, that manages the state for the micro frontend. The state can represent the micro frontend's model. When the micro frontend receives an action, e.g., based on user interaction with the user interface component or an action received from another micro frontend, the store can send the action to the backend. The backend can include one or more reducers that generates an updated model, e.g., without changing the model, based on the action and the previous model and sends the updated model to the store. Thus, rather than being mutated, an immutable model is threaded through the reducer function(s), which yields the new, immutable version of the model for the store. This model-based approach fits well as a distributed and concurrent computation paradigm at a larger scale where actors achieve a distrusted computation by exchanging messages and encapsulating their state. This also enables business components, which can be a combination of one or more micro frontends with a corresponding backend, to be location transparent, which means that a single page in an application can be composed by business components running on distinct servers. Inside of each actor, e.g., each business component, the state management enables stateless computation to be predictable, parallelized, and horizontally scalable.

In general, one innovative aspect of the subject matter described in this specification can be embodied in methods that include providing a configuration user interface that enables a user to select and arrange building block user interface elements in a layout for a page; receiving, from the configuration user interface, data specifying a layout of one or more building block user interface elements that each include a micro frontend and corresponding backend logic, wherein: each micro frontend includes one or more user interface components and a store that manages a model that represents a state of the one or more user interface components of the micro frontend; and the corresponding backend for each micro frontend includes a function that updates the model of the micro frontend based on a previous model of the micro frontend and an action; and generating user interface data that, when processed by an application, causes the application to generate a user interface that presents the one or more user interface components of each of the one or more building block user interface elements in the layout specified by the received data. Other implementations of this aspect include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices.

These and other implementations can each optionally include one or more of the following features. Some aspects can include receiving data specifying that a first building block user interface element is a subscriber to messages generated by a second building block user interface element and generating a declarative binding between the first building block user interface element and the second building block user interface element.

In some aspects, the backend of each building block user interface element includes one or more reducer functions. A given user interface component of each building block user interface element can include an action that is bound to a corresponding reducer function of the backend of the building block user interface element. The store of each micro frontend can be configured to send a current model maintained by the store and action data specifying a detected action to the corresponding reducer function in response to detecting the action. Each reducer function can be configured to generate an updated model based on the received current model and action data and provide the updated model to the store.

In some aspects, each of the one or more user interface components is bound to a respective attribute of the model. Some aspects can include updating the one or more user interface components in response to receiving an updated model that includes updated attributes. Some aspects can include receiving data defining custom business logic for the user interface.

The subject matter described in this specification can be implemented in particular embodiments and may result in one or more of the following advantages. Using the actor-like paradigm for communication between business components that is based on asynchronous message passing not only enables local transparency—e.g., different business components on a single page can run on physically different back-ends—but also enables temporal decoupling such that a receiving business component does not need to be in any way active and listening for messages. Instead, the business component is activated by the architecture on demand. In addition, the sending business component does not need to wait for the message to be processed, both of which enables better resource utilization and more efficient communication.

The interplay between model-based state, declarative configuration and composition, and vertical reuse and encapsulation provided by business components and other building blocks described in this document allows component and toolkit developers to safely define business logic within well-defined physical and logical perimeters, enables app developers to leverage a substantial amount of pre-built, tested, and vertical building blocks that speak their same business language, and lets designers draw from the thinking and user experience that inspired and were infused in the whole platform, from the most basic user interface components to declarative layouts and page navigation. The architecture can be used to enable developers to quickly create reusable applications with no-code and/or low-code approaches and to build and allow the building of reusable vertical toolkits that contain a set of building blocks, e.g., a set of building blocks for a particular team of developers that are typical for that team's business context. Using such building blocks reduces errors introduced by regenerating similar micro frontends for each application, rather than using pre-tested building blocks.

