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

GraphQL wildcard field #9

Open
benjie opened this issue Aug 12, 2019 · 2 comments
Open

GraphQL wildcard field #9

benjie opened this issue Aug 12, 2019 · 2 comments

Comments

@benjie
Copy link
Member

benjie commented Aug 12, 2019

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:

  • it reduces back-end load, as less data needs to be calculated
  • it reduces bandwidth, as no unused data is transferred (no over-fetching)
  • most importantly, it enables the schema to be maintained in a versionless way - adding new fields to a type will not affect any existing queries, and we can determine which fields are being used so we know when we can safely remove deprecated fields (should we wish to do so)

Here's a massive conversation about this in the spec repo:

@snlacks
Copy link

snlacks commented Sep 3, 2019

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.

@benjie
Copy link
Member Author

benjie commented Sep 3, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants