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.
The full architecture includes components used for multiple use-cases. One does not need all components to realize individual use-cases.
In the following a short overview is given on each component.
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
An API based on the meta-model generated with the metamodel-generator component from modelix.
▶️ For more details, see the 'Generated API' section in the MPS component documentation
In this example project, an extra domain-specific API layer is added which is defined in the OpenAPI specification. 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.
▶️ For more details, see the OpenAPI component documentation.
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-clientplugin 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
▶️ For more details, also see the API via model-server component for details.
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.