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.

Sign up for GitHub

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

Jump to bottom

GraphQL over HTTP spec compliance (#1120) #1226

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

GraphQL over HTTP spec compliance (#1120) #1226

wants to merge 1 commit into from

Conversation

tyranron
Copy link
Member

@tyranron tyranron commented Nov 27, 2023 •
edited
Loading

@tyranron tyranron added enhancement Improvement of existing features or bugfix k::api Related to API (application interface) lib::rocket Related to `rocket` crate integration k::integration Related to integration with third-party libraries or systems lib::actix Related to `actix` crate integration lib::warp Related to `warp` crate integration lib::axum Related to `axum` crate integration lib::hyper Related to `hyper` crate integration labels Nov 27, 2023
@tyranron tyranron added this to the 0.16.0 milestone Nov 27, 2023
@tyranron tyranron self-assigned this Nov 27, 2023
@tyranron tyranron added the research Involves researching and investigation label Nov 27, 2023
@tyranron
Copy link
Member Author

@LegNeato after investigating it closely, the rabbit hole seems to be way deeper that I thought it would be. There are quite a lot of nuisances and details to be handled properly regarding different media types (for example, response codes for application/json and application/graphql-response+json are treated very differently), and moreover, spec implies few points for extension by user-side, while the core should remain.

Implementing all this separately for each integration crate would be painful and fragile. Moreover, integration crates are not doing well with extensibility. That's why, to implement this properly, it seems right to introduce a new juniper_graphql_http crate, providing a core http-crate-based implementation and being framework-agnostic, just as we have the juniper_graphql_ws crate for GraphQL over WebSocket specs.

This, however, quite a huge and time-consuming task, so I decided to move it from 0.16 milestone to 0.17 one.

@tyranron tyranron modified the milestones: 0.16.0, 0.17.0 Nov 27, 2023
@tyranron tyranron mentioned this pull request Nov 27, 2023
Open
@LegNeato
Copy link
Member

Make sense to me! I've been thinking that we'd probably need something similar, mirroring the http / tower stack

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@tyranron tyranron

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::actix Related to `actix` crate integration lib::axum Related to `axum` crate integration lib::hyper Related to `hyper` crate integration lib::rocket Related to `rocket` crate integration lib::warp Related to `warp` crate integration research Involves researching and investigation
Projects
None yet
Milestone
next major
Development

Successfully merging this pull request may close these issues.

Make sure we are compliant with new graphql over http spec
2 participants
@tyranron @LegNeato