Accessing headers with the axum service #1599

musjj · 2024-09-23T21:16:59Z

musjj
Sep 23, 2024

The official example recommends something like this:

examples/axum/token-from-header/src/main.rs

async fn graphql_handler(
    State(schema): State<TokenSchema>,
    headers: HeaderMap,
    req: GraphQLRequest,
) -> GraphQLResponse {
    let mut req = req.into_inner();
    if let Some(token) = get_token_from_headers(&headers) {
        req = req.data(token);
    }
    schema.execute(req).await.into()
}

But you lose all the nice features/logic you would get with the async_graphql_axum::GraphQL service:

async-graphql/integrations/axum/src/query.rs

Lines 54 to 88 in 3046ae7

    
           fn call(&mut self, req: HttpRequest<B>) -> Self::Future { 
        
               let executor = self.executor.clone(); 
        
               let req = req.map(Body::new); 
        
               Box::pin(async move { 
        
                   let is_accept_multipart_mixed = req 
        
                       .headers() 
        
                       .get("accept") 
        
                       .and_then(|value| value.to_str().ok()) 
        
                       .map(is_accept_multipart_mixed) 
        
                       .unwrap_or_default(); 
        
                   if is_accept_multipart_mixed { 
        
                       let req = match GraphQLRequest::<GraphQLRejection>::from_request(req, &()).await { 
        
                           Ok(req) => req, 
        
                           Err(err) => return Ok(err.into_response()), 
        
                       }; 
        
                       let stream = executor.execute_stream(req.0, None); 
        
                       let body = Body::from_stream( 
        
                           create_multipart_mixed_stream(stream, Duration::from_secs(30)) 
        
                               .map(Ok::<_, std::io::Error>), 
        
                       ); 
        
                       Ok(HttpResponse::builder() 
        
                           .header("content-type", "multipart/mixed; boundary=graphql") 
        
                           .body(body) 
        
                           .expect("BUG: invalid response")) 
        
                   } else { 
        
                       let req = 
        
                           match GraphQLBatchRequest::<GraphQLRejection>::from_request(req, &()).await { 
        
                               Ok(req) => req, 
        
                               Err(err) => return Ok(err.into_response()), 
        
                           }; 
        
                       Ok(GraphQLResponse(executor.execute_batch(req.0).await).into_response()) 
        
                   } 
        
               }) 
        
           }

Is there really no better way of accessing the headers with the axum service without copy-pasting all of the code above?

janos-r · 2025-01-06T09:15:13Z

janos-r
Jan 6, 2025

I absolutely agree, I also have to do this manual execution that feels almost like a hack, totally skipping the intended API.

https://github.com/janos-r/axum-template/blob/4e95a988408a6770f62ea50bcae4d57074bfeb27/src/graphql.rs#L19-L46

But I do have an idea! If the official code in

async-graphql/integrations/axum/src/query.rs

Lines 39 to 46 in 3046ae7

    
           impl<B, E> Service<HttpRequest<B>> for GraphQL<E> 
        
           where 
        
               B: HttpBody<Data = Bytes>   Send   'static, 
        
               B::Data: Into<Bytes>, 
        
               B::Error: Into<BoxError>, 
        
               E: Executor, 
        
           { 
        
               type Response = HttpResponse<Body>;

Wouldn't return an HTTP response but a async_graphql::Response simply just not doing the .into_response() at the end which shouldn't be necessary anyway I think, we than could call the function as it is for execution and than edit the result as we need, and later just return the same thing (and axum calls into_response on it) or we call into_response at the end in our handler ourselves.
That way we don't have to do the manual execution!
Also can someone explain to me why it is a tower_service in the first place? If this is supposed to be an axum integration, wouldn't it be better to have it as a simple function handler to give to a .post(gql_handler) directly?

Any ideas?

0 replies

janos-r · 2025-01-06T10:50:35Z

janos-r
Jan 6, 2025

no better way of accessing the headers

In my case, I need to access the errors that are created in the async_graphql::Response, that's why I recommend (to the library authors) extracting the call function out of the tower_service and simply provide one recommended unified way how to execute the schema, while being able to edit the result afterwards.
But in your case, the headers are already there before the execution right? Can't you just make a middleware that you put in a layer before the gql? That would have access to get the headers and can pass something on in an Extension.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Accessing headers with the axum service #1599

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 2 comments

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

Accessing headers with the axum service #1599

musjj Sep 23, 2024

Replies: 2 comments

janos-r Jan 6, 2025

janos-r Jan 6, 2025

musjj
Sep 23, 2024

janos-r
Jan 6, 2025

janos-r
Jan 6, 2025