10/15/2020 by GraphQL Foundation
GraphQL has redefined how developers work with APIs and client-server interactions. And as the community works hard to foster the growth and adoption of GraphQL, we are excited to share the work of the community and discussions via a new monthly GraphQL Foundation newsletter.
All work on GraphQL and related projects, both big and small, is important to the growth and maturity of the project, which has already seen adoption from many of the world’s largest internet-scale companies.
Many of these items are just in beginning discussions while some are further along. The goal of this monthly post is to summarize and share what’s top of mind for the community and help others get involved. These are only initial discussion topics. For notes on the full discussion during the monthly WG calls please refer to these call notes.
Discussed whether the spec should allow deprecating an input that is required. Two concerns: deprecations are intended to be actionable; introspection does not include deprecated things by default - could break tooling that's no longer receiving deprecated inputs as part of their introspection results. Regarding case 1: not much of a blocker; the action from deprecation doesn't need to come from a schema (e.g. it could be switch to a new version/endpoint) Regarding case 2: much more of an issue because we could be breaking clients. My suggestion is to return required arguments even if they're deprecated - introspection should always give you what's necessary even if you say you don't want it.
trying to answer the “why we don’t support Defer on field question”. The reasoning for that is the original Apollo implementation was only on fields. We ran into problems in that it’s difficult to coordinate
The issue was first raised around the ambiguity of the term "query" as used in the GraphQL spec and ecosystem back in April. In just this title, we've referred to requesting, the Query type, a query operation, and a nested selection set; but that's just some of the ways we use this term, which can make it really hard for people new to GraphQL to get up to speed. Benjie has analyzed the use of the term, and has proposed a consistent set of terminology to use based on other terms used in the GraphQL spec already, this was discussed at the most recent Working Group. See Spec PR #777.
Vscode-graphql, which uses the official GraphQL Language Server, has now become the official reference vscode extension! Like GraphiQL, we will work to ensure all new spec language features are introduced here. After making the announcement we gained 30,000 new users! This blog post will tell you more about all the new features.
Developers can get involved in the community and contribute to the project at https://github.com/graphql.
Organizations interested in becoming members of the GraphQL Foundation or the GraphQL Specification can learn more on our member page. If you have questions about membership, please send an email to membership@graphql.org.