David Pedersen

juniper-eager-loading doesn’t yet support juniper 0.15. It’s quite tricky updating it to async and I haven’t had time to do it yet. So I’m afraid if you want to use...

Yeah that would work, but the project I'm working on right now it quite large so it takes a while to compile the docs. Seems a bit "wasteful" to do...

I've also found that "cp" conflicts with https://github.com/tpope/vim-fireplace

I have made a fork of this repo https://github.com/davidpdrsn/realworld-axum-sqlx with up to date dependencies.

This already exists in http-body-util as [BoxBody](https://docs.rs/http-body-util/0.1.0/http_body_util/combinators/struct.BoxBody.html) and [UnsyncBoxBody](https://docs.rs/http-body-util/0.1.0/http_body_util/combinators/struct.UnsyncBoxBody.html).

You generally don’t need to wrap Data. It’ll be Bytes is most cases. For error you can use `.map_err` to box it before wrapping it in BoxBody.

Are you intending to buffer the whole response body? If so, then yes it might contain more than one frame. You can get the whole response using [`BodyExt::collect`](https://docs.rs/http-body-util/latest/http_body_util/trait.BodyExt.html#method.collect): ```rust body.collect().await?.to_bytes()...

One could also argue that axum is too implicit in that a body magically gets turned into a response. > We couldn't make that breaking change to hyper, though. Maybe...

Yeah thats probably useful as well. However a straight `AsyncRead` to `Body` adapter is useful for example with `tokio::fs::File`.

IMO this unwrap is totally fine. The headers being added [here](https://github.com/hyperium/tonic/blob/c4525ba6ad21cf9db8d1857931f430cbe924aeb5/tonic-build/src/server.rs#L160-L161) are valid so it'll never panic.