Architecture
The telegram and telegram.ext packages contain several classes that make writing (chat)bots easy.
You have met most of them in the tutorial.
Because all of that can be a bit overwhelming, the below diagram gives you an overview of how the different components interact with each other.
python-telegram-bot is designed such that you can adjust it to many use cases.
In particular, many components/features are optional and some can even be fully customized.
The Updater class is there to fetch updates from the Bot API for your bot.
But you don't need to use it.
If you want to implement a custom mechanism to fetch updates (e.g. a custom webhook setup, you can just put your updates into the Application.update_queue or even manually call Application.process_update.
To build an Application that doesn't use an Updater, simply pass None to ApplicationBuilder.updater.
The JobQueue class integrates scheduling logic into the setup of telegram.ext.
This feature is optional.
If you don't need/want to use a JobQueue, simply pass None to ApplicationBuilder.job_queue.
The CallbackDataCache is the backend for caching arbitrary callback_data.
This feature must be explicitly activated to be used.
Please see this wiki page for more info.
The Defaults class allows you to specify default values for parameters that appear quite often, e.g. the parse_mode parameter.
This is an opt-in feature.
Please have a look at this wiki page for more info.
By default, data like Application.{chat, bot, user}_data is stored in-memory and is lost when the bot shuts down.
PTB includes an optional functionality to persist data across restarts, which BasePersistence as interface class at it's core.
Head to this page for more info.
By default, PTB will use the httpx library for the networking backend, i.e. making requests to the Bot API.
However, you are free to use a custom backend implementation as well.
For this, you'll have to implement the BaseRequest interface class and pass two instances of your custom networking class to
ApplicationBuilder.request and ApplicationBuilder.get_updates_request.
The Handler interface class is the most import class when it comes to the question of how the Application processes updates.
PTB comes with a number of built-in handler which cover most important use cases.
However, if you want to implement a custom logic of when an update should be handled, you can also write a custom implementation of Handler and use that.
As mentioned above, PTBs persistence functionality is based on the interface class BasePersistence.
To use persistence in PTB, you use an implementation of this class.
PTB comes already ships two implementations (see this page), but you are very welcome to implement a persistence class for your own serialization backend.
The class CallbackContext is a central part of the handler/job callbacks in PTB and more advanced users may want to add custom behavior to this class.
You can do so by passing an instance of the ContextTypes to ApplicationBuilder.context_types.
Have a look at this example for example use cases.