Annoying struct for every handler

[szguoxz]

I found I have to create a struct for every handler just because I want to extract a single string parameter from the querystring. I looks very stupid code. anyway to make it better?
I understand that I can use dynamic approach, i.e., extract the data in the handler's func body through hashmap or whatever. But then I lost the rejection feature, and it looks even more stupid.
Any ideas? It's much easier in other dynamic languages like .net. but in RUST, seems that I have a jump the hoop of proc-macro?

[davidpdrsn]

Please show an example of the problem and the “dynamic approach”.

[szguoxz]

Here is the code I copied from crates.io, as you can see, it's taking a dynamic approach for parameter: "sort" and "include_yanked".
I really hope I can write something like this:
pub async fn search(app: AppState, sort: String, include_yanked: bool) -> AppResult<Json>

I know why this won't work. I need to package "sort" and "include_yanked" in a struct, and write:
pub async fn search(app: AppState, Query(sortyanked): Query< SortYanked >) -> AppResult<Json>

But really, declare a struct for every handler is ugly. Wondering if there is a better way.

pub async fn search(app: AppState, req: Parts) -> AppResult<Json> {
conduit_compat(move || {
use diesel::sql_types::{Bool, Text};

    let params = req.query();
    let sort = params.get("sort").map(|s| &**s);
    let include_yanked = params
        .get("include_yanked")
        .map(|s| s == "yes")
        .unwrap_or(true);

[szguoxz]

And in Dotnet, my handler is so simple and straight forward, of course, it's a dynamic language, we are not comparing here.

public object GetPhoneLog(int appID, string phone, string code, int minutesago)

[davidpdrsn]

public object GetPhoneLog(int appID, string phone, string code, int minutesago)

That seems almost too good to be true. How does C# know where to get the params from? Could either be in the query string or the request body.

You're right that such an API isn't possible and you have to either define and extract a struct, or extract Query<HashMap<String, String>> and get the values yourself. I'm not aware of other ways to implement it that aren't "just add macros". Would be interested to hear if you have any ideas.

[szguoxz]

First of all, the dotnet version is my own framework. I made it to search Query first, then Json body. The API can work for GET/POST at the same time.
You see, when I design the framework, I realize the take/give is very important. There's no perfect framework, only framework works best for you. For me, it takes care of 95% of my use cases, which is as good as it gets.
You are right that this can only be solved by adding Macros. But actually it's not an easy task even for macros.

I thought about it, here is my idea, just for discussion:

1. Create a Route proc macro, which can make the routing easier. Right Axum routing is quite awkward. A Macro will make it much better. Route("/xxz", Get(fn)) is really not good, as I have to repeat the function name. It should be a #[Route("/dsds")], maybe specify Methds, call it done. See, I hate repeat names, it's a way for bugs, even strong typed names.
2. In this routing macro, we need to do some magic: I. collect all fn parameters with a primitive type, such as String, u32, i32, bool ... etc. And define a struct, replace the function signature as: Query(__st$123 { p1, p2, p3 }): Query<__st$123>. 123 will be a sequence number to make it unique.
3. to make it better, create a new extractor: QueryBody, which will search query string first, then Json Body.

That being said, this approach has a couple problems:

1. I really hope Rust support Anonymous struct like c# does, but it doesn't, so we need to come up a unique struct name, or maybe use a mod name after the fn name.
2. String has already been taken by Extractor, this will override it. But I think it's a good choice. Use the String body as the parameter is very rare. That feature can use a work around.
3. We will only deal with a couple primitive types. Like I said, it will cover over 90% of the use cases, we are not looking for 100%,

[davidpdrsn]

Right Axum routing is quite awkward. A Macro will make it much better

I disagree. axum intentionally doesn't have macros as macros makes everything harder to compose and understand. Sounds like you want rocket.

I really hope Rust support Anonymous struct like c# does, but it doesn't, so we need to come up a unique struct name, or maybe use a mod name after the fn name.

I just name my structs FooParams if I have a foo handler. Works well.

We won't implement what you're describing but there is no reason you couldn't build that on top of axum if you wanted to.

[cryptrr]

The problem is that the Query parameter is a HashMap and there is no way to query directly for a parameter and get back the string value.

It would had been nice if you could extract specific query params by using Query(param_i_need) : Query<String>

and directly get the string value I need in the variable.

Having to make serializable structs just to extract a query parameter from the request is madness.