The creation of the CodeGrade editor

In the latest release of CodeGrade we’ve introduced a built-in editor that allows students to code right inside CodeGrade. In this blog post, we will explain how we created this new feature and how good design decisions can make your code easier to reason about, and more scalable.

Why an editor?

As always when designing new features for CodeGrade, we first try to find out why we are building a feature. Which type of coder are they, how will this help their educational journey and what extensions to the feature can we already foresee? To get the answers to these questions we write user stories on how the feature will be used. For the editor, we see the most value for the “Coding to understand” group, the people that learn coding to communicate with coders, not to become great programmers themselves. The editor will replace the need for them to set up a local environment, especially when combined with AutoTest. These users are used to tools like Google Docs, not Emacs, so features like auto-save are important but extending the editor with custom code is less important. Furthermore, for this group the best feedback could be offered not just by looking at the end product, but also by looking at the process of how they got there, so keeping edit history and watching them code in real time could be useful additions.

Architecture

At this point we have a list of requirements for the feature, both functional (i.e. the editor should automatically save work) and non functional (i.e. the editor should look good inside the LMS). This means we can start designing the needed architecture. Before this feature CodeGrade clients relied fully on a REST API to communicate with the backend. This allows us to keep thinking in a request response model, and makes it easy for our customers to create custom scripts with our API. It was clear from the start that a REST API would not work, any collaboration feature would not be possible (polling for changes is not a scalable solution), and automatically saving would introduce an unacceptable amount of latency. To overcome this issue we decided to incorporate web sockets into our stack, this way we can have lower latency communication with our backend, and notify the client of changes. This brings us to the architectural diagram as pictured in figure 1.

‍