Use case 3: Model server and web backend

This use case realizes the synchronization of model data between a web application and MPS through a model server.

This use case consists of:

  • a model server that holds model data

  • a web backend that can read and write data to the model server

  • a web frontend that displays data from and interacts with the web backend

  • an optionally running MPS that syncs its data with the model server

To see how a web frontend can directly connect to a model server, take a look at use case 2.

A backend is needed if you need to control what data a client might read and write. It is also useful to translate data from modelix data structures into a data structure that is suitable for your web applications.

The web backend is implemented in Quarkus. It communicates to the model server using the model-client.

The data communicated between the model server and web backend are modelix-specific data structures without information about the metamodel. In the backend, those data structures are wrapped with generated Kotlin classes generated by the Model API generator from the metamodel. The backend programmer can use this so-called domain-specific-language API to access model data more type-safely.

The web backend exposes a custom application-specific API, which the web frontend uses to communicate and read and write data. The web backend, therefore:

  • controls how data is read and written to the model server.

  • hides details about modelix-specific data structures and domain-specific-language API.

Demonstration

use case 3
Figure 1. Demonstration of synchronization
Static
Figure 2. Interactions in demonstration

In this demonstration

  1. Data is changed in one of the opened web frontends.

  2. These changes are first propagated to the web backend.

  3. The web backend propagates the changes to the model server.

  4. The web backend also propagates the changes to the other opened web frontend.

  5. The model server syncs the changes into MPS.

  6. Model data is edited again in MPS by reverting the made changes.

  7. Those changes are then also propagated to the model server.

  8. The model server propagates the changes to the web backend.

  9. The web backend propagates the changes to all opened web frontends.

Instructions

You can try the demo yourself by downloading the samples repository.

In the downloaded repository, use Gradle to build the relevant components.

Command to build the needed components
./gradlew rest-api-model-server:build spa-dashboard-angular:build mps:project-modelserver-backend:build

This command:

  • Install dependencies in the MPS project mps/project-modelserver-backend

    The main dependency is the model-server-sync-plugin.

  • Generates TypeScript sources in mps/metamodel-api-ts

    Those sources are generated from the MPS languages in mps/languages. They are used in the spa-management-vue and spa-overview-angular.

  • builds the web backend rest-api-model-server

  • builds the web frontend spa-dashboard-angular

Start the components:

docker-compose --profile useCase3 up

This starts

MPS (optionally)

Start MPS 2021.2.6 without any global plugins and open the project in the mps/project-mps-backend folder.

This MPS project has a plugin installed and configured to sync the model content automatically with the model server.

Use case 1 describes the synchronization between a model client and an MPS instance.

Web frontends from use case 2 (optionally)

You can also start the web frontends from use case 2 and see how changes to the model are propagated there.