Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible API improvements to juniper_hyper #1102

Open
LukasKalbertodt opened this issue Sep 12, 2022 · 1 comment
Open

Possible API improvements to juniper_hyper #1102

LukasKalbertodt opened this issue Sep 12, 2022 · 1 comment
Assignees
Labels
enhancement Improvement of existing features or bugfix k::api Related to API (application interface) k::integration Related to integration with third-party libraries or systems lib::hyper Related to `hyper` crate integration

Comments

@LukasKalbertodt
Copy link
Contributor

While working on #1101 , I thought of a couple more possible improvements.

For one, I think it would be useful to make parse_req and execute_request[_sync] public. With that, it would be possible to inspect the GraphQLRequest before executing it (e.g. for logging). It's even questionable whether the convenience graphql[_sync] functions are even necessary then, as they just call these two other functions.

All functions taking a Request<Body> should also be able to take a Request<String>. The body is converted to a string internally anyway and users of the library might already have a Response<String>. This also helps with users inspecting the request beforehand, given that String is much easier to use than hyper::Body. However, extending the API like that is a bit harder than #1101 as we still want to support Body.

@LukasKalbertodt LukasKalbertodt added the enhancement Improvement of existing features or bugfix label Sep 12, 2022
@tyranron
Copy link
Member

@LukasKalbertodt let's give it a try 😉

@tyranron tyranron added k::api Related to API (application interface) lib::hyper Related to `hyper` crate integration k::integration Related to integration with third-party libraries or systems labels Nov 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement of existing features or bugfix k::api Related to API (application interface) k::integration Related to integration with third-party libraries or systems lib::hyper Related to `hyper` crate integration
Projects
None yet
Development

No branches or pull requests

2 participants