Or, how we ended up reinventing the wheel

The interview moved towards ideas for user identity and API identity for a re-platforming project. I was interviewing with my now employer Lux Group, and I wanted to meet the team, so the interview room half filled with a bunch of faces which I desperately tried to remember names for.

You’ve got a lot of code to write, why not take an off-the-shelf product like auth0 for identity? Stormpath has a great pricing model for your user numbers.

About one month later, I joined Lux Group to find:

Three weeks of code had been written integrating with Stormpath SDK.

Stormpath had just announced it had been purchased and are shutting down their API in a few months.

I felt like a complete idiot.

Luckily, someone on the team had a very workable plan: first add a proxy to blindly pass on requests to Stormpath, and incrementally replace this proxy with our own identity service.

And so, we soon set out to reinvent the wheel and write yet another identity service. Two weeks, 2kLOC and 12 PRs later, we had:

A fully functional identity API with a similar flow to Stormpath running across our environments (backed by Postgres).

Services & Web endpoints all integrating with this rather than with Stormpath.

10 million users migrated into the new API for performance testing.

A complete lack of bikeshedding on our identity API design (although we’ve tweaked & extended Stormpath’s design).

Success!

It took us just solid two weeks to duplicate the minimal surface area of the API that we needed. We migrated bcrypted passwords to the new authentication backend and did not reset our user passwords.

A well designed API can be more valuable than a working codebase and holds valuable domain knowledge. The focus spent on API design can instead be spent on a clean codebase. Knowing the end-goal helps enormously here. We gained the productivity of an SaaS without ultimately using their service.