Using Decoupled Drupal To Build Our Standup Bot

Agile teams carry out a daily standup where people share their reports: what they are going to work on, do they have any blockers, etc. 

At Axelerant, we run on agile. This means that we are heavily reliant on daily team huddles to keep each other connected and informed about the team’s landscape and progress. 

Standup bots can automate this process by asking team members to submit their report at a specified time. This report is then shared with all team members before the standup call. 

Over the years, we’ve tried a lot of standup bots like Standup Alice and Howdy, but most of these have some limitations, and we’ve found minimal options to extend them. 

This is what prompted us to build an asynchronous Slackbot to facilitate our standup meetings.

Why build our own standup bot when so many exist?

Apart from being paid tools, we found that with most standup bots, it was difficult to get a consolidated view of information. 

For example, when a team member logs their notes for the day, what they worked on gets stored as simply a ticket number. To see the ticket description or the time logged, users have to go elsewhere, eg. to JIRA. 

We envisioned a standup bot that knows what that particular ticket number involves, and shows those details. So we’d like to be able to integrate JIRA, which will help with updating the ticket status on JIRA easily. 

Another problem we wanted to solve was that of time logging. While our team members currently have to go to Tempo, search for the task and log time separately, we’d like to be able to integrate this activity directly into our new standup bot. This would allow our team members to share their daily notes as well as track time in one single step, instead of having to use two separate tools for each. Extrapolating further, we could also have the bot manage leave applications and other HR related tasks.

We wanted to build a tool that doesn’t just let us share updates but can also be integrated with other applications, making it easier to use and derive intelligence from it. 

How we are building this?

We’re using multiple technologies. 

• Decoupled Drupal: We’re using the Drupal API to store meeting notes. This becomes our CMS, helping us manage our content. Anything related to content and config can go here.
   
• GraphQL and Apollo: These make up the API engine. This will be the interface that is responsible for connecting with Drupal, Jira, Tempo, etc. 
   
• Microsoft Bot Framework: We’re using this for coding the bot. 
   
• Slack: This is our interface. 

Why GraphQL?

• You can query a GraphQL server and retrieve data. Unlike REST API, you don’t have to make multiple API calls to retrieve data which is available across multiple APIs. Since, you are not doing multiple API calls, this also leads to better performance than REST.
   
• It allows you to create a single point data source. A GraphQL server allows you to retrieve data from the database, REST APIs, or any third party services. All you have to do is run a single query.
   
• A REST API could emit a response payload with data that you might not want, while in GraphQL, you can specify the data you want in the query, and the response will only contain that data. This makes GraphQL perform better in slow networks.

Why decoupled Drupal?

We are using Drupal as a datasource in GraphQL. It will provide REST APIs which GraphQL will consume. 

We chose Drupal because it allows developers to easily create the necessary backend for the REST APIs. Drupal 8 is created with the mobile-first approach in mind. It allows you to create REST endpoints without any extra overhead (like writing code).

Why Apollo?

• Apollo is a platform for hosting the GraphQL server. Plus, it provides necessary libraries that allow a developer to quickly get into GraphQL. The libraries take care of the low-level stuff, like caching, etc., and developers can focus on writing the GraphQL server.
   
• The libraries are easily extensible.
   
• Apollo also provides useful tools for monitoring. It takes care of the development workflow. With Apollo, a developer can push changes to production with confidence.
   

Why Slack?

We have chosen Slack due to the wide usage of Slack for communication in various organizations.

Why Microsoft Bot Framework?

The framework provides the boiler-plate for creating a Bot and integrate it with a communication service, say, Slack.

Where we are currently with the implementation?

Currently, the development of the product is in progress. We are working on integrating Drupal with the GraphQL server as datasource. We have started building the bot using Microsoft Bot Framework, and we are working on integrating it with Slack.

What’s next?

We are expecting the first release in September.

Planned future integrations: 

1. JIRA integration: Team members can put JIRA ticket IDs and it will be automatically linked to the JIRA ticket.
    
2. Tempo integration: Team members can log time.
    
3. GitHub integration: Same as JIRA integration. Team members can put issue IDs and it will be automatically linked to the issue in a GitHub repository.
    

We’ll be trying out the beta version at Axelerant before releasing to the public.

Click here to read our next update.