Nowadays many companies or teams use Slack to communicate and share content. Slack is very flexible and opens up possibilities to developers, as it provides webhooks (incoming, outgoing), bots, and event subscriptions. Your Slack reflects the way that you work.
In our company (Octo Australia), we play a lot with Slack webhooks to facilitate our office management (for example to check if someone is at the office, open the building door ...) or to create fun tools and notifications (please water the plants, a connected ‘wheel of _mis_fortune’).
Our most recent idea was to create our own bot to save our pictures automatically into our drive because we share a lot of photos of our events and want to save them for later.
And we also thought it could be great if we could share it with the world in the Slack app store!
Steps
Here’s the architecture of our app:
We built our internal bot in Golang using Serverless framework to quickly have our product online. Serverless helps us to setup easily our AWS infrastructure and deploy it.
Then in order to transform our internal product into a Slack application that is ready to be published, a number of steps need to be followed:
Start by Slack configuration
You can easily create an application with Slack via their interface (https://api.slack.com/apps) and it should be managed under your slack team.
One thing you need to do is to create a second app for the production version because there’s no way for the moment to use the same app and connected to 2 different environments, even so, Slack currently provides you with 2 sets of credentials (for dev and prod)
Now you have to select carefully which permissions you need for your app to grant access to your users' Slack workspace. These permissions are given by a token using OAuth flow. You can only add the scopes that you are currently using (Slack’s security policy). The thing is if you need a new scope the users will have to reinstall your app.
As Slack use OAuth 2 to generate tokens you need to declare your redirect URLs, which is the endpoint for your server and which receives the code to be able to process. You can add as many as you want and this works well with your local server.
Depending on the Slack features you selected, you may to add configuration, for instance in our case we ask for an event subscription and so we need to set an URL (to the server) for Slack to call it when specifics event occurs.
Once this done you can generate your Slack button to be used for installation through a website or Slack app store.
As a new product, you have to build a landing page and we use an AWS S3 bucket to store our content. The last step concerning Slack is to be compliant with policies about the usage of users data, right on images, support for the users, and so on, which is a long checklist but it’s not a really big deal (https://api.slack.com/docs/slack-apps-checklist).
Slack provide you with a lot of tutorials to help you to create your app and moreover, their teams are very reactive to give feedback after submitting.
Google Drive
For the next part, we need to use Google Drive’s API and for that, we must configure Google OAuth.
Because our application requires server to server communication and an authorisation grant (we upload to Google Drive on the users behalf) it's necessary to obtain a token, which is a credential we can use to perform predefined tasks (uploading).
In the Google Cloud console, under APIs and Services, Credentials, we can add an OAuth screen and download the credentials we will need when making a request to the API for our clients credentials. In order to set this up we also need provide a few things, including authorised domains (eg photostashbot.com) and before launching it needs to be approved.
Application
The essence is sending a request to the API with our application credentials, from a registered domain and with a preconfigured redirect URL as a kind of callback endpoint which will receive the token.
Once the token is granted it can be stored in DynamoDB, along with a 'Refresh Token'. This is necessary to generate new tokens from Google. Each access token has a limited lifespan, meaning rotating the token in use for accessing the account is mandatory. This is different to the Slack API which does not use refresh tokens.
Some of the documentation for working with Google Drive was also difficult to find. For example, if a user uninstalls the application from Slack we also want to remove the credentials from our database for Slack and Google, but in the case of Google, we also need to remove the apps access to the users Google account by revoking the token. In the end it is a simple API call to https://accounts.google.com/o/oauth2/revoke?token= but the documentation specifying this was hard to find.
Environments management (local/dev/production)
Working with a serverless architecture makes it a little bit more difficult to set up environments. While Serverless framework definitely does make it easy to deploy infrastructure to AWS, there are some specific challenges when working in local and dev environments.
In order to test locally, we use SAM and specify configuration in a yml file. But this has limitations because in some case we need to actions with 'live' interaction with our dev slack api endpoint. For example it is not easily possible to test the OAuth flow (sign in with Slack, add to Slack) locally. In this case we must rely on deploying to AWS from a local laptop.
The issue with this however, is that if you deploy to dev you will overwrite the current dev deployment, and in many cases this is necessary. So it can add complexity as team members work on the project synchronously.
The overall flow of the software factory is facilitated by CircleCI. Configuration for endpoints, database names and redirect URIs are stored in a set of config files while all sensitive secrets for accessing Slack or Google are accessed via environment variables which are provided by CircleCI during the build and deploy process.
Conclusion
The most complex development part was to deal with Slack and Gdrive credentials to save and secure them, how to deal with it and how it works especially Gdrive.
When you create a public application there is a lot of things you need to take care like legal usage or images, the condition of use etc.
It was a lot of fun developing a small project that can be useful for others to use.
Want to try it out? Here’s our Slack app: https://photostashbot.com/