When Code Schoolers think about proposed technical topics that transform into a potential course, developers must ask a few questions. How will we test the students’ code? What type of tools are available to speed the development process and offer a better learning experience? Can the course be taught within the confines of the web browser, or will a service call need to be made to an external service? With the release of our new MongoDB course, The Magical Marvels of MongoDB, we can visit some of the decisions made and how MongoDB was taught right out of your own browser.

Remote Executor

At Code School, we start with a tool we use to evaluate a student’s code submission called executor. There are 2 separate approaches to executors: client or remote. With a client executor, all code is run on the student’s web browser, which yields better security and a much faster overall experience. However, most of the time the actual tool being taught in the course can’t be used within a browser. With a remote executor, each submission takes a bit longer, but there is no emulation of the tool (aka, “faking it”). What does that mean? Typically, it’s the real tool being used that’s taught in the course. So for the MongoDB course, we began with a remote executor. Leveraging Docker and MongoDB, the student’s code submissions are sent to a service where the code is evaluated within a container. The result is then packaged along with a full preview of the database, and then the entire data set is returned to the course where further tests will be used to ensure a correct submission. With a fully working remote executor, we were then able to focus on building out a client executor.

Tool Search

Now the search for possible tools is on! This part of the development process is quite fun — we search through GitHub and forums for any tools that simulate MongoDB within the browser without making any service calls. At first, this search seemed futile and using a remote executor inevitable. But while searching, we stumbled across minimongo being used with Meteor. After forking the project and an hour or 2 of setup, we had a bare-bones working prototype. However, about half the functionality was nonexistent within the library that was needed to properly teach the course. Even more, this library was not designed to act like the shell, nor was it really designed to be used for the course’s intended purpose. Since the course already had a working remote executor, pushing forward on a client executor seemed worth the effort.

Client Executor

The client executor must work within our Campus course platform, so some drastic modifications had to be made. The overall structure of the tool would have to change to simulate how the shell works. Methods such as “find” could no longer use callbacks, and methods such as “aggregate” would have to be built out and implemented. Also, specific shell commands, such as “help” and “db”, would need to be added, along with any shell output that would be expected from a real MongoDB database.

Integration

Course development typically moves very quickly, and not much time can be spent on prototyping for long periods of time. Undertaking the aggressive transformation of minimongo into a Campus course submission engine required tests, fast development, and a bailout plan in case it became apparent that the tool could no longer be used. Any decision had to be carefully weighed against the amount of work, the course deadline, and what can truly be achieved with the given tools at hand.

Using minimongo as the base of the full executor, basic functionality of MongoDB can be emulated within this module. The main purpose is returning a result that’s similar in structure to how MongoDB returns data. A lot of functionality was stripped out and moved around as the tool began to fit into the course. This module was then added to another module called the Mongo Client Executor, where the student’s code is evaluated and run against minimongo within the Mongo Client Executor. This evaluates and returns a result based upon the query. The executor then executes a specific object that responds with an appropriate response based upon the state of the database and what command was run. The executor also formats all data to be accepted on the Campus platform. At this point, minimongo represented about half of the Mongo Client Executor. This approach did allow for using MongoDB within the browser, but some queries entered by the student could get past our system, resulting in a false pass or failure.

In order to combat small submission issues, a peg parser was added to the Mongo Client Executor. Utilizing PEG.js, a parser was built to pull apart each student’s submission and ensure the correct syntax was used. This also enables developers to inspect a syntax tree generated from the student’s submission, allowing exact detection of errors. It also provides an extra layer of protection against bad submissions and  allows us to specify when a command is being used that we don’t support in the browser, such as sharding.

End Result = Success!

The final setup has the student’s submission running through a browserified Mongo Client Executor, which evaluates the query with minimongo getting a data set back. This is then run through the shell emulator portion, where shell commands are parsed and acted upon, or specific responses, such as “writeResult”, are displayed. Finally, the user’s submission is run through a peg parser where any final issues can be detected. All of this data is then packaged and sent back to Campus, where tests are run against all of the resulting data and a determination of a pass or fail can be made.

With these tools bundled together, MongoDB was able to be used within The Magical Marvels of MongoDB course without ever having to reach out to an external service. The entire course is run right within the student’s browser! And because an external service was ready and waiting in case the client executor didn’t pan out, we were able to have a much more aggressive pursuit of running the MongoDB database right within the browser. Using an in-memory database has its limitations, but for the purpose of teaching MongoDB within the browser, it was a really good fit. The performance, security, and scalability over the remote executor really yielded to a solid course.

Obviously there is quite a bit of work that all of us at Code School put in to create new courses for all of you. If you haven’t already, be sure to play through our newest MongoDB tutorial, The Magical Marvels of MongoDB, where you’ll explore the basics and learn what it means to store data in a document-oriented database. And of course, let me know your thoughts in the comments section below (tip: Click “View Discussion”)!