Kudos to @vedarth for keeping his cool while getting the infrastructure stable. This meant working late nights, getting woken up at odd times to respond to Pagerduty calls and building monitoring for our systems all at the same time.
For the last month the administering Rbox team has been working hard on api v2 and I felt it is now a good time to share what we have achieved.
Today in Recruiterbox we have the following versions of the api
Some of the problems with the above approach
It is desirable to have a single canonical api for recruiterbox that both our app as well as customers use. This means that you add new features and fix bugs in one place.
Today api v1 has over a hundred endpoints. This is hard to grok for even devs inside Recruiterbox, let only external customers. We need to have a small api surface area and a consistent api, so that is easier for devs to start with and work with. React.js is a very good example of it.
The goal is to totally take out api v1 and have our app use api v2. If an app as complex uses the api, then a lot of our customers can as well. The trick however is to keep the design generic enough and not couple it how our app does certain things. This means we need to have routine discussions on the design of the API.
The admin team has already built a few basic endpoints as a first cut. The idea is that if we build anything new, we should use ApiV2. This isn't as easy as it sounds because you may be enhancing a feature that already has an api, rewriting the api layer can add a lot to your delivery times. This a call that every team needs to take after discussing it with other teams and the admin team. Bigger features like for example the candidate profile page redesign will make sure that we use the new APIs. It has become easier to write and modify the api because of the changes in RIP.
RIP had a few rough edges and issues and it was hard to write resources. The admin team has refactored RIP and fixed the following issues
Rajesh conducting yoga class