Overview of the samples

In the first use case, an MPS project is synchronized to a repository on a model server by utilizing the model-server-sync-plugin.

It shows how to make model data, previously accessible only in a running MPS or via files, available through a server.

In itself, this use case has little value, but the next use cases build in part on it.

See the Use case 1 page for details.

In this use case, we connect web frontends to a model server. The web frontends read from and write model data to the model server.

One web frontend can be used to edit model data and is implemented with Vue.js. The other one serves as an overview and is implemented with Angular.

You can see how changes made in one connected application are instantly reflected in another connected application. You can also connect an MPS to the model server and see how changes made in the application are synced to MPS and vice versa.

The frontend applications directly use the model-client JavaScript library that connects to the model server. They also use a TypeScript API generated by the Model API generator from the metamodel to enable type-safe access to data structures provided by the model client.

See the Use case 2 page for details.

In this use case, a web frontend connects to a web backend, which in turn communicates with a model server.

Like in use case 2 model data is synced automatically between the model server, the application and MPS.

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 with Quarkus. It uses the model-client to connect to a model server. It also uses a Kotlin API generated by the Model API generator from the metamodel to enable type-safe access to data structures provided by the model client.

For the Angular based web frontend, the web backend provides a custom HTTP- and websocket-based API.

See the Use case 3 page for details.

This is not strictly a use case but rather a bonus to increase the transparency and visibility of the requests happening in the background. The model-server always provides a /metrics endpoint which allows you to obtain data on several inner workings, such as HTTP connections or JVM statistics. As soon as you start a model-server, you can thus run a dedicated monitoring database (e.g. Prometheus) and a dashboard (e.g. Grafana) to obtain and visualize metrics respectively.

See the Monitoring page for details.