The current #[vlugin] interface is simple enough but needs some rework.

First, we won't have http messages, so on_request and the http dependency is deprecated. We will only have an on_message/on_msg that accepts a well known user defined message that implements Deserialize(on_create remains).
Current vlugin example:

#[vlugin]
pub async fn on_create(cx: &mut Context) {
    let someone = cx.config::<String>().unwrap();
    cx.set(someone   " says hello");
}

// DEPRECATED
pub async fn on_request(cx: &Context, req: http::Request) -> http::Result<http::Response> {
    // ...
    Ok("answer".into())
}

Second, the macro is too magic, it requires a build.rs script to parse the source file as "temporary" workaround for custom inner attributes not being available but it adds friction and the feature doesn't look like it will land anytime soon. Instead we can be a bit more verbose and create a derive macro for the message that the user needs to define

#[derive(Message, Deserialize)]
enum MyMsg {
    DoThing,
}

fn on_msg(cx: &Context, msg: MyMsg) {
    // ...
}

Third, the WASM support means we trash what's currently being generated to support dynamic libraries and replace it with a wasm_bindgen interface that can be called by the host JS environment.

Last, to compensate for the new added verbosity we can add an optional cqrs feature that provides macros that generate the boilerplate necessary for this recommended pattern of separating commands and queries.

#[cmd]
mod cmd {
    fn do_thing(cx: &Context, some_param: String) { ... }

    fn save_something(cx: &Context, some_param: String) { ... }
}

#[query]
mod query {
    fn get_stuff(cx: &Context, some_filter: MyFilter) { ... }
}

Nothing set in stone but good to start the conversation. @mrkaspa let me know what you think ;)