tamasfe/aide

[Feature Request] proc_macro router auto gen

y-haidar opened this issue · 2 comments

Hi, I am experimenting on giving a rocket like experience but with axum, like so:

#[aide::make_router(
  state = Arc<AppState>,
  nest(api_router_1, path = "/apiV1"),
  nest(api_router_2, path = "/apiV2"),
)]
mod root_router {
  use std::sync::Arc;
  use axum::extract::State;
  use crate::AppState;

  #[aide::get("/")]
  pub async fn index(_: State<Arc<AppState>>) -> String {
    "index".to_owned()
  }

  #[aide::post("/yay")]
  pub async fn yay() -> String {
    "yay".to_owned()
  }

  fn yay_docs(op: TransformOperation) -> TransformOperation {
    op.description("yay")
      .response::<201, String>()
  }

  // Untouched examples
  #[some_crate::some_attr_macro]
  pub fn some_other_fn() {}
  pub struct MyStruct2 {}
}

It would generate something like this:

mod root_router {
  // ... original code but remove aide specific attributes

  pub fn make_router() -> aide::ApiRouter<Arc<AppState>> {
    ApiRouter::new()
    .api_route("/", get(index))
    .api_route("/yay", post_with(yay, yay_docs))
    .nest_api_service("/apiV1", api_router_1::make_router())
    .nest_api_service("/apiV2", api_router_2::make_router())
  }
}

Transform operations can be detected with this format SOME_ROUTE_FUNCTION_NAME_doc. The _doc at the end of a function name is what determine whether to use get or get_with. The aide::make_router attribute macro is the only one implemented. The other macros like the aide::post attribute macros are fake, but should be create for documentation purposes(panic if used outside of aide::make_router.

I have a poc on my local machine but with axum router. Are you interested if I work on this feature for aide?

Hi a crate does something like this with aide support: https://crates.io/crates/axum-typed-routing

Great! I couldn't find it on my own. Closing