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 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.
Use Gradle to build the relevant components.
./gradlew rest-api-model-server:build spa-dashboard-angular:build mps:project-modelserver-backend:build
Install dependencies in the MPS project
The main dependency is the model-server-sync-plugin.
Generates TypeScript sources in
Those sources are generated from the MPS languages in
mps/languages. They are used in the
builds the web backend
builds the web frontend
Start up the components.
docker-compose --profile useCase3 up
2021.2.6 without any global plugins and open the project in the
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.
Now you can modify the model through the web frontend. Those changes are first communicated to the web backend. From there, they are communicated to the model server.
The model server syncs those changes to other open web applications. You can see this by opening the dashboard a second time in a different tab.
If you have an MPS instance running and connected to the model server, changes made in MPS are synced with web applications, and vice versa.
You can also start the web frontends from use case 2 and see how changes to the model are propagated there.