System architecture and components in this repository

This samples implementations allow to run different use-cases in different setups - thus showing the flexibility of the modelix platform. Depending on the chosen use-case, only a subset of the components in this repository are used.

Full system architecture

The full architecture includes components used for multiple use-cases. One does not need all components to realize individual use-cases.

system diagram full

In the following a short overview is given on each component.

The MPS Language

The meta-model (language) of the courses domain and a model (soulution) with sample data in JetBrains MPS on which everything in this sample is based.

▶️ For more details, see the Language section in the MPS component documentation

Generated model API (domain API

An API based on the meta-model generated with the metamodel-generator component from modelix.

Domain-specific OpenAPI

In this example project, an extra domain-specific API layer is added which is defined in the OpenAPI specification[1]. This layer is meant educational as no noteworthy abstractions from the language itself happen in this definition. It intends to show how one introduces a clearly defined domain-specific abstraction decoupling the language engineering (meta-modeling) and the web development.

We provide two backends (i.e. implementations of the API layer): The API via modelQL and API via model-server components.

▶️ For more details, see the OpenAPI component documentation.

OpenAPI implementation

This project provides two implementations of the openapi domain abstraction.

MPS as a source

This backend provides access to the model by obtaining the model knowledge directly from a running MPS instance. It is implemented using ktor and connects to a model-client plugin running inside of MPS. This component can only provide read and write access.

▶️ For more details, see the API via modelQL for details.

model-server as a source

This backend provides access to the model by connecting to a running model-server. It is implemented using Quarkus and can provide read access to the underlying model. Additionally, a websocket for push notifications about ongoing model changes is provided. This is realized using websockets exposed by the model-server.

▶️ For more details, also see the API via model-server component for details.

Single-page application (SPA) Dashboard

The dashboard provides access to model knowledge through a browser. As it is conforming to the OpenAPI specification, the dashboard is able to obtain the model content from both backend implementations. However, the dashboard is consequently limited by the chosen backend.

This components requires running any of the available OpenAPI implementations to obtain model knowledge from.

▶️ For more details, also see the Dashboard for details.

Real-time' collaboration web application

⚠️ TBD

Deploying to Docker / Kubernetes

⚠️ TBD

1. See for details on how OpenAPI works.