Superslack - Exercising Slack Apps

Posted: 30 November, 2018 Category: backend Tagged: slack APIngroktesting

New to the slack API? To start having fun earlier and defer the detailed dive into the docs and API specs, I give you:

  • superslack-server - tiny prebuilt slack app that you can fork and play with

  • superslack-ui - a fantastically no-frills UI for exercising/testing your slack app. Fork and extend to play & experiment.

    superslack UI

    The idea is to shorten the amount of time it takes to get talking to slack for the very first time. You go to slack, create an app, fill in the secrets/tokens in your server's .env file, and that's it. You can start with the UI, and then when comfy, You can peek at the server code, and then when comfy, you can throw the lot away or grow it into a more robust thing.

Getting started

I started my journey with this tutorial. Do check it out to get the gist of things. What it comes down to, is:

  1. a Setup phase, in which

    • you set up an http server (which will evolve into your slack app)
    • you install and run ngrok (for IP+port forwarding of your localhost to a public endpoint that Slack can actually find and talk to), and
    • you create a slack account with a workspace that your slack app can frolic about in.
  2. a Coding phase, in which

    • you extend the http server with routes that handle calls and callbacks from Slack
    • you finally excercise your app by taking actions in slack and/or hitting your server with requests to do something slacktaculous.

Things I learned that might save you time

  • When working with ngrok, know that unless you're paying them, the IP necessarily changes each time you restart ngrok... when that happens, that means you need to log back into slack, hunt down every redirect url and change it. So as much as possible, while testing/developing, keep ngrok running in the background, un-disturbed.
  • You will hit the ground running faster if your make your http requests via curl in a terminal. Or even Postman. Why? Because all such tools don't care about SOP (Same Origin Policy). Browsers, otoh, are designed in such complete obeisance to SOP that you will be beset with CORS errors. I had decided to go the browser/ui testing route, so I had to build in an (admittedly straightforward) 'forget CORS' attitude into my server.
  • When you read the API docs, please put your APIs hat on and realise that when they say send us a "token", they mean "send us a bearer token with the appropriate Authorization header in the HTTP request. Don't just stuff it into your post payloads.
  • All those json payloads are at the mercy of your http client. If you're using raw request in nodejs, or fetch browser-side, its best to explicitly set the correct headers (application/json) yourself and also call JSON.stringify() and JSON.parse() on your json objects & string payloads. The only flawless variant of such things was the the body-parser module for express, and the attendant .json() response methods, which do what it says on the tin. In spite of which:
  • Slack can and shall send you stringified json payloads, so your cutesy lil calls (e.g. if using express) will barf. Take a good look at the structure of your response payloads coming back from Slack before writing the code to parse them.

For all these reasons and more, I used my "superslack tool" to help me test and learn. Check it out, in case it will be helpful to you too. It also lets you play with pushing simple as well as interactive messages to slack, and getting the response selected by a user.