Awesome_E A custom API for things from checking projects for blocked words to on-the-fly project player modding.
As I was developing my tools for Hopscotch, I needed to store some persistent data and have a server instead of only relying on a frontend. Previously, I stored data either with counting APIs, with spreadsheets, or even by manually updating data by committing it to the Hopscotch Tools repo.
However, it was time to use a DBMS – even a simple one would do. So, I set out to create an API to run many of the pages you see in the Hopscotch Tools, including project modification requests and automatically retrieving the latest project player scripts directly from the Hopscotch servers.
One of the applications for this API was a system to judge competitions hosted on Hopscotch. Like many other coding platforms, people host contests and see which participants can create the best project. The problem is, there was no way to judge it efficiently since the only communication between users was directly in a forum thread. The API was then created for competition organizers to store projects and their respective scores.
The API also handles project requests. Previously, they used an automated form and spreadsheet to keep track of requests, and it had to be made public in order for the client to be able to retrieve data. This structure was fragile and made it so it was possible to see other users’ requests, so I changed it in favor of a more robust system that (1) sends notifications to me properly, (2) stores and returns data such that only the person who submitted the request can see it, and (3) works just as well for the user.
A page using the API to retrieve competition projects
The Admin Interface for me to add and edit videos
I also used the API to automate a workflow that was otherwise very difficult: updating projects. In Hopscotch, you can easily make a visual or bug fix change to a published project, but there’s no way to save intermediate progress when doing this. That means that if you change a project, you have to update it immediately or discard the changes, which make larger updates impractical. However, I added an endpoint to my custom API that is able to update a published project using the data stored in one of your drafts (which can be saved infinitely before publishing).
Finally, I also used the API to manage content shown on the Hopscotch Tools page. I wanted to move away from hard-coding Hopscotch blocks (for the help guide), links to videos or demos, and words that I knew blocked by Hopscotch (for the filtered word checker). So, I used a database to store these, had the API return them when requested, and made it easy to update on my end with an admin interface.
This API is entirely a backend application, and is written in Node.js. It uses express to handle routing, and contains unit tests written in Jest to ensure that different API endpoints behave properly. Since this API deals with multiple individual tasks rather than one complex task, each table does not interact with any others. This allowed me to be more flexible with database management, so I chose to use Deta’s free (noSQL) database, as it allows me to experiment and iterate quickly without worrying about set up.