Hackathon Project – Nitro Cloud Slack Integration

Every quarter, Nitro gives employees in product and engineering time off from their usual workloads to participate in a hackathon. There are only 2 project requirements:

  1. it’s somewhat related to our core business (aka it’s not just a throwaway toy)
  2. you can produce a three minute demo video to show it off.

With an idea in mind, everyone is then free for a week to collaborate as a team or work on their own. The follow Monday, we gather everyone up for a meeting where we watch the demo videos, talk about our projects, and then cast our votes. Judging categories vary from silly (best name) to serious (most viable for product inclusion), with the top 3 of each earning a prize. All in all in it’s a blast for everyone involved.

For this year’s hackathon project, I decided to work with a fellow developer with the goal of integrating Slack within our Nitro Cloud application. We didn’t know for certain what we wanted to do, but our reasoning was simply that Slack is Nitro seemed like an excellent match from the ouset. It’s our (and many other companies’) primary internal communication tool. Slack has a thriving plugin/add-on scene, and so it seems like a natural fit for these two applications to get along.

The first step was to establish communication and data exchange, to help gauge the viability of the immediately apparent use cases we could think up, such as:

  • From Cloud, sharing a document for signature/viewing directly to a user on your company’s Slack
  • From Slack, be able to view a list of documents that are pending signature, have been recently modified, or any other query, from a slash command

It was not immediately apparent how easy or difficult it would be to achieve each of these goals. So, to start answering that question, we first investigated the integration methods available for Slack. Each slack integration approach caters for different use cases and complexity. As it turns out, pushing data into slack is a bit easier than pulling data into slack on demand, but here’s a short summary of some of the terminology:

API Integrations

Incoming Webhooks

  • This what we used to share documents from cloud— This is sending data INTO slack from an external service.

Outgoing Webhooks

  • This is how you used slash commands— we did not use this, but this is how you reach OUT to evoke an external service using a slash command

Real Time Messaging API

  • This is a more intense version of outgoing webhooks—focused for creating bot users to interact with a user in real time. We did not go this route.

App Deployments

As far as bundling your application together, there are two main options. The first, is to create a Custom Integration, that is specific to your company’s slack. This is a set of code that is unique to your company’s slack only and is not distributable to another company via the slack store Add to Slack button.

Custom Integrations

  • This is how you get started; this is where we stopped.

Publishing an App

  • This is how you distribute your application if you want to get real with it.

In the end, this is what we wound up with:

Adding Nitro Cloud to Your Company’s Slack Button

Adding Nitro Cloud to Your Company's Slack Button

Authorize Nitro Cloud Screen

Authorize Nitro Cloud Screen

Type Your Share Message

Type Your Share Message

Choose a Recipient from your Slack’s Contacts
Choose a Recipient from your Slack's Contacts

JavaScript Code to send the message:

postMessage: function (message, channelId, token) {
return $http({
method: 'POST',
url: 'https://slack.com/api/chat.postMessage',
isCors: true,
params: {
token: token,       // From Authorization Step
channel: channelId, // User or Channel Name
text: message,      // Message Payload (including share link in markdown)
},
});
}

Conclusion

While we only wound up with 2nd place overall, I’m very proud of what we did and found it a real pleasure to work with Slack. It’d be nicer to continue to work with the API and add more features in the future.