First look at JetBrains Gateway

Introduction

#

I recently set to try out a new product from JetBrains, the “JetBrains Gateway”.

JetBrains Gateway is a remote development tool, that lets you offload all the heavy lifting of the JetBrains IDE to a remote server via SSH.

A remote development workflow seemed tempting, as I often work from multiple different computers during the week, and I wanted to see if this could one day let me replace my primary work PC, a bulky Lenovo P15 Gen2 laptop, with something smaller, thinner and lighter.

The server setup - Part 1

#

To get started quickly, I spun up a virtual machine with Ubuntu 22.04 on Microsoft Azure, as I’ve got a Visual Studio Enterprise subscription through my workplace.

At first, I wanted to try and make it as cheap as possible. Therefore, I went with a Standard_DS1_v2 VM - a machine with 1 VCPU and 3.5 GB RAM. After waiting for the VM to be created and started, I tried to create a new project on the VM using the JetBrains Gateway application on my laptop. To my surprise, that was not possible:

The server setup - Part 2

#

So I decided to give the VM some more horsepower. I upgraded it to a Standard_D2ads_v5, a machine with 2 VCPU and 8 GB RAM. Now, the experience was a lot smoother. The JetBrains Gateway client, which looks just like the usual JetBrains IDE, quickly found all the plugins I had added to my IntelliJ IDEA Ultimate install.

The project I checked out on the remote server, was a small Spring Boot MVC application, with TailwindCSS for the frontend. This project therefore needed a JDK and NodeJS to be installed on the host, which they weren’t. After installing the needed tools, the Gateway client quickly detected them. The next step was to add the required environment variables to the Run Configuration of the Spring Boot project. However, as I tried to paste the variable value into the Environment variables dialog, I stumbled upon a bug, I think. The IDE wouldn’t allow me to paste the value of the environment variable into the Environment variables dialog. Strange, but it is currently a beta product after all.

After manually writing the values into the dialog, the Run Configuration for both the Spring project and the TailwindCSS transpiler worked like a charm, and I could access the frontend on the remote host, after poking a hole in the firewall (NSG in Azure terms) on the virtual machine.

The overall experience

#

The overall experience of the JetBrains Gateway almost feels “native”.k While there is a slight, noticeable delay before features such as the auto-complete dropdown appear and fully populate, the experience is generally smooth. It’s very hard to tell that all the indexing and processing occur on a remote host.

The aforementioned delay gets a little less noticeable after scaling the VM up to a Standard_D8ads_v5 (8 VCPU and 32 GB RAM). As of 2023, 8GB of RAM generally is a bit too limited for a Java development environment anyway.

Conclusion

#

A remote development workflow is quick and easy to get started with, using the JetBrains Gateway and it would definitely be possible to utilize it during my day to day work. With that said, the cost of the cloud based virtual machine quickly adds up, as 8 CPUs and 32GB of RAM seemed to provide the smoothest experience. Therefore I haven’t committed to use this as my primary workflow, but I would definitely take it into consideration again, the next time I’m out shopping for a new work laptop.