In theprevious partofthis series, we created another database model named Message to hold the message-data from our Telegram bot. I also explained the process of defining a SQL schema using a Django model, what to consider during that phase and how to bring the Django’s model field reference docs to a good use during that process. Last but not least, we learned what a Heroku “ One-Off Dyno ” is and how it can be used to execute administrative tasks on our production site like applying outstanding migrations to a database.
This time, I will provide you with the last piece of the puzzle to make your bot available to the world. You will learn how to write and wire the python code toactually use all that we have prepared so far. At the end of this part, your bot will be able to receive and store each message sent to it by registered users. And since it’s already more than a month since I published the previous article in this series, let’s not waste any more time and jump right in!
A few more details on what we will do todayHow to link the outside world (Telegram servers) with your bot’s code and data(base) now? Actually, with Django, that’s quite easy. But if you have never done something like this, you might feel a little lost here.
By now, you have already achieved to:
… register a Telegram bot using “ BotFather “, the official interface provided by Telegram to register bots for their service. … create a Django project to start your work in. … prepare yourproject to be easily repeatable by creating a virtualenv and a Pipenv file and thus prepared it to be deployed to a containerized environment. … register an account at yourpreferredcode-hosting provider ( Heroku , if you followed the recommendations of this guide). … register a project with yourhosting provider to hold your Django project’s code, served by a Git remote and hook. … register a new app for your bot in the Django project. … create a database and configured your remotely deployed Django application to utilize it. … designyour database models to hold the data needed from Telegram messages for your bot’s purpose. … applied the migrations, which are created from your models definitions, to your production code hosting database.See? This is already a hell of a lot of complicated things! Managing to get this far is already a huge success! And since I did not receive a single question about anything from my previous articles ofthis series, you all did manage to achieve all of this successfully, didn’t you?:yum:
Great!
So, the last missing piece we have left in front of us is somehow bringing all these efforts together by creating a view .
Linking the outside world and your botOK, given the fact that we did not progress for more than a month with this project in the meantime (sorry for that, seriously:cry:), let’s first talk about what it is that we are trying to achieve next. Personally, when I’ve got hit by the “ Developer’s block ” (which happens more commonly the more time I let pass before I sit down and continue with a project), it helps me to form an easy yet explicit sentence, describing the task at hand.
For that, I’m trying not tothink about what it was that I’ve done last time or the details of my initial plan or something; it helps to establish a habit of not interrupting your work in the middle of something, really since this allows you to do so and not having to re-think where you left off! Always try to establish something SCRUM evangelists would call a “ potentially shippable artifact “, meaning: Something that could be added to a product already running in production without breaking anything but providing a new set of functionality or a good foundation to implement these in subsequent releases, at least.
In this project, that sentence could be something like:
Create an interface (called “ Webhook “), which the Telegram bot can connect to and submit messages it received.
In the Django world, this pretty perfectly describes a view. Cited from the very first sentences of the Django views docs :
A view function, or view for short, is simply a Python function that takes a Web request and returns a Web response. This response can be the HTML contents of a Web page, or a redirect, or a 404 error, or an XML document, or an image . . . or anything, really. The view itself contains whatever arbitrary logic is necessary to return that response. This code can live anywhere you want, as long as it’s on your Python path. There’s no other requirement no “magic”, so to speak. For the sake of putting the code somewhere, the convention is to put views in a file called views.py , placed in your project or application directory.
So, let’s fire up our preferred editor and open the file bot/views.py (since we will make all our modifications inside our “bot”-application directory).
So far, only our “ Hello World “-static content-view called index is in there. Another interesting file in this context is bot/urls.py ; open that in your editor as well.
So … let’s do the most obvious things first before we are diving into the logic. Think of a name for your view and create the basic skeleton for it in your bot/views.py file. The name is absolutely irrelevant; to prove that, I’ll continue with this called “ talkin_to_me_bruh “. You can come up with pretty much any name here as long as it’s unique. This won’t define the URL-path which the outside world is seeing or anything; it’s just the internal name of a function. So, my skeleton for“ talkin_to_me_bruh ” will look like this:
from django.http import HttpResponse def talkin_to_me_bruh(request): # please insert magic here return HttpResponse('OK')If we define a URLconf for this (which we will do in the next step) and navigate to this without inserting some magic at the “ please insert magic here ” marker, Django would nevertheless render an appropriate HTTP answer, containing the string OK in its body.
… why trust me I’m not a trustworthy person at all :smiling_imp:, so let’s just do it (not sponsored by