Building a New Hackathon Management System

Optimizing the applicant management system behind nwHacks, Western Canada’s largest hackathon

This year, our developer team took on the task of rewriting the applicant management system that powers nwHacks. This is a summary of how it went, from changing our web framework, to going completely serverless. And at the end, a quick look at the system in action.

What Changed?

• Back-end: Golang scripts → Google Cloud Functions (JavaScript)
• Database: Firebase Realtime Database → Google Cloud Firestore
• Front-end: Polymer → React & Redux

Why?

We’re a completely student-run team. One of the biggest consequences of this is that our projects have to switch hands quite frequently. For this reason, it felt important that we prioritize making our codebase easily approachable, and require the least amount of maintenance as possible.

Going serverless

From nwHacks 2015 to nwHacks 2018, we’ve been using a set of Golang scripts that were hosted on a server. These scripts were used for tasks like application submission, tagging applicants, and sending mass emails. Our club typically operates between September — May (a regular school year). Our peak traffic occurs between November — December (our application period) and peaks again on the day of our hackathon. The main takeaway from this is that the scripts are called on every now and then, but definitely not all the time. And yet, we have to keep the server running for this entire period. Most of the server time is spent waiting for a request, as opposed to serving requests.

By moving to a serverless architecture, specifically FaaS (functions-as-a-service), we no longer have to worry about this. The basic idea is that you deploy a set of functions to the cloud. When someone calls on a function through its URL (for example, when submitting an application for nwHacks), the following happens in the cloud:

1. The function is loaded from a shared server disk into memory, initialized, and executed.
2. After it’s finished running, the resources it uses are freed. If it’s called frequently enough, it stays in memory to minimize any cold starts (the delay from having to load & initialize a function).

The difference is that we no longer waste resources on our own idle server, and only pay for what we use. The vendor we chose was Google Cloud Functions (GCF) as it integrates nicely with the rest of the Google Cloud services we use. We can quickly write a function that we want to access through a URL and deploy it to GCF with a single command. The cloud functions are auto-scaled, auto-provisioned, and require zero maintenance. It doesn’t get any easier than this. 😄

Updating the database

In previous years, we used Google’s Firebase Realtime Database, which is a NoSQL cloud database service. It integrates nicely with the other services in the Firebase suite (such as Firebase Authentication). This year we switched to Google Cloud Firestore, which is meant to be a successor to the Firebase Realtime Database. It was in beta testing at the time we adopted it, but has since reached general availability. To get an idea of the difference, you can check out this document for a nice summary.

Regarding the front-end

Previously we were using Polymer, a front-end framework by Google which advocates for a number of web technologies that are in the process of being standardized (such as custom elements, shadow DOM, and HTML imports). The framework was gaining popularity, but changed quite dramatically starting in version 3 so an overhaul would have still been necessary. We decided to look for a more well-established framework with no sudden breaking changes between versions, and one with plenty of resources to get started. We settled on React & Redux. To simplify things even further, we chose an additional framework called react-redux-firebase which comes with a handful of neat features that make our lives easier.

Some other optimizations

1. We now have a separate Google Cloud Project for our development and production environments, which should reduce the chances of unknowingly modifying something important during development.
2. We have feature flags in our database, which every user’s browser will automatically listen to when they visit our site. We can use these flags to enable/disable features (such as applications) and have them instantly update on all clients that are using our web application.
3. We’ve added support for mentor & volunteer NFC-enabled nametags (last year we only gave those to hackers) as well as assigning coat check numbers to applicants (for large item check-in). If this is the first time you’re hearing about our NFC app, feel free to check out last year’s write up, and the source code here.

About stack literacy

Since our front-end and back-end logic is written in JavaScript, future developers will only have to know JavaScript, HTML, and CSS (with JSX being easy to pick up) to be able to make meaningful changes to the web application. This should hopefully make the process of getting familiar with the codebase as easy as possible for new developers.

How Much Did It Cost?

Yup, you read that right. The total cost of running both the production environment and development environment was only $7.28. This included thousands of function invocations and database read/writes on both environments. But Google actually gives new users $300 in platform credits for a year, so our actual cost was nothing. Less money spent here means more money to spend on cool prizes for nwHacks! 😃

The Organizer Interface

Now, here are some demo clips of a few common tasks done on the system by organizers. The system in the clips is being run locally using fake data from our developer database! Kudos to Sherry Xie for designing the mock-ups that we used in order to build this interface.

Sorting, searching, and scoring applicants

Filtering applicants by properties or tags

Selecting and bulk-tagging applicants

Conclusion

I’m incredibly proud of my team (currently Min Gyo Kim, Lynn Zhang, Stanford Lin, Giulio Rossi, and myself) for implementing the internal tools you see above while juggling classes and other commitments at the same time. You can find the source code for our website & applicant system here, as well as the rest of our projects in our GitHub page.

Thanks for reading! 👋

P.S. — If you want to join our team for the upcoming year, we’re hiring!

nwhacks.io — Western Canada’s largest hackathon hosted by nwPlus.
Stay in touch: Twitter | Facebook | Instagram