Hackjudge — From Inception to Application

An event managing application developed in-house at GDSC VIT to create and manage events from start to finish.

During events, there is so much that needs to go into managing — from creating portals and applications for the event to a whole mess of excel sheets that the organizing team has to manage while scoring and ranking teams. To address this problem we created Hackjudge, an amazing platform to create and manage events from start to finish.

So hi, I’m Pragati, a server-side developer at GDSC VIT and Hackjudge is one of the longest projects I have worked on up till now, spanning almost 2 years and grown to its 3rd version. Talking about its architecture, the project is divided into 2 components:

The admin side to “judge”
The participant’s side for letting participants/teams submit their ideas [the “hack” part]

Let’s dive straight into how it all began.

The development started in January 2020. I had just started learning backend then, so was familiarising myself with Node.js with Express, MongoDB, and REST APIs. I started with creating a basic CRUD backend and tested it out using Postman. Once I had my basics clear, I started with the project at hand.

January 2020

The mentor assigned to me was Amogh Lele, an amazing developer, and an equally amazing mentor at GDSC VIT. He guided me with all the minute aspects of maintaining security while creating a server-side platform. Under his guidance, I made the routes and models and I was done with the backend.

Well, it turns out that this was just the beginning of my backend story for Hackjudge and also this was my first adventure with common developer problems.

Due to some personal problems, the front-end developer had left the club. There was no one assigned immediately as everyone had selected their projects at the beginning of the semester.
My backend API was never tested by a frontend dev, so I was never too sure of the fact that all routes that were needed by the frontend were made by me

So this went on to the next semester which began in July 2020, this was when everything everywhere went to work/study from home.

July 2020

A new semester means a new project so I had taken up a project called “Frogg editor — an online Groff editor” under Angad Sharma, ex-Community Lead at DSC VIT. Hackjudge remained an open-source API until October when GDSC VIT conducted an event called Ideathon — where participants who register can form teams and submit their ideas which will then be scrutinized by our GDSC VIT team and the top teams make up to the finals.

And by the way, that’s me hosting an event for the first time on YouTube, pretty embarrassed about it, but definitely learned from those mistakes.

But wait, Ideathon’s architecture sounds familiar … and you guessed it, the Hackjudge API was used for this. More precisely the participant side of the API was used where:

Users can register
They can create a team (which generates a unique team code)
The team code can be shared for letting others request to join your team
The team leader (who created the team) can allow participants to join and also remove already made members
The leader can submit the idea, edit it and also delete the team
Emails are sent when someone joins the team or leaves the team or when the team is deleted [made using Amazon’s SMS]

However, the backend is not all that there is to a project. The amazing front-end developers, Ashutosh Kaushik and Ananya Ganesh who replicated the beautiful web designs made by Pranjal just made the whole application absolutely stunning.

Now let’s talk about the backend development part. During this time I realized that the previous API couldn’t be used directly and that a lot of new changes were required. The models needed new attributes and relations and the route’s logic had to be improved to meet the frontend’s needs. All of this demanded a structured format for the database because it was difficult, (Not not doable, just difficult) to implement it in a non-relational DB like Mongo which I was using.

So switching to a relational database, in my case PostgreSQL seemed a good option then and that’s what I did.

This is the structure that I used to start the second time

1. Designed and worked on the models and relations

2. Worked on middleware

✓ To check if a user is admin or not

✓ To check if a user is authorized

3. Implemented CRUD for models like Auth, Events, Teams, Metrics, Scores, Comments

✓ Then finally implemented those routes that were specific to the project’s functionality

✓ Getting statistics about events

✓ Getting all participants

✓ Getting all teams, qualified teams, evaluated teams, and unevaluated teams of an event

✓ Getting all reviews about an event, and a separate route to get data for a review

✓ Several routes to manage how a user can join a team and how a leader of the team can manage the team and make their submission

The above is a brief of all the routes that were made, you can find a detailed description of them here.

Under the guidance of my mentor (Amogh), I revamped the entire backend and not just the participant’s side, but the admin side also, to keep it ready for future projects.

So Ideathon was done and it was a success and this was the second version.

January 2021

My next semester in college, a new project commenced for me. It was Pipo — an application for creating your own personalized scrapbook, the backend of which I had made under the guidance of my mentor, Riddhi Gupta. Here is a link to its repo: https://github.com/GDGVIT/pipo-backend

However, there is a twist to this, because this wasn’t the only project I worked on. Hackjudge had finally found its front-end developer, Pranjal Timsina, for completing the website which had found its appealing designs in the Adobe XD files that Ishi had made. It wasn’t yet “So long, farewell, Auf Wiedersehen” to this project considering the number of applications it can be used for!

So here we are in the present applying Hackjudge’s admin side for our flagship event at DSCVIT, Devjams, and also for the mini-events that lead to it. That’s version 3 by the way. It basically accommodates 2 extra routes.

A route that returns all the teams with their scores.
A route that lets you send a JSON with all details for your admin portal and the route pushes the respective data to its attributes in the database and then you can use the UI to score your participants and review the teams.

Simplified isn’t it.

This brings me to the present, August 2021. There can never be an end to this project :) Looking forward to making more versions to make the application as customizable as possible.