If you might not know, I have made a discord bot Gmbot — Multiplayer Game bot for Discord (itsnikhil.github.io). The way how this bot used to function was very simple, there was a trigger phrase
gmbot followed by command name like
createwar and some parameters
gmbot createwar -players @Player1 @Player2 -game 4 -type ft3
I have already written a detailed post showcasing it’s various features, database schema, etc. which you can read at Gmbot — Chatbot for gamers (itsnikhil.codes). I made that bot in python as
discord.py API wrapper library was written in python and I was comfortable working in that language. Like everyone, I followed whatever tutorials, documentation, etc. were available online. But today in this post I want to talk about something which I did not give much thought at the time when I started working on gmbot in 2019.
Everything was very monolithic
What I meant with monolithic is that all the functionality existed in a single codebase, everything I wanted to do had to be done in python. Even though the project was well structured into classes, easy to read/understand code and a common pattern was followed for creating each command but it was not testable, not scalable and not flexible. All the business logic was mixed within the command handler.
Example of how “gmbot status” command looked like
import DAOclass Status_Command(commands.Cog):
def __init__(self, client):
self.client = client @commands.command(aliases=['wars'])
async def status(self, ctx, *args): # status command handler
# validate command
# call DAO to get data from database
# business logic
# call success/error
await self.success_message(ctx, message)
await self.error_message(ctx, "ERROR") async def success_message(self, ctx, error):
# format and send success message async def error_message(self, ctx, reason=None):
# format and send error messagedef setup(client):
Can we do better? Micro-services
By micro-services I do not mean having different bots handling different features of the bot. I want you to think and treat discord bot server as simply a frontend-client like a mobile app and instead of mixing business logic into it, have a separate backend server communicating via RESTful APIs.
gmbot createwar -players @Player1 @Player2 -game 4 -duration 12
With this architecture commands like above will be passed to chatbot
frontend-client which can then make a POST request to to backend with the params in the body and client key in headers indicating this is a record from discord.
curl --location --request POST 'localhost:8080/createwar' \
--header 'client: DISCORD-BFF' \
--header 'x-api-key: **************' \
--header 'Content-Type: application/json' \
"name": "Server1 Name"
"name": "Player1 Name",
"name": "Player2 Name",
"game": "Mini Miltitia",
This API would return JSON response and status code based on which
frontend-client can craft a discord formatted response or slack formatted response
- Much easier to test the features
- Easy and quick growth/expandability
- Backend servers can be horizontally scaled
- Flexibility to experiment and optimize
- Freedom to try out new technology
- Separate deployments
- Leaner teams and increased productivity
Much easier to test the features
We have been developing backend services for many years now and have developed complex observability tools which can even tell which API request took how much time for a particular database query in real-time. Of course we have proper tooling to test and automate backend servers with proper CI/CD process. Without separate backend there is no good way to test discord/slack bots besides testing manually. If you would search for testing in discord.py official docs Search (discordpy.readthedocs.io) you will be out of luck.
Easy and quick growth/expandability
If you create a chatbot for discord, you have to accept the fact that you are limiting your audience group to that matching discord’s. Sketch design tool restricted itself to only support MacOS while Figma was web based open-to-all because of which Figma easily captured the market however good Sketch was in it’s comparison. Let’s say you developed an attendance bot and you want to support both slack and teams, backend can still be shared while clients can vary since core business logic is same across bots/ webapp. This is something I regret not doing for gmbot, when gmbot failed, I could not pivot my idea into a mobile app easily. Having this opportunity is very important for a lean startup which can require pivoting business into different direction any day.
Backend servers can be horizontally scaled
Let’s say your chatbot got famous, everyone is talking about it, your product is in the headlines everywhere ❤. There will be a flood of new users trying to use your service. According to some random folks on internet, 1 server can handle ~2500 active discord groups load. This can obviously vary based on your server resources and what actions your bot perform. Fortunately,
discord.js bot support
sharding Getting started | Discord.js Guide (discordjs.guide) but I would argue, it is much better to scale backend horizontally by running multiple instances of server behind application load balancers, using in-memory caches, etc. these are webservers in the end, you don't have to depend on discord to provide a way to scale.
Flexibility to experiment and optimize
Adding/Removing features becomes much easier, you can setup multiple environments like production and development allowing you to safely work on experimental features without affecting actual customers or their data. You can also work on optimizations behind the scenes without touching the
Freedom to try out new technology
Each microservice has separate codebase which can be updated independently of other services. Microservices plays really well with continuous integration and continuous delivery by providing ability to have different deployment pipelines.
Leaner teams and increased productivity
Micro-service codebases are smaller in size and thus much faster to build, test and release. One do not depend on other to make a release after which you can release yours. We can have people work on domains/areas where they have expertise. Not being forced to collaborate with everyone let’s developers focus on their tasks and increase productivity.