Multilanguage Web-based IDE Development
Budget: $1,500 – $2,000 USD
Project overview
This project will require little to no frontend work.
The infrastructure outlined in this doc is for a web based IDE that utilizes a VSCode window to write code in and a VNC window for viewing a linux desktop (so graphics programs can be written). This must support multiple languages and be expandable into more in the future, but for now I am focused on java and python.
IDE
These IDE’s will be docker containers managed in Kubernetes, that get spun up when a request is made for one, and shut down after 10 minutes of inactivity. They need to sync to a GCS storage bucket in google cloud.
When an IDE is requested to be started a GCS bucket should be passed, and the IDE will load up with those existing files. Any changes made to the container’s filesystem (in the code directory) should be synced to that GCS bucket. Ideally also the VSCode user will be something non root that has no access to anything but the directory its code and settings are in so they cannot navigate around and break everything.
Usage: that spins up a container in under 3 seconds with VSCode Server to put in an iframe. This will also need to use a noVNC viewer running over websocket that can also be embedded in an iframe.
This needs to be in some solution using kubernetes clusters to keep instances warm for fast load times while expanding compute as demand increases, so I am for the most part, only paying for what I am using. This is important as the usage of these instances spikes during the day where everyone starts up one within like a 5 minute span, and then almost no people do for the next hour.
In my prototype using AWS FARGATE cells, I used https://tigervnc.org/ + https://github.com/novnc/noVNC + https://github.com/novnc/websockify to get the virtual X11 desktop to display through websockets to a noVNC viewer. I wrote my own IDE in react, but in this next version I am opting to say just use https://github.com/coder/code-server to display VSCode, for simplicity. I have tried this when playing around and it seems to work.
Some nit-picky features that are required for this IDE:
A run button that can be triggered through a HTTP request. Students who are learning how to code for the first time will not understand how to run things in a command line. I will be placing a green run button on the react frontend and need it to trigger the code to run, placing output in the VSCode terminal.
Settings that can be modified externally in the frontend for:
Programming Language (with version)
Default run file (for aforementioned run button)
A startup script ability. Startup.sh (doesn’t need to be called that) that a user could write code for in the frontend in settings and it will execute that code (think automatic pip installs for libraries needed in the project) before letting them code.
Easy duplication. Teachers will write code in one of these IDE’s that is going to be a template, flagged in the db. The template code will need to be replicated whenever a student starts the assignment, with the option to reset to template. So all these settings like language, start.sh, all of it needs to be easy to duplicate. This should come easy due to the nature of temporary containers, but worth mentioning.
Full Edit history. not in the same GCS bucket as the live code probably, but somewhere we need a full edit history for every single IDE that a teacher could scroll through to see the exact code at any timestamp. This should also flag any pastes into VScode so teachers can see what students pasted (the anti-cheat).
This project will require little to no frontend work.
The infrastructure outlined in this doc is for a web based IDE that utilizes a VSCode window to write code in and a VNC window for viewing a linux desktop (so graphics programs can be written). This must support multiple languages and be expandable into more in the future, but for now I am focused on java and python.
IDE
These IDE’s will be docker containers managed in Kubernetes, that get spun up when a request is made for one, and shut down after 10 minutes of inactivity. They need to sync to a GCS storage bucket in google cloud.
When an IDE is requested to be started a GCS bucket should be passed, and the IDE will load up with those existing files. Any changes made to the container’s filesystem (in the code directory) should be synced to that GCS bucket. Ideally also the VSCode user will be something non root that has no access to anything but the directory its code and settings are in so they cannot navigate around and break everything.
Usage: that spins up a container in under 3 seconds with VSCode Server to put in an iframe. This will also need to use a noVNC viewer running over websocket that can also be embedded in an iframe.
This needs to be in some solution using kubernetes clusters to keep instances warm for fast load times while expanding compute as demand increases, so I am for the most part, only paying for what I am using. This is important as the usage of these instances spikes during the day where everyone starts up one within like a 5 minute span, and then almost no people do for the next hour.
In my prototype using AWS FARGATE cells, I used https://tigervnc.org/ + https://github.com/novnc/noVNC + https://github.com/novnc/websockify to get the virtual X11 desktop to display through websockets to a noVNC viewer. I wrote my own IDE in react, but in this next version I am opting to say just use https://github.com/coder/code-server to display VSCode, for simplicity. I have tried this when playing around and it seems to work.
Some nit-picky features that are required for this IDE:
A run button that can be triggered through a HTTP request. Students who are learning how to code for the first time will not understand how to run things in a command line. I will be placing a green run button on the react frontend and need it to trigger the code to run, placing output in the VSCode terminal.
Settings that can be modified externally in the frontend for:
Programming Language (with version)
Default run file (for aforementioned run button)
A startup script ability. Startup.sh (doesn’t need to be called that) that a user could write code for in the frontend in settings and it will execute that code (think automatic pip installs for libraries needed in the project) before letting them code.
Easy duplication. Teachers will write code in one of these IDE’s that is going to be a template, flagged in the db. The template code will need to be replicated whenever a student starts the assignment, with the option to reset to template. So all these settings like language, start.sh, all of it needs to be easy to duplicate. This should come easy due to the nature of temporary containers, but worth mentioning.
Full Edit history. not in the same GCS bucket as the live code probably, but somewhere we need a full edit history for every single IDE that a teacher could scroll through to see the exact code at any timestamp. This should also flag any pastes into VScode so teachers can see what students pasted (the anti-cheat).