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.
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.
▶️ For more details, see the 'Generated API' section in the MPS component documentation
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-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 themodel-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.