Removing the Runtime from Design Time
Another year has passed, and once again one of the best weeks of the year is behind us: a week full of challenging coding and time with colleagues.
This year, I focused on decoupling design time from the runtime engine.
A bit of history
In the old Eclipse-based Designer, the development environment was one large codebase. While this had benefits, it also made some architectural boundaries difficult to enforce. As a result, the runtime engine had to be running even for tasks that only involved designing a process.
A runtime is useful for simulating processes, but it should not be required just to design one. It adds startup time, memory usage, and download size. Ideally, when VS Code starts with our extension, the process editor should be available more or less immediately without starting the entire engine.
We have already made significant progress in this direction. For example, the engine is no longer required to build and validate a project with our Maven project-build plugin. However, the API endpoints for our VS Code extension and our web-based editors still depend on runtime code.
Today, opening a project’s graphical role editor requires starting the engine and deploying the project first. This is inconvenient for developers, so removing that dependency became one of my goals for this code camp.
Rework API endpoints for our VsCode Extension
I focused mainly on the communication between the VS Code extension and the engine. I removed unused endpoints, simplified parameters, and moved the endpoints from the workspace-based dev security context into a new, independent designer context.
This work also gave me the opportunity to explore how to keep an older VS Code extension compatible while changing the backend. For each endpoint, I first introduced a compatibility layer, migrated the extension to the new API, released the updated extension, and removed the compatibility layer only afterward.
Final result
These changes bring us closer to a design-time environment that is lightweight, fast to start, and independent of the runtime engine. There is still more work ahead, and I did hope to get further, but I'm satisfied with the progress made during this code camp.
Side projects
As this code camp was mainly some hard technical refactoring work, I've also enjoyed a little role in the development of a newly integrated simple rule engine (see other code camp post). And I also updated all of our editors to the last Tanstack Table v9 update which was quiet a rewrite.
