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 its 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!

Working Group Updates

GraphQL Foundation marketing committee

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.

Release plan for next version of GraphQL specification

The next release is in the final stages of review and is anticipated to be released soon. Details on the release are TBD.

Schema Coordinates update

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.

Full unicode support

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.

Fragment Arguments RFC

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.

Roundtable discussion on @defer/@stream

Read the lengthy and informative conversation here, or watch on YouTube here.

graphql-js update on the Typescript migration

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.

Default Value Coercion RFC

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.

Glossary RFC

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.

Query Level Nullability RFC

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.

In Other News…

Upcoming Events

Get Involved!

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.