Roadmap

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.

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.

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.

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.

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.

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.

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.

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.