async support for Object trait

[gemhtcr]

https://docs.rs/minijinja/latest/minijinja/value/trait.Object.html

Is it okay to add a async version for call/call_method in Object trait ?

I understood that it might be difficult to add it because of the lifetime issue, but there are some cases where we have to query from database inside call/call_method to proceed

Proposal

pub trait Object: + Send + Sync  {
     [...]
     fn call(...) {...}
     async fn call_async(...) {... /*so we can query from database on the fly*/}    //  proposal

     fn call_method(...)  {...}
     async fn call_method_async(...)  {... /*so we can query from database on the fly*/}  // proposal
     [...]
}

impl minijinja::Template {
    [...]
    fn render() {...}
    async fn render_async() {...}  // proposal
    [...]
}

By supporting async above, it'd be more extensive and natural for minijinja to interact with database

Possible workaround

A possible workaround is to use undeclared_variables to query before calling render but that required extra complexity to parse those variables

[mitsuhiko]

Having async methods would mean that the entire render code path would have to become async. I don't think that's particularly appropriate for how the engine works. What I would do is just to call runtime.block_on in the method call. There are various patterns that could be done around it to make this better/more efficient if needed.

[gemhtcr]

Hi Mitsuhiko,
Thanks for the reply.
Before this post, I've actually tried runtime.block_on and it isn't intuitive as it looks. The following is a working version with block_on idea but the performance is pretty bad in my case

// rust
async foo() {
   // [...]
   // spawn_blocking is required, otherwise it failed the pressure test
   let _rendered_output = tokio::task::spawn_blocking(move ||
        get_minijinja_env().render_str(...)
   ).await;
   // [...]
}

impl StructObject for Foo {
    fn get_field(&self, name: &str) -> Option<Value> {
        // [...]
        let _bar = futures::executor::block_on(async move {
            // another_runtime() is another tokio runtime 
            another_runtime().spawn(async move { query_database().await }).await
        });
        // [...]
    }
}

Performance

I think the performance is bad because we block the current thread to wait for render

More

There are various patterns that could be done around it to make this better/more efficient if needed

I'm curious about the patterns here. Can you by any chance provide more detail ? 🙇‍♂️

[mitsuhiko]

I added an example here using Handle and spawn_blocking for render. This should resolve your performance issues if this pattern works for you: https://github.com/mitsuhiko/minijinja/blob/main/examples/object-using-async/src/main.rs

If you find it too hard to pass the handle into the template (eg: you cannot hold it in your structs) then you could bind it to a thread local before the render. In that case you might need to make a more convenient wrapper around.