There is tremendous learning value in interfacing a bot with a bot API directly, without going through an external bot building framework.
To provide some context, the chatbot I built sends the user daily Twitter trends. You don’t need Twitter to use it. If you do have a Twitter account, it serves as a supplement to your Twitter experience, because the trends it sends you are country-specific.
I learnt a lot about the interactions possible on a certain platform
It is rather simple when the chatbot and the user can only communicate in plaintext. However, different chat platforms like Facebook Messenger, Kik or Telegram provide different features and interactions that change the user experience substantially.
The best way to learn about what’s possible is to try their bot API directly, without going through an external framework or library.
For example, Telegram has a unique inline query feature, where the user can simply type “@bot_name ..” from any chat to get some results. Therefore, the user does not always have to start a private chat with the bot in order to benefit from it.
Once the query is submitted, the bot can process it and generate a list of results, which can be formatted in a variety of ways. When the user selects a result, the message will be sent to the chat. For performance reasons, lazy loading and caching are supported by Telegram.
A sample list of inline query results
As I was finishing my bot, I realized that it was not enough to send the user a list of Twitter trends. After all, the user may want to see tweets related to a certain trending topic, and one way to do that is to direct the user to Twitter via a specific link.
Thankfully, I discovered that the Telegram API supports custom hyperlinks with HTML <a> tags, so I could keep the message really succinct! The user can simply tap on an individual trend to open up Twitter and view the tweets related to it.
A list of trends with selectable hyperlinks
In contrast, Facebook Messenger currently does not support custom hyperlinks. If I decide to implement the bot in Messenger, I may have to show both trends and their URLs separately, which will result in a very long message.
As you can see, different platforms offer different features and interactions. The best way to learn about it is to try it. This may pay huge dividends in the long run when you need to optimize the user experience on different platforms.
I learnt about service messages
I thought that only the user could send messages to my bot.
However, I was surprised to receive messages that were not directly sent by the user! These messages are known as service messages, which are administrative in nature.
I realized that there was some value in handling some of these service messages. For example, when anyone (including my bot) joins a chat group, I will receive a service message from the platform indicating who it was. If it was my bot who had joined the group, I would send the introductory message as a reply without waiting for the user to say “/start”. Conversely, if my bot is evicted from a chat group, I will know about it and can treat that service message as a “/stop” message.
I handled the different ways in which the user could stop my bot
I informed the user to send “/stop” if they wanted to unsubscribe from daily updates. However, I learnt that not every user will send this message.
The Telegram chat client allows the user to stop the bot by pressing and holding on the chat and then selecting “Delete and stop”. Unfortunately, I do not get a service message when this happens. When I attempt to send a daily update to this user, Telegram will reply with “403 Forbidden, Bot was blocked by the user”.
I handled this error by removing the user from the list of subscribers, until the user decides to subscribe again. Therefore, I can save on future server resources as I will not try to send updates to this user anymore. Furthermore, it allows me to maintain an accurate count of the number of subscribers.
What about frameworks?
I have not tried using one yet. However, these are my initial thoughts on bot frameworks purely in terms of their interfacing capabilities with the APIs of various chat platforms.
While there may be some initial time savings gained by using frameworks, they do introduce a layer of complexity and have various limitations. For example, since frameworks need to be rather general to cater to many use cases, they come with functions that you may not need. They may not support all API features of a particular platform as well.
Without a framework, we can still build a bot that supports multiple platforms by having good software architecture. Interfaces that parse received messages and send back a custom response need to be platform-specific, but other components such as the database and interpretation of text can be common modules. Thus, we have full control over how we want to use each platform’s API for an optimal user experience. Furthermore, we can write just enough code for features that we want to use.
Though there is more upfront cost, the code is still server-side. Hence, it is not as expensive to support two chat platforms as it is to support native Android and iOS apps.
Just as with website builders and app builders that have come before bot builders, be aware of the pros and cons. Don’t feel obliged to use one!
To conclude Part 1/2
In building my chatbot without the use of a bot framework, I learnt about the different interactions possible on the platform I chose, the different kinds of messages, and the different ways that a user could stop the bot. As a result, I have gained a much better sense of that platform’s true capabilities. If I do eventually use a cross-platform framework, I will have a better awareness of its limitations.
In Part 2, I share more about parsing messages, handling timezones, and dealing with edge cases. Click here for Part 2!