Know me better

What do you do at Recruiterbox?
How long have you been working at Recruiterbox?
Imagine if someone is wanting to join Recruiterbox, what would be your elevator pitch to them?
What tools do you use on a daily basis to get your work done?
Lets talk something outside of work! What do you do for fun? What kinds of hobbies and interests do you have outside of work?
What is the favourite book you ever read / favourite vacation spot / favourite movie / favourite sport? (Any other favourites will also do)
Uttam Kini

Crime scene

Uttam gave a kudos to Vedarth

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.

Vinod gave a kudos to Anant, Anenth, Bhargav, Gaurav, Kundan and others

@anantpal @uttamkini @anenth @akhil @gauravkumar @vasu @viky @kundankumar @bhargavvoleti @vedarth Pulling off a high quality major redesign release with ease.

Uttam gave a kudos to Anenth

Kudos to @anenth for relentless speed in delivering stuff in the Candidate redesign stream. Keep up the awesomeness !

Raghuveer gave a kudos to Anant, Uttam and Vedarth

After several months of effort (and years of talking about this), we upgraded to Django 1.10. This is a big step in maintaining our infrastructure in good shape. Good job @uttamkini @vedarth @anantpal and others.

Uttam Kini

Api v2 and the way forward


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.

Why another version of the api ?

Today in Recruiterbox we have the following versions of the api

  1. v1 (eg. /api/v1/openings ) it is a mix of Tasty pie endpoints and some RIP
  2. public_api/v1 (eg. /public_api/v1/openings ) written in RIP authenticated using an api token
  3. js api ( eg. js_api/v1/openings) written in RIP and unauthenticated because it is supposed to be used for customers' career pages.

Some of the problems with the above approach

  • The same entity has multiple endpoints and different conventions of schema which means when we add a new feature or fix bugs we need to do it in multiple places
  • Some of the design decisions are not consistent with each other and not very popular in the external world eg. sub resources, some resources modelled as CRUD endpoints and some others as commands and View.

There is no public and private

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.

Small API surface

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.

Dogfooding is the best way to VALIDATE THE API's DESIGN

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.

All that is awesome, but where are we right now ?

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.

API Endpoints are now easier to write with 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

  • There are sensible defaults for error messages (there were null responses before)
  • All the logic of a resource resides in one class and by extension one place/file Developers have to extend the CrudResource and all the authentication, authorization, entity actions, serialization hooks etc are on the same class. All exsiting resources have been moved to the new style, so no two ways of doing things.
  • Flattened hierarchy in the RIP codebase means if you want to know how CrudResource works, then it is just about reading the code in one class, most classes don't inherit from anything. This is a decent substitute for documentation until we get there.
  • There is a base class for all apiv2 resources called CrudResourceV2, a lot of common logic like authorization which is common across all api endpoints can go here. Developers don't need to add code or tests for this common logic.
Uttam Kini

Kudos to @navaneethr, @kundankumar @sanjukta and others who helped them in keeping the integrity of the functional tests … its been weeks since I got a failure unrelated to my change in CI… I have now almost forgotten the word ‘random failure’ … keep up the awesomeness team 🙂

Uttam Kini

Rajesh conducting yoga class

Show More
Need help?