O Slack API, How Do I Love Thee?
I’ve worked with more APIs over my 25+ years as a professional developer than you can shake a stick at. (Note to self: Figure out where that expression came from — seems curious that shaking a stick is what one would do to question the impressiveness of something.)
Right now, my passion project is GrowthBot, it’s an all-in-one chatbot for marketing, sales and growth. Because it’s all-in-one (i.e. not just a single feature) it talks to a lot of different systems and consumes over a dozen APIs. And, because it’s a chatbot, it works on several different platforms including SMS (via Twilio), Facebook Messenger — and, of course Slack.
Being a B2B bot, Slack is the natural home for GrowthBot. It’s the platform I’m spending the most time on.
So, I’ve been going deep on the Slack API and I have to say, I love it.
O Slack API, how do I love thee?
Let me count the ways…
- I love that you love JSON because every time someone makes xml the default output for their API, a puppy feels uncharacteristic ennui.
- I love that you know the one_right_way when it comes to case for API URL endpoints. Everything is lowercase and uses underscores, just like it’s supposed to (because that’s how I like it).
- The API is consistent and cohesive and makes sense. In 99% of the cases, I can guess what the API endpoint name is going to be and how it’s going to work.
- The documentation is consistent, and (OMG!), accurate.
- Your API docs have a personality, wit and a sense of humor. Because as it turns out, most developers appreciate humor, and I’ve heard rumors that some even have a personality.
- Your team is exceptionally responsive. Over Slack — and even email. And get this, they actually care. I can feel it.
- I love that you are not developer-hostile like some platforms I know.
- I love even more that you understand that we developers are betting our time (and sometimes our careers) on a platform. You know the importance of being clear about your philosophy about developers (you love them) and your intention to build, and more importantly, maintain trust.
I know what it’s like to be loved and it is clear that Slack loves developers.
I think those last two points are worth of their own section.
Slack’s Forward Looking Philosophy On Ecosystems
Lots of companies release APIs. But an API does not a platform make. A platform is something people build on. To really create a platform people can build on, there needs to be a core philosophy of creating value for the builders. Slack has that philosophy.
We are building for a future where Slack is dwarfed by the aggregate value of the companies built on top of it.
That’s the way to think about platforms. Yes, every platform as it gets to scale is going to have a dilemma. It has to make tough choices. The toughest is deciding whether the company should make something a core feature of its product — putting it in competition with the developers that were delivering those features and previously meeting that customer need.
I don’t know what the right answer is in these situations. But, I know what the wrong answers are. The wrong answer is to be greedy and hostile towards the developers. The wrong answer is to start closing down your API so that your internal teams can “win” and you can push-out whichever third-party apps are getting in your way. I understand the need for companies to make money — even platform companies. But, I believe that you have an implicit understanding with your developer ecosystem that you will not take advantage of their trust in the future. It’s OK to build competing features — but don’t exert your power over the platform to unfairly win over customers. Let the customers choose what is best.
Only time will tell how Slack’s philosophy will evolve as they grow and scale. But, my gut tells me that Stewart Butterfield and friends have their hearts in the right place.
Now, to lighter topics. Have you seen the new Events API?
The Events API Is The Best Thing That’s Happened To The Slack API, Ever
The biggest gripe I had with the Slack platform when I started working with it was the need to work with web sockets. You actually had to manage these connections, one per team that had installed your app. It was ugly and you had to get deep into the bowels of things that you just didn’t want to get deep into. You had to worry about socket states and lost connections and sharding connections across servers based on some voo-doo hashing algorithm that you were going to be hated for some day.
But, thankfully, none of that is necessary now.
Slack introduced the amazingly convenient and useful Events API.
Now, your app just subscribes to the events it needs. Slack kindly sends you regular messages over https so you can go back to focusing on your users, instead of focusing on how to manage finicky web sockets. Thanks, Slack!
Developer Experience (DX) Drives Platform Success
We all know about user experience (UX). We know that in this day and age, even in B2B software, user experience counts. A lot.
One thing we don’t talk about a lot is developer experience (DX). But, for platform companies, it’s just as important. There are so many analogs between UX and DX it’s not even funny. Great user experiences are clear, consistent and cohesive. Great developer experiences are too.
Now, back to working on GrowthBot. The Slack version in beta now has been installed by over 250 teams, and is cranking. And, just learned today that’s a featured app on the Slack app store (you can see it on the homepage now, in all it’s glory).
If you’re building a Slack bot, please say hi. It’s nice to know others are out there living the dream.
And, to the Slack team: Thanks for creating a great product and a great developer experience. You folks have been a joy to work with.