🤖 An elegant Telegram bots framework for Rust https://docs.rs/teloxide
Find a file
2020-10-24 19:59:08 +03:00
.github/workflows Add tests for sqlite storage 2020-10-24 19:51:55 +03:00
examples Add a bot example for SqliteStorage 2020-10-24 19:57:51 +03:00
media Replace media/PING_PONG_BOT.gif with DICES_BOT.gif 2020-07-29 16:10:19 +06:00
src Get rid of an unnesessary TODO 2020-10-24 19:59:08 +03:00
tests Add tests for sqlite storage 2020-10-24 19:51:55 +03:00
.gitignore Add tests for sqlite storage 2020-10-24 19:51:55 +03:00
Cargo.toml Add tests for sqlite storage 2020-10-24 19:51:55 +03:00
CHANGELOG.md Merge branch 'dev' into v0.3.1_release 2020-09-26 19:01:16 +03:00
CODE_STYLE.md Update CODE_STYLE.md 2020-10-01 17:58:26 +06:00
CONTRIBUTING.md make 'dev' default branch in docs 2020-08-17 18:10:03 +03:00
ICON.png Improve the ICON.png quality 2019-10-15 16:16:56 +06:00
LICENSE Update LICENSE 2020-02-22 02:56:02 +06:00
logo.svg Make logo svg 2019-12-30 12:14:05 +03:00
netlify.toml add docs|master badge and netlify config 2020-08-12 22:49:58 +03:00
README.md Update README.md 2020-10-08 20:02:35 +07:00
rustfmt.toml Use the default characters per line limit 2020-07-26 23:47:02 +06:00

teloxide

A full-featured framework that empowers you to easily build Telegram bots using the async/.await syntax in Rust. It handles all the difficult stuff so you can focus only on your business logic.

Table of contents

Highlights

  • Functional reactive design. teloxide follows functional reactive design, allowing you to declaratively manipulate streams of updates from Telegram using filters, maps, folds, zips, and a lot of other adaptors.
  • Dialogues management subsystem. We have designed our dialogues management subsystem to be easy-to-use, and, furthermore, to be agnostic of how/where dialogues are stored. For example, you can just replace a one line to achieve persistence. Out-of-the-box storages include Redis.
  • Strongly typed bot commands. You can describe bot commands as enumerations, and then they'll be automatically constructed from strings — just like JSON structures in serde-json and command-line arguments in structopt.

Setting up your environment

  1. Download Rust.
  2. Create a new bot using @Botfather to get a token in the format 123456789:blablabla.
  3. Initialise the TELOXIDE_TOKEN environmental variable to your token:
# Unix-like
$ export TELOXIDE_TOKEN=<Your token here>

# Windows
$ set TELOXIDE_TOKEN=<Your token here>
  1. Make sure that your Rust compiler is up to date:
# If you're using stable
$ rustup update stable
$ rustup override set stable

# If you're using nightly
$ rustup update nightly
$ rustup override set nightly
  1. Run cargo new my_bot, enter the directory and put these lines into your Cargo.toml:
[dependencies]
teloxide = "0.3.1"
teloxide-macros = "0.3.2"

log = "0.4.8"
pretty_env_logger = "0.4.0"

tokio = { version =  "0.2.11", features = ["rt-threaded", "macros"] }

API overview

The dices bot

This bot replies with a dice throw to each received message:

(Full)

use teloxide::prelude::*;

#[tokio::main]
async fn main() {
    teloxide::enable_logging!();
    log::info!("Starting dices_bot...");

    let bot = Bot::from_env();

    teloxide::repl(bot, |message| async move {
        message.answer_dice().send().await?;
        ResponseResult::<()>::Ok(())
    })
    .await;
}

Commands

Commands are strongly typed and defined declaratively, similar to how we define CLI using structopt and JSON structures in serde-json. The following bot accepts these commands:

  • /username <your username>
  • /usernameandage <your username> <your age>
  • /help

(Full)

use teloxide::{utils::command::BotCommand, prelude::*};

#[derive(BotCommand)]
#[command(rename = "lowercase", description = "These commands are supported:")]
enum Command {
    #[command(description = "display this text.")]
    Help,
    #[command(description = "handle a username.")]
    Username(String),
    #[command(description = "handle a username and an age.", parse_with = "split")]
    UsernameAndAge { username: String, age: u8 },
}

async fn answer(cx: UpdateWithCx<Message>, command: Command) -> ResponseResult<()> {
    match command {
        Command::Help => cx.answer(Command::descriptions()).send().await?,
        Command::Username(username) => {
            cx.answer_str(format!("Your username is @{}.", username)).await?
        }
        Command::UsernameAndAge { username, age } => {
            cx.answer_str(format!("Your username is @{} and age is {}.", username, age)).await?
        }
    };

    Ok(())
}

#[tokio::main]
async fn main() {
    teloxide::enable_logging!();
    log::info!("Starting simple_commands_bot...");

    let bot = Bot::from_env();

    let bot_name: String = panic!("Your bot's name here");
    teloxide::commands_repl(bot, bot_name, answer).await;
}

Dialogues management

A dialogue is described by an enumeration where each variant is one of possible dialogue's states. There are also subtransition functions, which turn a dialogue from one state to another, thereby forming a FSM.

Below is a bot that asks you three questions and then sends the answers back to you. First, let's start with an enumeration (a collection of our dialogue's states):

(dialogue_bot/src/dialogue/mod.rs)

// Imports are omitted...

#[derive(Transition, From)]
pub enum Dialogue {
    Start(StartState),
    ReceiveFullName(ReceiveFullNameState),
    ReceiveAge(ReceiveAgeState),
    ReceiveLocation(ReceiveLocationState),
}

impl Default for Dialogue {
    fn default() -> Self {
        Self::Start(StartState)
    }
}

When a user sends a message to our bot and such a dialogue does not exist yet, a Dialogue::default() is invoked, which is a Dialogue::Start in this case. Every time a message is received, an associated dialogue is extracted and then passed to a corresponding subtransition function:

Dialogue::Start

(dialogue_bot/src/dialogue/states/start.rs)

// Imports are omitted...

pub struct StartState;

#[teloxide(subtransition)]
async fn start(_state: StartState, cx: TransitionIn, _ans: String) -> TransitionOut<Dialogue> {
    cx.answer_str("Let's start! What's your full name?").await?;
    next(ReceiveFullNameState)
}
Dialogue::ReceiveFullName

(dialogue_bot/src/dialogue/states/receive_full_name.rs)

// Imports are omitted...

#[derive(Generic)]
pub struct ReceiveFullNameState;

#[teloxide(subtransition)]
async fn receive_full_name(
    state: ReceiveFullNameState,
    cx: TransitionIn,
    ans: String,
) -> TransitionOut<Dialogue> {
    cx.answer_str("How old are you?").await?;
    next(ReceiveAgeState::up(state, ans))
}
Dialogue::ReceiveAge

(dialogue_bot/src/dialogue/states/receive_age.rs)

// Imports are omitted...

#[derive(Generic)]
pub struct ReceiveAgeState {
    pub full_name: String,
}

#[teloxide(subtransition)]
async fn receive_age_state(
    state: ReceiveAgeState,
    cx: TransitionIn,
    ans: String,
) -> TransitionOut<Dialogue> {
    match ans.parse::<u8>() {
        Ok(ans) => {
            cx.answer_str("What's your location?").await?;
            next(ReceiveLocationState::up(state, ans))
        }
        _ => {
            cx.answer_str("Send me a number.").await?;
            next(state)
        }
    }
}
Dialogue::ReceiveLocation

(dialogue_bot/src/dialogue/states/receive_location.rs)

// Imports are omitted...

#[derive(Generic)]
pub struct ReceiveLocationState {
    pub full_name: String,
    pub age: u8,
}

#[teloxide(subtransition)]
async fn receive_location(
    state: ReceiveLocationState,
    cx: TransitionIn,
    ans: String,
) -> TransitionOut<Dialogue> {
    cx.answer_str(format!("Full name: {}\nAge: {}\nLocation: {}", state.full_name, state.age, ans))
        .await?;
    exit()
}

All these subtransition functions accept a corresponding state (one of the many variants of Dialogue), a context, and a textual message. They return TransitionOut<Dialogue>, e.g. a mapping from <your state type> to Dialogue.

Finally, the main function looks like this:

(dialogue_bot/src/main.rs)

// Imports are omitted...

#[tokio::main]
async fn main() {
    teloxide::enable_logging!();
    log::info!("Starting dialogue_bot...");

    let bot = Bot::from_env();

    teloxide::dialogues_repl(bot, |message, dialogue| async move {
        handle_message(message, dialogue).await.expect("Something wrong with the bot!")
    })
    .await;
}

async fn handle_message(cx: UpdateWithCx<Message>, dialogue: Dialogue) -> TransitionOut<Dialogue> {
    match cx.update.text_owned() {
        None => {
            cx.answer_str("Send me a text message.").await?;
            next(dialogue)
        }
        Some(ans) => dialogue.react(cx, ans).await,
    }
}

More examples!

Recommendations

  • Use this pattern:
#[tokio::main]
async fn main() {
    run().await;
}

async fn run() {
    // Your logic here...
}

Instead of this:

#[tokio::main]
async fn main() {
    // Your logic here...
}

The second one produces very strange compiler messages due to the #[tokio::main] macro. However, the examples in this README use the second variant for brevity.

Cargo features

  • redis-storage -- enables the Redis support.
  • cbor-serializer -- enables the CBOR serializer for dialogues.
  • bincode-serializer -- enables the Bincode serializer for dialogues.
  • frunk -- enables teloxide::utils::UpState, which allows mapping from a structure of field1, ..., fieldN to a structure of field1, ..., fieldN, fieldN+1.

FAQ

Q: Where I can ask questions?

A: Issues is a good place for well-formed questions, for example, about:

  • the library design;
  • enhancements;
  • bug reports;
  • ...

If you can't compile your bot due to compilation errors and need quick help, feel free to ask in our official Telegram group.

Q: Do you support the Telegram API for clients?

A: No, only the bots API.

Q: Why Rust?

A: Most programming languages have their own implementations of Telegram bots frameworks, so why not Rust? We think Rust provides a good enough ecosystem and the language for it to be suitable for writing bots.

UPD: The current design relies on wide and deep trait bounds, thereby increasing cognitive complexity. It can be avoided using mux-stream, but currently the stable Rust channel doesn't support necessary features to use mux-stream conveniently. Furthermore, the mux-stream could help to make a library out of teloxide, not a framework, since the design in this case could be defined by just combining streams of updates.

Q: Can I use webhooks?

A: teloxide doesn't provide special API for working with webhooks due to their nature with lots of subtle settings. Instead, you should setup your webhook by yourself, as shown in examples/ngrok_ping_pong_bot and examples/heroku_ping_pong_bot.

Associated links:

Q: Can I use different loggers?

A: Yes. You can setup any logger, for example, fern, e.g. teloxide has no specific requirements as it depends only on log. Remember that enable_logging! and enable_logging_with_filter! are just optional utilities.

Community bots

Feel free to push your own bot into our collection!

Contributing

See CONRIBUTING.md.