Slack Bots and all that
===

Chat applications like Slack and Discord are good platforms to build simple applications that take an input and provide some output. After all, you can treat slack as a REPL-like interface for commands. The idea is not new of course, and numerous bots have been written ever since the days of IRC.

#### Reasons to use slack as a platform

Last week we made a simple Slack bot that allows customer-facing guys to retrieve the OTP corresponding to a given order. For OTP related issues the customer guys would have to ask some backend guy to retrieve the OTP himself. This is a rather slow task and can be easily automated.

The main reasons for exposing the above functionality via a slack app/bot is

- Slack is already used by everyone in the organization and is almost always running on their computer

- Authentication is already done by Slack's API and authorization can be done by the slack channel admins.

Initially we thought about using Metabase's slack bot solution but it was kinda too complicated for the functionality we need - just a db fetch based on the user input.

Slack provides an easy to use NodeJS API, so we used that instead. The bot listens for `@` mentions and expects a list of order numbers, which we query the db with. Then we reply to the user.

Hosting the bot on the GoMerchants servers was relatively simple using [proctor](https://github.com/gojek/proctor). However, it doesn't have a node-app preset so we had to do a bit of manual tweaking. _Note to self - tell the proctor guys to add node support._

#### Robust parsing

Although this is a rather simple application, it's good to always strive for correctness as much as possible - in this case that's be proper parsing of inputs and showing good output to the user even if it's an error. This is especially important when you are going to use the input as part of a db query.

Initially we used regexes to parse the list of order numbers. We should able to handle this using some simple parsing. In my opinion, while regexes are good for standardized formats like single urls, IDs, output of unix commands etc., they are not good for human input. We could teach everyone in the customer-facing team how to format the input as a proper JSON array, but nah. The alternative is to use context-free language based parser. Context-free language descriptions are more readable and more extensible than regexes. So if we need to add some extra functionality to the bot, we could implement a `<command> <arg_1> ... <arg_n>` kind of interface too.

Gone are the days when you either had to generate code using a parser-generator or you had to write your own parser which is terribly boring and error-prone. In the 21st century we have parser combinator libraries with which you can describe your format quickly in plain JS and have much more readable code. For this bot we used [parsimmon](https://github.com/jneen/parsimmon). Although this project is not super security sensitive, it never hurts to make your code robust.

#### Always Monitoring

For a simple application like this, we probably don't _need_ to integrate with full arsenal of monitoring services we typically use for our microservices. But we added some monitoring anyway. This is always a good discipline. If nothing else, it provides a good visual interpretation of the app's workings and graphs are nice to look at.