findIDP Tech Choices

I’m building a service that uses a bunch of heuristics to, given an email address, figure out which Identity Provider (IDP) you should try to use to log that address in. I’m doing it in Go. Here’s why.

The Context · You can read about about the whys of the thing in Project findIDP. But here’s the how:

• You get an email address.

• You do a whole bunch of network retrievals; glance at the domain’s MX record, try WebFinger, ask some well-known providers whether they host the domain.

• People can go online and select their own IDP for email addresses they control. There’s a dorky little 3-column database for that.

• It’s protocol-independent; I would hope to support lots of IDPs and flavors, probably via Backbone.js.

So logically it’s pretty easy, except for: The database might have a lot of records, the query load might get really high, and the logic is all asynchronous and concurrent.

Options · My thinking went like this:

• Life is too short for server-side Java.

• I’ve done my last few in Ruby, and I’m fine with that but it’s time to broaden the horizons; also I’m a little worried about scaling if this thing catches on.

• Python would be fine but if I’m going to learn something new, I want new and different.

• I would love to do this in Erlang, or even better, Elixir. But...

• The things that life is too short for include sysadmin shit, so I don’t want to think about server instances and subnets and that whole trail of tears. I want something I can run on a mainstream commercial PaaS cloud.

Having followed that line of thinking, the two options that looked best to me were NodeJS on Heroku, and Go on App Engine.

From that point of view, the choice was pretty easy. First of all, while Node is totally elegant and I’m a Heroku fan, I’ve just never managed to warm up to JavaScript. Secondly, Go is said to be psychologically comfy for C programmers, and I was one of those for a whole lot of years. Third, while App Engine has some odd performance quirks, if you treat it right you should have no trouble with a billion rows in the database or really big number of queries per second.

And since I work here, I can probably avoid, you know, paying.

Progress · So I started poking around early last week and had the service running four days later, just checking the MX and WebFinger so far. Except for there’s no WebFinger out there to check. Whatever.

I haven’t fallen in love with Go the way I did when I started using C in the Eighties or Java in the nineties or Ruby last decade. Yeah, I’m that old. I have a list of Go things I like and others I dislike and I’ll write about them. But pretty clearly, it’ll be OK for this job.

Why I’m Smiling · I’d never seen Go before. So life is pretty good when you can wade into the swamp of unknown infrastructure and get a result the same week.

But here’s the real happiness: I have choices! I’m dead sure that this could’ve been made to run just fine using at least one other PaaS combo. And if I were willing to become a cloud sysadmin, lots more choices.

Choices are good on the data side too. I have simple flattish tuples, and I haven’t for a moment considered going relational. Whatever hosting option I picked, there’d be a decent post-SQL data store; probably more than one.

There’s never been a better time to be a developer.

Contributions