-
Notifications
You must be signed in to change notification settings - Fork 6
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
GraphQL wildcard field #9
Comments
I feel this is ignoring the community. All three of those bullet points are refuted when we take into account that these are professional, experienced developers who have read those previous concerns elsewhere and still want the feature. This unhelpful, "it's for performance" is not a valid reason to exclude a feature, where it's a choice of the developer. It's for philosophy. If it were purely performance, there could be flags, warnings, or limits. The consumer of persisted data and GraphQL may technically and philosophically be under the same control, but in actual use, organizational, knowledge domains, and practical matters often still keep these concerns separate. There's already explanation in comments, open issues, unanswered Stack Overflow questions, critical blog posts, and angry tweets that prove that there's an actual need, so I will leave it at that. |
I don't think this is the place to argue one way or the other for the future of the feature in the GraphQL spec (that's what the spec repo is for). The fact is that GraphQL does not currently have wildcard fields and people frequently ask why not. The intent of this issue is to suggest that we should have a canonical answer to this frequently asked question, the most salient reason IMO being that it enables the versionless schema design and evolution that GraphQL encourages. I have no problem with the answer linking to the discussion about the possibility of adding them in the future, but I think the FAQ should answer questions about the GraphQL specification as it stands. |
I see many people getting confused why GraphQL doesn't have a wildcard field; in fact I see some people calling GraphQL "half baked" and seeing the lack of wildcard as one of the reasons that justify their opinion.
I think this topic should be added to the FAQ. I wasn't comfortable adding a PR to proposals as it's not clear exactly what format the proposal should be in yet (they seem to be placeholders currently?).
IMO the lack of a wildcard field is one of GraphQL's biggest strengths - it forces clients to specify the fields that they need, which has a number of advantages:
Here's a massive conversation about this in the spec repo:
The text was updated successfully, but these errors were encountered: