Serverless Telegram Bots Integration/Support

[NoobInTheNet]

Rust Teloxide Framework Integration with AWS Lambda for Serverless Telegram Bots

Hello Rustaceans and Teloxide enthusiasts! 🦀

I'm currently working on an exciting project where I aim to deploy a Telegram bot using the Teloxide framework within a serverless environment, specifically AWS Lambda Functions. The idea is to leverage the on-demand execution capabilities of AWS Lambda, where each incoming message from the Telegram API triggers a specific Lambda function via webhook endpoints.

Current Progress:

• Successfully set up the Telegram API to call the AWS Lambda function.
• Lambda function can parse the incoming body to extract the "Update" from Telegram.

Tools & Frameworks:

• aws-lambda-rust-runtime for Lambda runtime integration.
• cargo-lambda for project scaffolding and testing.
• State/Context persistence in Redis (even I'm using SQLite on local development).
• Long-term persistence in a cloud-based NoSQL or SQL database (considering Rust SeaORM or similar).

The Challenge:

While I've made significant progress, I'm currently facing a challenge in integrating Teloxide, especially with its Dispatcher Tree (DPTree). My goal is to programmatically pass the incoming update JSON into Teloxide's DPTree. This would allow the DPTree to act as a router, checking the state and other filters, and then directing the Update to the appropriate function. After processing the update, the function would update the State/context, send a reply, and terminate the instance.

Given the nature of this setup, there's no need for a graceful shutdown since the webhook will remain set up. An alternative approach I considered was using a Docker image with an NGINX frontend to handle SSL and redirect internally to the Teloxide AXUM server. However, I believe the initial serverless approach would be more cloud-native and optimized.

Seeking Community Input:

I'm reaching out to the community, especially those familiar with Teloxide and serverless architectures, for recommendations and brainstorming:

1. Integration with DPTree: How can I best integrate the incoming update JSON with Teloxide's DPTree without the need of enabling polling/webhook server on Teloxide's end?
2. State Management: Given the ephemeral nature of Lambda functions, what's the best approach to manage and persist state/context effectively?
3. Optimizations: Are there any best practices or optimizations I should consider for this serverless bot setup?
4. Alternative Approaches: While I'm inclined towards the serverless approach, I'm open to suggestions that might offer better performance or simplicity.

I genuinely believe that with the combined knowledge and expertise of this community, we can come up with a robust and efficient solution. Looking forward to your insights and suggestions! And I would love, once I get this product working, to scaffold it and in the close future release a community-available serverless integration for Teloxide 😄.

Cheers!

[Enucatl]

As a starting point, you should be looking into webhooks:

https://docs.rs/teloxide/0.12.2/teloxide/update_listeners/webhooks/index.html

[WaffleLapkin]

Given the nature of this setup, there's no need for a graceful shutdown since the webhook will remain set up

I don't think that's true, graceful shutdown also makes sure that all the updates are actually processed, which you do want.

---

Teloxide is not designed with serverless architecture in mind, so you'll have to reinvent something.

I would suggest doing one of two things:

1. Copying code that works with dptree from dispatcher
2. Making your own UpdateListener that returns the single update and then shutdowns dispatcher

The second option can be tricky and cumbersome, so I'd probably go with the first one. In which case you just parse the update (I had the feeling you got this already?) and then insert Me, Bot and Update into the dependencies and call handler.dispatch(deps).await, and vualá — you got a drop-in replacement for dispatcher that processes a single update. I could even maybe see this function added to teloxide itself, since I've seen multiple people trying serverless...

[jdiazcano]

Sorry for reviving this but I am actually trying to create a teloxide bot that runs on AWS Lambda. I know it has been tried before but everything seems to work with a few caveats.

1. The dispatcher is necessary because I am actually using dependencies and a dptree for knowing which command neds to be executed. Same thing as the challenge that is being described here.
2. Webhooks are usable but I would need to create the url and then pass that to the code which does not seem to be too right.
3. Using the dispatcher removes the current webhook

Now, everything separately is not really a problem, but together isn't really too usable.

I have been thinking that it should be possible to (as also described earlier in here) have a way to handle a lambda event where the json is parsed and passed to a dispatcher that does not modify, poll or behave in any special case, just handling the messages that are being sent to the function.

For me, this is very appealing as Rust + Lambda means that the bot does not have any kind of cold start and in my case I don't need to to be long lived to have some kind of cache or anything. It is just a matter of spinning up the function, responding and shutting down (maybe saving something to the database but it is optional).

I have tried with a custom listener that does not call the delete_webhook function but cannot make it work and webhooks seem overkill when we already have the body that would be returned and just need to parse and respond.

What are your thoughts on creating a new feature aws-lambda or something similar where you have a dispatcher that can handle an Event with a dptree and dependencies? Probably not even needed to have a new feature if we can get a string with the payload and pass it to the dispatcher, some kind of static dispatcher.

Thanks!

[WaffleLapkin]

You don't need Dispatcher to use dptree though. If you need to process a single update with dptree it's literally as easy as this:

async fn process_update<E>(update: Update, tree: UpdateHandler<E>) {
    if let UpdateKind::Error(err) = upd.kind {
        log::error!(
            "Cannot parse an update.\nError: {:?}\n\
             This is a bug in teloxide-core, please open an issue here: \
             https://github.com/teloxide/teloxide/issues.",
            err,
        );
        return;
    }

    let dependencies = deps![update, ...]; // you probably need the bot, etc

    match tree.dispatch(dependencies).await {
        ControlFlow::Break(Ok(())) => /* update handled successfully */,
        ControlFlow::Break(Err(err)) => /* update handled unsuccessfully */,
        ControlFlow::Continue(deps) => /* update not handled */,
    }
}

You are missing on

• allowed updates hinting
• dispatching key (an ability to process some updates in order)

But it's pretty much inevitable. All other Dispatcher features are not relevant to "process single update" scenario.

---

Webhooks are usable but I would need to create the url and then pass that to the code which does not seem to be too right.

I'm not entirely sure what you mean by that... Do you want an ability to use webhooks::axum, etc without teloxide calling set_webhook? There is currently axum_no_setup which allows for that. I am planning to remove it in #993 though, so if it's something you need please LMK.

---

Using the dispatcher removes the current webhook

No, that's not what's happening. What's happening is that Dispacher::dispatch uses polling_default which deletes webhook. You can use Dispatcher::dispatch_with_listener and provide your own listener and it will not touch webhooks.

---

I have tried with a custom listener that does not call the delete_webhook function but cannot make it work

What problems do you encounter?

---

What are your thoughts on creating a new feature aws-lambda or something similar where you have a dispatcher that can handle an Event with a dptree and dependencies? Probably not even needed to have a new feature if we can get a string with the payload and pass it to the dispatcher, some kind of static dispatcher.

Well. I don't think Dispatcher has anything to do with this function. Dispatcher is all about managing update stream, workers, shutdown, allowed updates¹, ...; If you have a single update all of those features are not needed and are even bad.

I'm don't really have anything against adding a function like process_update above. But at the same time, I don't really see the reason to add it, as it's so simple. If you don't care about errors too much, it's literally just tree.dispatch(dependencies).await.

---

Hope that helps!

Footnotes

1. this one is interesting but requires changing arguments to get_updates / set_webhook which is outside of the "handle single update" interface ↩

[jdiazcano]

It was very easy after knowing that it is possible to just dispatch the dependencies and the Update within it. I just had to look that the Update was what Telegram was sending to the Webhook and parse it.

#[tokio::main]
async fn main() -> Result<(), Error> {
    pretty_env_logger::init();
    lambda_runtime::run(service_fn(bot_handler)).await
}

async fn bot_handler(event: LambdaEvent<LambdaFunctionUrlRequest>) -> Result<(), Error> {
    let bot = Bot::new("token");
    let forward_email_client = ForwardEmailClient::new("https://api.forwardemail.net/v1/");
    let bot_context = BotContext {
        forward_email_client: Box::new(forward_email_client),
        maintainer: UserId(myId)
    };

    let update: Update = serde_json::from_str(&event.payload.body.unwrap()).unwrap();

    let handler = Update::filter_message()
        .branch(dptree::entry()
            .filter_command::<Command>()
            .endpoint(handle)
        )
        .branch(dptree::filter(is_master)
            .filter_command::<MasterCommand>()
            .endpoint(master_handle));

    let me: Me = bot.get_me().await?;

    let dependencies = deps![me, bot, update, bot_context];

    handler.dispatch(dependencies).await;

    Ok(())
}

So I think it is very easy, I might even try to add a small example for the examples folder as this might be useful for other people!