6/30/2021 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 the monthly GraphQL Foundation newsletter.
GraphQL reached new heights in 2020 and is only poised to continue it’s meteoric rise in 2021. Thank you again for your involvement in this project and your support of the GraphQL Foundation. We are excited for another productive year!
The newly created GraphQL Foundation marketing committee is responsible for coordinating marketing activities in support of the Foundation and the projects. They meet regularly, and welcome participation from Foundation and community members.
The meeting agendas and minutes are open and available in meetings/. We generally meet on the fourth Thursday of the month at 9am PT. To be added to the recurring invite, please contact operations@graphql.org.
The next release is in the final stages of review and is anticipated to be released soon. Details on the release are TBD.
The WG is evaluating how to use Schema Coordinates (e.g. what can we improve by using schema coordinates, and is Looking for support in advancing from Draft to Accepted.
The WG is looking for support in advancing this iteration from Proposal to Draft. Most notably full unicode is already supported today, albeit without having explicit tests for it.
The only new code that is added is the verification of the surrogate pairs. The current implementation allows for invalid surrogate pairs.
For the past 5+ years, Relay has had the @arguments directive, which is not spec compliant. In some sense, Relay is a dual GraphQL client: there's Relay syntax which is used to resolve data available locally on the client, and then that syntax compiles down into a spec compliant syntax to resolve data from an external source (aka a "server"), which hydrates a graph of "local" data the relay-specific resolvers operate over.
This means Relay can get away with having user-written fragments that are freed from operation-defined knowledge: Relay's fragments can be provided with variable values that were never defined at the operation level, to use when resolving arguments.
Read the lengthy and informative conversation here, or watch on Youtube here.
The working group will be converting as much of graphql-js to TypeScript as possible, which will probably need some breaking changes due to default values and other changes. One of the aims is to also be readable so they might release these breaking changes along with the TypeScript migration.
The WG has spent several weeks working to integrate the default value changes into GraphQL Ruby, which has resulted in several architectural discussions and some bug reports.
The purpose of this RFC is to add clarity and precision, especially after the many meanings of a query. The WG is working to define the terms first, then will revisit extracting it into an appendix.
Used by many including Yelp and Netflix, the proposal is to allow queries that can include a non-null designator (!) to indicate that a field should be treated non-nullable and if it returns null it should escalate following the standard GraphQL error bubbling.
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.