JetBrains Projector a Game Changer for MPS Projects?

My thoughts on the new Projector project by JetBrains, how we can use it with MPS and how it relates to modelix.

Last week JetBrains Projector had its initial release. Projector is a tool and framework to access JetBrains IDEs (and also Swing applications) over the network. It does what X11 can do on Linux by transporting the UI over the network but in a Java specific way. The application runs on the server, the UI renders on the client and the client sends events back to server when the user interacts with the application. Projector supports native clients as well as a browser client, all of them are open source and the browser client is automatically integrated into the server. For more information take a look into the blog post by JetBrains which also links the source code repositories. JetBrains makes it clear that they don’t see projector as a product but as a technology that can be used to enable new use cases with their IDEs.

For the server side Projector provides three options right now. One of them is a IDE plugin that turns every IDE into a server and you can access it over the network. The second one is a set of python scripts that install a server with a giving IDE version for you. The most interesting one from my perspective is the Docker image based variant. JetBrains provides pre build images for some of their IDEs but gives you the configuration scripts to build your own images.

The Docker images allow for interesting use cases especially in combination with Kubernetes. For instance automatically deploying the right IDE version for a project or launching a pre configured IDE in the cloud.

At its core Projector is a way to interact exclusively with an IDE running on a different machine. Projector doesn’t aim to provide collaboration features or similar, it’s aimed at a remote UI use case. To me it seems to solve similar use cases as Github Codespaces or Gitpod.

An MPS View on Projector

From an MPS point of view Projector allows for nice new use cases. One of the main benefits is removing the barrier of installing and setting up an IDE locally. Why is this particularly important with MPS? Endusers of most MPS solutions aren’t tech savvy developers but are from different backgrounds like tax or medical experts, systems engineers or finance analysts. For these users using and maintaining something IDE-like is inconvenient at best or outright scary.

MPS on a technical level has always blurred the lines between the IDE and the language the IDES is used with. The projectional editor needs to integrate deeply with the surrounding IDE to provide its full potential. While languages in the MPS ecosystem are typically distributed as IDE plugins they normally have a strong dependency on a particular version MPS and won’t just work with older or newer versions. In addition to that a project has a dependency on a particular version of a language which often changes over the lifetime of the project. Newer releases of the language might change the meta model in an incompatible way and require migration of the project.

As I mentioned above the most interesting use case for Projector and MPS is based on containers. For accessing the IDE on your development machine there are solutions that work well like VNC or Teamviewer. From my point of view Projector in combination with containerized application on Kubernetes can provide solutions to these challenges.

An architecture for MPS and Projector involving Kubernetes would look similar to the architecture of modelix. In such an architecture a web frontend will allow the user to start the IDE, this will then deploy a new container into Kubernetes and give the users access to it once that process has finished. How the frontend decides which container to start can vary based on the project needs in the simplest case the use select the exact version of the information is extracted from the project the user wants to edit.

Lets take a look at specific benefits and use cases.

Preconfigured IDEs

Providing users with ready to use environments is a significant challenge in MPS projects. Some projects required specific tools or libraries to be available. These need to be installed on the users machine. While all this can be solved with an installation process that takes care of all these dependencies, it’s often a source of additional complexity and errors. MPS IDEs are Java IDEs at its core which leads to a dependency on the JDK or at least a JRE.

Installing MPS based solutions with an included Java regularly causes discussions with IT departments in large organizations because it’s not obvious to them why “business people” all of a sudden need software that are usually used by developers. While in itself it’s not a show stopped it causes additional process overheat when introducing a MPS based solution. Moving all this into the infrastructure because nothing is installed on the client can be a huge benefit.

As mentioned languages and models have a strong dependency on each other. If it is required to view and edit models created with older versions of a language the meta-model behind the language needs to be kept backwards compatible. Keeping the meta-model of a language backwards compatible is possible but in many cases undesirable. As in any other software project deprecated parts of the meta-model would need to be kept around, increase complexity and are sources of error. With MPSs migration feature, that allows to migrate models to newer versions of the meta-model, there is even less reason to keep these deprecated features around for a long time. Evolving the meta-model and removing the deprecated parts of it poses one challenge: how to do a change to a model that was created with an older version of the meta-model and can’t be migrated to the new one? It’s possible to keep all the versions of the MPS base application around and install the correct one the machine where the user needs to edit the model. While this sounds easy it often isn’t because you might not know which exact version to use and time consuming trail and error is required to find the correct version.

With a solution based on containerized IDEs and infrastructure that support such use case this because easily possible. As long as the infrastructure knows which version of the IDE to use for a giving version of the models it can launch it. This requires the repository that stores the models to contain metadata with the information about the tools version. The infrastructure can choose the matching version of the tool based on such metadata and make it available to the user. Users don’t need to worry about the version aspect the simply choose a branch that they want to edit.

Continuous Deployment for Languages

A regular challenge in MPS project is deploying language changes to the users. Ideally you would like to deploy changes to your users quickly to get feedback. Of course versions involve breaking changes in the meta-model which require migrations need to be deployed more carefully. But the majority of changes are typically low risk. Since most MPS project deploys a full blown RCP, the frequency of change is limited. While features like incremental updates cut down on the cost to some degree, they lower the installation time and bandwidth requirements, these features still interrupt the user in their workflow. Deploying changes multiple times a week or even daily is usually not accepted by the users. Ensuring that all uses have gotten a particular bug fix is also impossible with such setups.

With a Projector and Kubernetes base setup continuous deployment gets much more feasible. Building containers with the up to date languages and deploying them from continuous integration isn’t much more effort than building a classical RCP application. Users won’t notice updates for the most part since they are “just there” the next time they connect to their IDE.

Lowering the cost for deployments and gaining more control over the update rollout process are the criteria that make continuous deployment in language engineering projects an option.

Less Resource Constrains on the Client

We have all been there, this one person in the project which hasn’t gotten a new notebook in half a decade, performance on the machine is horrible and the complete project is put into question. 😬

Joke aside, MPS end users aren’t developers and won’t have access tp comparable hardware to a developers machine. One can’t assume that everyone has tons of RAM or high performance CPUs. While these constrains aren’t a problem early in the project they might become one though the lifetime of it. Models grow, languages get new features or code generation gets more complex which can rise the hardware requirements. Getting every user on the project new hardware will be costly and cause lots of discussions with the IT department. Scaling containers in the backend is much more feasible and all users get better performance without new hardware.

How Does This Affect modelix?

If you know modelix and see that Projector has a browser client, you might ask yourself isn’t this the same as modelix?

If you don’t know modelix let me briefly explain what it is: modelix is an open source project that, among other things, allows you to edit MPS models in the browser. I also happen to be involved in the modelix project.

When we look at the goals of modelix, the difference in scope becomes obvious. Modelix as a platform that aims to make models addressable entities in the cloud, store models centrally with real time collaboration in mind, provide infrastructure primitives to build services on top of models and make models editable in the browser. Projector is all about making the UI of an IDE accessible over the network. In scenarios where the goal is to access an IDE over the network Projector can provide a better solution than what modelix can do at the moment. If you care about the other aspects apart from remote access to the UI then Projector alone is no solution to the problem.

With Projector and infrastructure based on Kubernetes you can easily build a similar experience for MPS based solutions to what Codespace on Github or GitPod provide for “classical” code. If you want to build a rich ecosystem around models where these models are accessible to others then modelix is the way forward.

All that said modelix and Projector aren’t mutually exclusive. On the contrary there are scenarios where Projector and parts of the modelix platform can work together. You could use the modelix storage layer, which seamlessly integrates with MPS, to store your models in a central repository in conjunction with Projector. This will give you the remote editor capabilities of Projector and the realtime collaboration features of modelix on top of it. In this scenario you are basically replacing the editor part of modelix with Projector and you could still use other parts of the modelix platform.

What’s Next?

To me Projector looks like a useful addition to the ecosystem around MPS and we as a community should explore use cases for it together. Short term Projector will allow us to mitigate some of the shortcomings of an RCP based client application when we build solutions with MPS. This will make our lives in some projects easier and might even open up new uses cases that weren’t possible because of organization constrains by the potential users. What Projector won’t do is fundamentally change how we think about models and IDEs with MPS.

For everything midterm I’m think modelix is the way forward because it will gives us much more opportunities to build ecosystems around models and frees us from the notion of a classical IDE. In a modelix based world models become first class citizens in the cloud accessible to a larger audience with rich services build around them.