Building the DNSimple Slack app
Javier Acero
on
It's been roughly half a year since we released the DNSimple Slack app. If you work with domains or do anything DNS related you should go get it:
Back then, the resident vanlifer @meeunier, wrote a really nice blog post explaining, not only the features of the app, but also the process that we went through to ship it. He mentions that a five day project ended up turning into a 3 month effort. However he didn't go into any detail into the challenges we faced, specially development-wise. I would like to fix that right here, right now.
Technology choices
The first question that I'd like to address is what language we used. Although we may have taken a different route today, Ruby still was our favorite tool back then. For a very small web application the choice seemed obvious and we went for Sinatra.
One of the benefits of going the Ruby way was the myriad of libraries that we had at our disposal. One gem in particular ended up being super useful to format the output of our commands: terminal-table.
The web layer is very simple as the application only accomplishes two very well defined tasks:
- Performing the necessary OAuth dances with both DNSimple and Slack.
- Responding to commands.
With that skeleton in place, all we needed to do was parsing the commands that we received, performing the necessary calls to the DNSimple API, and replying back to the users. Easy enough. A couple days worth of work. Or so we thought…
Development challenges
Adding the first commands was easy enough. Things like listing the domains in your account, listing the records in a domain are simple, fast API calls that allowed us to follow the pattern I just described. Enter the register command.
If there was a command that we were sure we wanted in the MVP that was the register command. Being able to buy a domain directly in Slack is really cool (and something we've done now more often than we would like to admit).
Unfortunately domain registrations are slow (very slow) and can take a long time to complete as they involve several interactions between us, our upstream provider and the corresponding registry. Slack doesn't allow for any command to take more than 3 seconds to respond, which meant dealing with this particular command wasn't going to be as easy as we thought.
What Slack does allow you to do for long running commands is sending an initial response and following up with later on. This means that you need to be able to schedule the work that needs to be done, and then reply back once it's completed.
This provoked big changes to our code base and the integration of new third party libraries which pushed back the release date from what we had originally planed.
Bad luck comes in 3s
Once our register command was working beautifully well we put it in front of the team. Every one loved it. It was all bells and whistles. We thought we were ready to launch… It was too good to be true: it turns out there was some "legal stuff" that we had overlooked…
ICANN policies
We are called DNSimple for a reason: we want everything to be simple, easy to use. Specially if it is related to domain services or DNS. That's why we wanted you to simply type /dnsimple register awesome-domain.com to purchase your domain.
If you've ever registered a domain you know that you need to provide your contact details. This information will be listed as the registrant details in the WHOIS information of the domain. We didn't want you to pick your contact from Slack, so we simply chose one for you. As it happens this can be ICANN policy violation. On top of that, there are some TLDs that make it really hard to change the registrant contact information…
So, when we thought we were done, we had to further enhance the register command to allow you to choose your registrant contact. This is how the register command ended up looking:
Slack policies
Third time is a charm, right? With our wonderful register command finished we were ready to submit to the Slack directory. Or so we thought…
As we were putting together all the assets required for the submission we realized that there was a tiny bit of the Slack check-list that our app wasn't complying with: our command responses were using attachments and weren't providing a fallback text.
We had to go over all of our commands and add the fallback text. It wasn't a hard thing to do, but we contacted Slack about them a couple times over them which pushed our submission date even further.
The lessons to be learnt
There is a happy ending to this story: we finally shipped our Slack integration. It's working beautifully and our customers find it helpful. But that's not all to be happy about as we also learnt a couple things along the way:
- Don't keep side projects private: if you read @antoine's post you'll notice that it was only a small part of the team working on this project and that we were developing it in secret. We could have saved quite some time and frustration if we had discussed the project with the rest of the team and get them help us figure out not only the legal stuff, but also other things like the scope of the project.
- There are no such things as weekly projects: even if you want to go fast and you want to keep a software project to the bare minimum it will take time. This is specially true nowadays that almost every single application works with third-party services. You will need to figure out not only how to integrate with it, but also how to do it the right way.
Javier Acero
Programmer. Minimalist. Apple fanboy. Currently having fun at DNSimple. I love coffee and my cat.
We think domain management should be easy.
That's why we continue building DNSimple.
