Engineering Recruitment Automation System - 0

How did it start? Why build RAS? 👨‍💻

It’s November, and all my friends have canceled plans for a Winter trip. ❄️ I’m slightly disappointed as I see a project I’ve been working on for the past few months isn’t going to production. In December, IITK sees the placement season. I am responsible for the automation portal as Web Executive at the Students' Placement Office. A senior called out this responsibility and pointed out the portal is very inefficient. I’m the web executive; after all, let’s look into it. 🤓

What I found out: The portal is built in Django, using HTML templates and MariaDB. Decent enough tech specs. But the load on our virtual machine was too much. Hmmm… we need to “optimize” and “scale” it. As a foolish enthusiastic novice developer, I asked the Placement Coordinators:

Image	Translation
	Me: Do we have budget constraint? Can we shift to aws? It’s easier to shift load there Manali(Placement Cordinator): Can you do it?!

Now with a go-ahead sign. I, as usual, was discussing fascinating and crazy tech stuff. Ironically, the server name contained “Bitching United”. I believe that server with three users had more activity and quality content than a dedicated group. During a conversation, the portal came up, so he volunteered to join.

After a converstation with dryairship: Mythbust101: A portal doesn’t simply scale if you put it on AWS. 🥲

What do we have?

After a little bit of digging, we found out:

1. Portal was using a deprecated Django version (ofc, python 2)
2. Portal had bloaty packages for zipping, xlsx conversion, file serving
3. Portal was communicating in terms of entire HTML
4. Endpoints were simple HTTP calls
5. Portal was single threaded
6. No caching anywhere

The portal was sufficiently capable of serving enough users back when it was created. Abhishek and I sat down for disaster management. But requirements have changed now.

💥 Disaster Management

• We bumped the version of Django
• before that, we had to bump the python version
• The code base was not formatted well enough for a tool to help 😔
• We fixed a few security issues. We added caching
• We tested the portal against several benchmarking tools to understand if anything improved. It was a great success.
• We also looked into How to scale this, but there was something common between Django and ruby on rails.

🎯 Conclusion

SPO used the updated portal in Intern Phase 2. The performance of the portal has improved. But the caching backfired. A user could see the cached data of another user since the entire HTML was being cached.

Final thoughts:

• The level of abstraction Django provides is too much. Mastering this framework isn’t what either of us is looking for.
• It’s high time the team works on a new portal with proper ideation and design.
• Not assuming the position of Web Head(Senior to Web Executive) to manage this portal.

I remember Abhishek’s comment:

Bhai revert karde, isse apni intern and placement lagwa lenge exploiting security loopholes

This post still doesn’t answer the question: Why build RAS? 👨‍💻 Stay tuned for the next post.