Dora - A Fare Estimation Telegram Bot
Having worked for slightly over a year in an agile tech start-up as a developer, I've learnt so much in such a short time frame with regards to both programming and business. The environment there fueled my passion for building things (both useful and not too useful stuffs), and I could crunch out code through nights without feeling (too) tired because I genuinely enjoyed the process.
Yet when University began for me, things weren't as "hands-on" as I thought it would be; in fact only one of the courses, out of eight that I'm taking this semester, deals with programming, specifically in Python. The first three weeks revolved around the basics of the language and focused more on nurturing computational thinking than anything too technical. However, the fourth week was when the professor landed a group assignment on us - to create our very own Telegram Chat Bot in 5 weeks, and I remember getting incredibly thrilled as my brain instinctively starts googling for "How-to"s. The next few nights were thereafter unknowingly dedicated to this project, and I present Dora, a one-stop fare estimation Telegram chat bot.
Dora follows a simple conversation flow: You input a pick up and drop off location and the bot will return you fare estimations from 3 ride sharing/taxi companies active in Singapore, namely Uber, Grab and ComfortDelGro:
APIs that are currently integrated in this chatbot include:
- Google Places Distance Matrix
- Google Places Autocomplete
- Google Places
- Taxifarefinder
- Uber
- Airtable
Dora was somewhat technically simple and straightforward to build - API calls to the taxi companies using the latitude and longitude of the pick up and drop off locations to return the fare estimates and display them as buttons on the Telegram UI. We didn't manage to get Grab's API however due to the security issues, and thus our fare estimation for Grab is an arithmetic logic based on their fare structure on their web page. We'd first retrieve the estimate distance and duration (driving) between the two locations using Google Places Distance Matrix, and feed that those estimates into the Grab arithmetic function.
Dora is deployed on Heroku and is currently live so give it spin @dooorabot! If you'd like to get technical and check out the source code, here it is (you'll need your own API keys). What I would like to recap most, however, is more on the challenges that I faced while building this little chat bot.
Challenges: Maintaining conversation context
As Dora is dependent on user message inputs for the conversation flow, one of the main challenges that I faced was to have the bot keep context to the conversation, that is being able to intepret my next message and trigger the respective event. (e.g. Knowing that my next input is a pick up location or drop off location). And hence the idea of having a global variable chat_context initially came to mind, in which the variable will continuously be updated according to the stage of conversation.
For example, initating the fare estimation flow by sending '/taxi' to Dora will update chat_context to 'location_pickup', in which then Dora will know how to handle the next incoming message - call Google Places Autocomplete API with it. Once a pick up location has been selected, chat_context will then be updated to 'location_dropoff', and similarly, the next incoming message will be used to call the autocomplete API. chat_context will be reset to 'none' once the whole conversation flow is complete. This idea worked - but only if one user is querying the bot at a single time. It only occured to me that having the conversation flow depend on a global variable would mean that the variable will be highly volatile to mutations when we started testing the bot as a group and received messages in the complete wrong order.
My solution to this issue was thus to save each user's contextual information on a database, and have the bot query the specific user's information to validate which stage of the conversation that user is currently at. Airtable is an amazing tool to prototype databases incredibly quickly and I had one up within 5 minutes of configuration.
Apart from chat_context, I also saved a few other information as above (they were previously also stored as global variables) in the database, and this thus enabled Dora to handle unique conversations with users.
Is this the best solution to address this issue? I don't think so, but it was the best that I could think up at that point of time. Definitely keen to hear other possible solutions!
This article was updated on October 13, 2017