In a previous article, published in July 2019, we wrote about why we felt the need for an asynchronous Slack standup bot, and how we’re building it using decoupled Drupal and GraphQL.
It’s now September. Here’s a look at our progress so far.
Where are we with the development?
We’ve stuck to our commitment of releasing the bot in the first week of September. The essential features are already implemented, and we’re now working on the authentication mechanism of the bot.
What’s possible right now:
- Users can initiate a conversation with the chatbot, answer questions that the bot asks, and submit their updates for each day. These updates are posted in the Drupal backend.
- In addition, time logging can be done directly from Slack via a Tempo integration.
- We’re making a few more updates, like making it possible for the bot to initiate the standup at a specified time.
- We’re also adding the option to post a notes summary in a specific Slack channel.
- JIRA tickets will be automatically linked, so that users can opt to see more information about each ticket. (We’ve not decided yet whether this feature will be included in the first release.)
We should be ready to use the bot at Axelerant in 2-3 weeks.
A look at the bot’s architecture
With GraphQL, we can change the dialog flow of the bot without worrying about revisiting the GraphQL backend, and make changes according to our needs.
Apollo Server makes it easy to set up a GraphQL server quickly. We can dive directly into key aspects of GraphQL (like the schema, datasources, resolvers, etc) without worrying much about setting up the server.
We’ve built expertise with GraphQL, chatbots and microservices.
This project has given us the opportunity to explore areas like GraphQL, chatbots, JIRA APIs, and the Apollo Server.
We shared a demo of the bot at our session at Drupal Camp Pune 2019 on Microservices architecture pattern using GraphQL and Decoupled Drupal.
This is what it’s like interacting with the bot
It was a full house, with 50-60 people attending. Afterwards, many audience members approached us with their questions around such an architecture: using Drupal as a microservice, GraphQL implementation, REST vs. GraphQL, etc.
These are important questions today. Developing and integrating APIs is a difficult task, and GraphQL makes this process easier for developers, helping to improve developer experience. GraphQL and microservices architecture help improve speed and productivity by allowing autonomous and cross functional teams to work together effectively.
Even though this blog post by Dries finds that JSON:API performs better than REST and GraphQL (and JSON:API is now part of Drupal 8.7), we believe that there are a lot of use cases where GraphQL is the better choice. It’s important that you evaluate what technology and architecture work best for you, based on your application needs.
Together, GraphQL and microservices architecture enable us to build powerful, modern applications, and ship products faster. And we’re excited to explore these further in future projects.
Want to know more about our capabilities? Reach out to Prateek on LinkedIn.About the Author
Prateek Jain, Director, Digital Experience Services
Offline, if he's not spending time with his daughter he's either on the field playing cricket or in a chair with a good book.