The following image shows a dense overview of our current roadmap.

2024 01 roadmap

Key priorities overview

The aim of this roadmap is to provide you with a more detailed overview of our plans. We have compiled a catalog of our significant areas, which are our top priorities we focus on delivering. In the following we shortly list these key priorities. Below you can find more detailed explanations for each of these.

  • ModelQL: Dynamic query language for on-demand loading overcoming issues associated with upfront data retrieval and optimizing performance

  • MPS 2023 / 2024 Support: Provide support in modelix for newer MPS versions

  • LIonWeb (estimated 24.1): Integration with other web components via a new LionWeb bulk API adapter

  • Model-server services: Streamlined interfaces and structure for services[1]

  • Meta-model in model-server: A way to store the meta-model of corresponding model content in the model-server (foundation for language evolution).

  • GraphQL interface: An endpoint for smaller web applications, leveraging the available tooling ecosystem

  • Projectional text editors in browser: Projectional text editors for browsers, using Kotlin multiplatform to edit models directly or through server-side rendering

  • Graphical Editors: We plan to provide the data synchronization and the generation of a TypeScript model API to enable graphical editors on the web.

ModelQL (estimated 24.1)

With the modelix 23.2 release we introduced ModelQL: A dynamic way of loading and writing parts of the model on demand while reducing the number of requests to a minimum. To learn more, head over to the ModelQL documentation and the corresponding How-Tos. While the early version allowed us to provide a quick win for large models, we were not able to finish this feature fully. Especially writing support currently needs to be stabilized and performance can be improved. We also want to integrate ModelQL in our samples project to present a graspable example beyond the documentation.

MPS 2023 / 2024 Support (estimated 24.1)

In a larger effort to become MPS version independent, we prepare our plugins and interfaces with MPS to provide preliminary support for MPS 2023 for the modelix 24.1 release. This effort is needed to provide adequate support today, but in the following release 24.2 we plan to fully transition away from dedicated MPS plugins over to IntelliJ Platform plugins. IntelliJ Platform plugins do not require to be written in MPS and are allowed to be created using Kotlin - just like everything else in modelix. All MPS interfacing parts will use the comparably stable APIs provided by MPS to query and modify MPS models, such as the Open API and the SModel. As a result, we do not have to migrate and maintain MPS plugins for multiple MPS versions at the same time. Instead, we have a single Kotlin codebase which can provide the same functionality to all MPS versions. This effort will reduce complexity and potential for bugs and allow us to better test and validate our MPS interfacing plugins.

LIonWeb (estimated 24.1)

Modelix focuses on a good integration with MPS. But if you are interested in the integration of other modeling technologies then check out the LIonWeb project (short for Language Interfaces on the web). They specify more general interfaces and use the modelix model-server for data storage and exchange in their current prototypes. For 24.1 we want to provide an adapter for the modelix model-server to support the initial LionWeb bulk protocol for model data storage and retrieval. The modelix team co-authored and is involved with the LIonWeb initiative.

Model-server services (estimated 24.2)

Modelix already allows you to access model data from any web application, either untyped (i.e. on the M3 layer), or typed (i.e. on the M2 layer or domain layer). As soon as you have model content in a web application the question regarding correct scoping, typing, and other checks arises. In MPS we grew accustomed to easy integration of these different language aspects. In modelix we envision model-server services to do this type of model analysis, checking, and eventually transformation. In fact, this can already be done today: Any application accessing model data from a model-server can provide external APIs for the above-mentioned features. However, we plan to streamline interfaces and approaches used by services to communicate with the model-server. Our goal is to provide a stable basis for services which will encourage re-use and extension.

Meta-model in model-server (estimated 24.2)

When using MPS, model migrations are made easy using the migration aspect. However, once stepping outside of MPS, migrations may become more difficult. Model migration needs to be carried out across platforms, teams and (web) applications when a new language version is deployed.

We want to support a generated API that can work with multiple versions at the same time with which we also can support meta-model versions checks for compatibility. As a consequence, we will need meta-model information in the model-server and plan to add this as a foundation for Language Evolution.

Until now, there was no need for this knowledge to be available directly but technically the meta-model is already stored, though implicitly encoded in the storage, but the model-server does not use or interpret this knowledge. We have some ideas we need to further refine and explore in the following releases.

GraphQL interface (estimated 25.1)

As with all other parts of modelix, we prefer using established and state-of-the-art tools. Consequently, for smaller web applications we consider to provide a simple GraphQL endpoint, which can provide immediate benefit. Especially the access to a powerful tooling ecosystem with GUIs, editor integrations, code generation, linting, analytics, and more is a direct win.

However, it is important to note, that this approach will not scale: As soon as the model size grows or the strong integration requirements exist, other tools such as our ModelQL or the model-server services are needed.

Projectional text editors in browser (estimated 25.1)

Similar to our previously developed notation language prototype (based on the old shadow models), we want to provide generic projectional text editors in the browser. A default notation is used for concepts without a web specific notation, just as MPS does it. We envision projectional text editor components implemented in Kotlin multiplatform for editing models in the browser, either directly or via server-side rendering.

Graphical Editors in the Web (estimated 25.2)

The experience from MPS shows that the requirements for a graphical editor are too diverse to support all of them with a single framework. There are many different frameworks available in the web world where you can choose the one that fits your use case. We plan to only provide the data synchronization and the generation of a TypeScript model API, but not the integration of any diagram framework itself.

1. We understand a service in this context as model-server independent software which operates on model data to provide some sort of derived knowledge. Within the modelix architecture, it does not matter if services run client or server sided, but we want to ensure that services are independent components which have to define their own endpoints and interfaces to the outside. We envision services to provide model validation, checking, transformation, or any other model data modification - features which language workbenches tightly integrate, for example in MPS aspects.