announcements

Jem GillamApril 16, 2026

The GraphQL Foundation is happy to announce the latest cohort of GraphQL Ambassadors! Ambassadors represent a diverse range of geographies, backgrounds, and use cases — from maintainers of popular libraries and meetup organizers to educators writing guides and tutorials, and beyond. Join us in welcoming Akshat, Ayush, Emily and Ivan to the team!

Ivan has been deeply involved in GraphQL since its early days, contributing extensively to graphql-js and the specification itself. He also authored the initial version of the GraphQL over HTTP specification, which formalises how GraphQL operations are transported over HTTP. Alongside this work, Ivan has been a regular speaker and advocate for GraphQL in the community.

Emily represents the next generation of spec and tooling contributors. Through her work on large-scale GraphQL gateways and her role championing the Field Extensions RFC, she is helping evolve how GraphQL schemas can be extended and composed in real-world systems. She has also been sharing her insights through talks and contributions to ecosystem tooling, bringing a thoughtful perspective as she continues to grow within the community.

Akshat brings a strong focus on practical GraphQL adoption - from performance and security best practices through to mentorship and community education - helping developers build robust APIs in real-world environments. Lastly, Ayush is exploring how GraphQL fits into the next generation of infrastructure, advocating for its role in orchestrating complex systems and inspiring more students and early-career engineers to get involved in the ecosystem.

Together, this cohort reflects both the depth and the future of GraphQL: experienced voices who have helped shape the ecosystem, and new contributors who are expanding its reach into new domains and communities.

How to Get Involved

• Nominate an Ambassador. Do you know someone doing incredible work with GraphQL? Nominate them (or yourself)!

• Connect locally. Attend events and workshops hosted by Ambassadors in your region.

• Share your story. If you’re publishing, teaching, or building with GraphQL, we’d love to hear from you.

What’s Next

The Ambassadors program is part of our broader effort to strengthen community engagement and education around GraphQL. Look forward to spotlights on our Ambassador team, upcoming blogs and speaking opportunities, and ways you can collaborate with these leaders.

Together, we’re building not just technology, but a thriving, global GraphQL community.

Seeking SMEs for GraphQL Conf 2026

Blog

announcements

Help the GraphQL ecosystem growApril 13, 2026

We’re excited to announce the first GraphQL ecosystem Call For Projects! If you are building tools, advocating, or more generally supporting GraphQL, this program is for you.

Our goal is to offer financial support and recognition for individuals who are helping move the ecosystem forward.

Each selected project will receive a $5000 grant as well as promotion on the GraphQL blog and socials.

The Call for Projects is part of the general GraphQL grant program and submissions must meet some criteria:

• Contributes to a project or another GraphQL property (YouTube, socials, …).
• Must be submitted by individuals (companies are not eligible for funding).
• Requires signature of a grant agreement (preview).
• Requires a graphql.org blog post explaining the work.

For 2026, we encourage participants to submit projects around the themes below:

• AI
• Golden path
• Security
• graphql-js improvements
• Guides and tutorials

For example, these topics have been discussed recently in the community and would be good starting points for contributions:

• Implement alternative serialization format (CBOR, argo) in graphql-js.
• Implement semantic introspection in graphql-js to make it easier for agents to discover GraphQL schemas and types.
• Implement new experimental GraphQL features such as or service capabilities in graphql-js.
• Implement a type-safe query builder library using TypeScript.
• Design and implement a “caniuse.graphql.org” website to make it easy to see at a glance what experimental features are supported in different frameworks.
• Propose and implement an alternative way to thread in inputs to @skip/@include (highlighted as a problem here).
• Design and implement a content hub for easily spreading the word about GraphQL.
• Run a GraphQL survey.
• Modernize and reimplement https://www.howtographql.com/ with modern tools.
• Document additional GraphQL Schema Guidelines on the graphql.org website.
• Illustrated guides for newcomers.

This list is not exhaustive and all submissions will be carefully examined. If you are unsure about where to start, join the Discord server to brainstorm ideas.

• May 31, 2026: deadline for submissions.
• June 30, 2026: winners are announced.
• Dec 31, 2026: program closes.

You can apply now by filing the GraphQL grant application.

For any questions please reach out to [email protected] or join the discussion on Discord (channel ).

We’re looking forward to your proposals!

Seeking SMEs for GraphQL Conf 2026

foundation

GraphQL FoundationApril 9, 2026

The primary mission of the GraphQL Foundation is to ensure that the GraphQL community is able to focus on the continued evolution of the specification and reference implementations. We accomplish this through a number of core activities, some of which are directly related to hosting and administering core projects, and others through growing and engaging the user community. Our budget is created and approved by our member companies via the Governing Board. As part of our commitment to transparency, we are publishing the first-ever GraphQL Foundation Budget Report and will continue to do so regularly into the future.

All figures are expressed in USD.

Link to Budget Summary Spreadsheet: GraphQL Foundation 2025-2026 Budget Summary

2025 Summary

We ended 2025 having spent 2.9% ($17,729) more than forecast. Details below.

What we learned

Event forecasting is a challenge. GraphQLConf 2025 underperformed in terms of sponsorship and attendance numbers. Thanks to the conservative budgeting by the Linux Foundation’s Events team, we also came in significantly under budget, which balanced out the ledger.

Carryovers are not ideal. The GraphQL Foundation is not a bank and should ideally not carry a large surplus year-over-year. This is because our funds are meant to be invested into our community! Our carryforward has progressively and appropriately shrunk over time; we are ending the year with $189,180 in the bank, a modest decrease from 2024’s figure.

Successful year for Developer Grants. Continuing the previous point, we awarded more grant money this year than ever before. These investments are at the heart of the GraphQL Foundation’s mission and should be celebrated.

Spending by category

Our budget is grouped into five different sections:

Community engagement and marketing

We spent $387,883. The biggest line item, by far, was GraphQLConf 2025. This category also included “swag” and social media management software.

Legal

We spent $213 on trademark maintenance.

General & administrative

This amounted to $36,682, attributable to finance, accounting, compliance auditing, taxes and governance support.

Staff, travel, and board

We spent $102,895 in this category. Nearly all of this went to Program Management services provided by the Linux Foundation and our Community Gardener, Graphile. LF Program Management takes care of back-of-house functions like conference coordination and membership management, while our Community Gardener manages various GraphQL Specification Project initiatives, including the main specification, GraphQL.js, GraphiQL, and countless other responsibilities that ensure the health of the technical project and support the mission of the Foundation. A small portion was allocated to fund staff travel to GraphQLConf.

IT infrastructure and staff

We spent $73,595 in this category, which includes typical IT infrastructure expenses such as hosting as well as our Developer Grant Program. The Developer Grant Program awarded $18,000 in grants in 2025 to community members who made meaningful improvements to GraphQL technical projects. Take a look, and consider applying for 2026!

Revenue

The GraphQL Foundation’s budget is drawn from member dues, conference sponsorships, conference attendee registration fees, and carryover from previous years. The GraphQL Foundation collected $219,667 in dues this year. We took in $187,910 in sponsorship and conference pass sales. We also had a $382,871 carryover from 2024.

2026 Budget

We are planning for $266,382 of expenditures and anticipating $211,000 of revenue, which will leave us with $133,798 to carry forward into 2027.

See the linked spreadsheet for a line-by-line breakdown. Our priorities this year are cutting administrative costs, right-sizing the conference, and adding new streams of funding for the Community Working Group, Ambassadors, and Locals to leverage. We believe this will create new sources of content, engagement, outreach, and education for our community.

Themes and priorities

A lean, smart budget. This year’s plan reduces overall spending without compromising on our mission. Despite outlying fewer expenditures, we are still able to hold our marquee event, invest in grants, and even introduce a new funding stream to our community.

Investment in our most engaged contributors. The GraphQL crowdfund is not a new platform but it hasn’t been very active since it was created. A lot has changed, though! 2025 brought us a new Community Working Group, GraphQL AI Working Group, and the Ambassadors Program. By expanding the surface area of the GraphQL project, we are inviting more contributors into the fold and magnifying the potential impact of our most engaged community members. The planned crowdfund block grants are there to support members of the community to be able to direct investment into areas that will support the mission of the GraphQL Foundation. Examples include boosting our YouTube presence, swag orders for acknowledging community contributions to technical working groups, and other tactical expenses. A charter will be necessary so that there is a common understanding of what expenses would be appropriate for this fund.

Meta’s investment makes a big difference. We were able to get this budget together in this shape thanks to the knowledge that Meta would be providing an incredible amount of support for GraphQLConf. The GraphQL community is so grateful for your investment. Thank you to everyone at Meta who is making this happen!

Making an impact

Supporting the GraphQL community is a valuable service. Consider joining the GraphQL Foundation, read more here. We would like to thank our current members for their continued investment in our mission. Consider sponsoring GraphQLConf 2026. Donations to the GraphQL Crowdfund help fund initiatives from the Community Working Group and our GraphQL Ambassadors initiative.

We are grateful for our community and hope this report serves the ecosystem well.

Seeking SMEs for GraphQL Conf 2026

announcements

Meet the GraphQL community worldwideApril 7, 2026

GraphQL Day (graphql.org/day) is going global in 2026! After a successful debut in Paris, GraphQL Day is going on tour worldwide as part of FOST (Future of Software Technologies) — a federation of conferences bringing together the GraphQL, AsyncAPI, OpenAPI, and JSON Schema communities.

GraphQL Day is the place to meet the GraphQL community: startups, enterprise, open source maintainers, vendors, business leaders, students and more! Expect content for both experts and beginners. FOST is the perfect opportunity to connect with wider ecosystem and stay on top of API technologies.

2026 Schedule

For 2026, you can expect GraphQL Days in the cities below:

More locations are being investigated. Subscribe to the GraphQL socials (X, BlueSky, LinkedIn, GraphQL Weekly) to get the latest news!

Call for Speakers

We’re looking for speakers across all events! Any GraphQL topic is welcome — production war stories, technical deep-dives, workshops, or lightning talks. We especially appreciate talks that speak to the broader FOST audience, including folks from adjacent API communities.

Submit your talk →

Get Your Tickets

Singapore tickets are available now, with tickets for the other cities coming soon. Visit graphql.org/day for all the details and to grab your spot.

See you there!

Seeking SMEs for GraphQL Conf 2026

announcements

Meet the GraphQL community worldwideApril 2, 2026

GraphQL Day (graphql.org/day) is going global in 2026! After a successful debut in Paris, GraphQL Day is going on tour worldwide as part of FOST (Future of Software Technologies) — a federation of conferences bringing together the GraphQL, AsyncAPI, OpenAPI, and JSON Schema communities.

GraphQL Day is the place to meet the GraphQL community: startups, enterprise, open source maintainers, vendors, business leaders, students and more! Expect content for both experts and beginners. FOST is the perfect opportunity to connect with wider ecosystem and stay on top of API technologies.

2026 Schedule

For 2026, you can expect GraphQL Days in the cities below:

More locations are being investigated. Subscribe to the GraphQL socials (X, BlueSky, LinkedIn, GraphQL Weekly) to get the latest news!

Call for Speakers

We’re looking for speakers across all events! Any GraphQL topic is welcome — production war stories, technical deep-dives, workshops, or lightning talks. We especially appreciate talks that speak to the broader FOST audience, including folks from adjacent API communities.

Submit your talk →

Get Your Tickets

Singapore tickets are available now, with tickets for the other cities coming soon. Visit graphql.org/day for all the details and to grab your spot.

See you there!

Seeking SMEs for GraphQL Conf 2026

announcements

Martin Bonnin and Mark LarahApril 1, 2026

GraphQL is ten years old. During those ten years, teams small and large have adopted the typesafe, concise query language. It powers everything from tiny side projects to some of the most demanding APIs on the planet. The type system, the developer tooling, the ecosystem — all of it has matured tremendously.

And yet, one thing has remained a persistent point of criticism: the HTTP 200 status code. By returning 200 even when errors occur, GraphQL makes it harder for existing monitoring tools, proxies, and CDNs to detect failures. Teams building on GraphQL have had to work around this limitation from day one, and it remains one of the most common pain points raised by newcomers and experienced users alike.

Today, we’re fixing that once and for all: GraphQL is switching to HTTP 500.

Why GraphQL returned 200

To understand why this change matters, let’s look at why 200 made sense in the first place. Unlike REST APIs, where an HTTP 404 or 500 immediately tells you something went wrong, GraphQL works differently. A GraphQL response can contain both and at the same time. A single query might fetch five fields successfully and fail on a sixth — and the client still needs the five good fields.

Because partial data is a valid and expected outcome, the HTTP status code alone can’t summarize what happened. The real error information lives inside the response body:

The request itself succeeded — the server understood the query, executed it, and returned what it could. That’s a 200 in HTTP terms. The array tells the client exactly which fields failed and why, while still carries everything that resolved correctly.

This was a reasonable trade-off at the time, but it made traditional monitoring much harder. Your dashboards see a wall of while users may be experiencing real failures. Alerting on HTTP status codes alone won’t catch a broken resolver that’s silently nulling out a critical field. After ten years, the community has spoken loud and clear: this has to change.

The fix: HTTP 500 by default

After years of debate and confusion, the GraphQL Working Group has reached a historic decision: starting with the October 2026 spec release, all GraphQL responses will return HTTP 500.

That’s right. Every single one.

The reasoning is simple. If returning 200 for errors was confusing, the solution is to return an error status code for everything. 500 Internal Server Error is the most honest status code available — after all, something could be wrong, and you won’t know until you check the response body. Which is exactly what you should have been doing all along.

This brings several advantages:

• Observability is solved. Your dashboards will light up like a Christmas tree. You’ll never miss an issue again because every request looks like an issue.
• Job security for SREs. With a 100% error rate, the on-call rotation has never been more exciting. The incident response platform industry is expected to boom.
• No more misleading metrics. Your 99.9% success rate was a lie anyway. Now your 0% success rate is at least consistent.
• Developers will finally read the response body. We’ve tried documentation, conference talks, and blog posts. Nothing worked. Fear works.

The array will remain unchanged, but a new boolean will be added to the response for clients that want to know if the data is actually usable:

We look forward to a new era of GraphQL observability!

PS: If you’ve read this far, congrats and happy first of April!

You can now use the status code of your liking together with the content type.

We also recommend that servers implement tracing with OpenTelemetry (or similar); resolvers that throw errors can be observed via errors recorded on spans.

Join us at GraphQLConf in a few of weeks to learn more!

Seeking SMEs for GraphQL Conf 2026

Blog

announcements

GraphQL FoundationMarch 17, 2026

Due to a variety of factors, the date for GraphQLConf 2026 is changing. Please mark your calendars for 19-20 May, 2026! We will still be at the Meta campus in Fremont, California.

The Governing Board did not make this decision lightly; due to limitations with the original site, it became clear that the space was infeasible for a conference of this scope. After exploring several “Plan B” scenarios with events teams at Meta and The Linux Foundation, we determined that rescheduling was the only workable solution.

There is a silver-lining: Shifting dates slightly will allow us to welcome more members of the community safely and more comfortably. We are very much looking forward to GraphQL 2026.

View the program and register here: graphql.org/conf/2026.

Thank you to our Platinum sponsor, Meta, who is graciously providing the space for this event. We also wish to thank our Gold sponsors, The Guild and Wundergraph; our Silver sponsors, Apollo GraphQL and ChilliCream; and our Bronze sponsor, Grafast. If you are interested in sponsoring GraphQLConf, we have packages beginning at only $1,000 USD. See our prospectus for more information.

Seeking SMEs for GraphQL Conf 2026

announcements

GraphQL FoundationJanuary 29, 2026

GraphQLConf will return to its roots in the Bay Area on May 6-7, 2026 at the Meta office campus in Menlo Park, CA. The Bay Area has always played a special role in the GraphQL story. From the earliest internal experiments to the first open-source release and initial meetups, this region helped define what GraphQL would become. Bringing GraphQLConf back to the area is an opportunity to reflect on how far the ecosystem has grown while looking ahead to what’s next.

More details can be found on the conference website.

We are deeply grateful to Meta for their generosity in making both their facilities and their event support team available to GraphQL users. GraphQLConf is an event run in service of the community, and support like this allows us to focus our resources on what matters most: creating a welcoming, inclusive, and high-quality experience for everyone who builds with GraphQL. We couldn’t do this without partners who believe in the long-term health of the ecosystem.

Accessible to all

This year, conference registration will be essentially free for attendees!

However, it’s well known that free tickets can lead to increased no-shows, which in turn can make planning difficult and prevent others from attending. We’re currently working on a ticketing model that encourages attendance while keeping the event accessible. More details will be shared once the model is finalized; our goal is simple: keep GraphQLConf open to everyone, try to offset some expenditures, and respect the community’s time and the generosity of our hosts.

What to Expect

GraphQL continues to evolve rapidly, and GraphQLConf 2026 will reflect the breadth and depth of the modern ecosystem.

Major themes are expected to include:

• AI and GraphQL
• UI and product development
• Backend architecture
• Security and trust
• Federation, composite schemas, and distributed systems
• Developer experience
• Tooling, performance, and operations
• Getting started with GraphQL
• …and much more

Whether you’re building client applications, designing schemas, operating federated graphs at scale, or exploring how GraphQL fits into an AI-driven future, GraphQLConf is the place to connect and learn. And the vibes are sure to be great if prior conferences are any indication!

This year the conference will be two days instead of three, a change from prior years; we’re hoping to organize more informal get-togethers for the Working Group, TSC, Board and Ambassadors before/after the conference — details to follow.

Call for Proposals Is Open

We want to hear from you.

The Call for Proposals (CFP) is now open, and we encourage submissions from across the community — practitioners, maintainers, newcomers, and long-time contributors alike.

If you’ve learned something the hard way, built something interesting, or have a perspective that could help others, we’d love to see your talk.

GraphQLConf exists because of community and industry support.

The GraphQL Foundation is actively seeking sponsors who want to invest in the GraphQL ecosystem and help make this event accessible to developers around the world.

We have options for every budget level for your team, starting at just $1,000 USD.

 View the prospectus: GraphQLConf 2026 Sponsorship

From Autumn to Spring

We had such a good time at GraphQLConf 2025 that we couldn’t wait twelve whole months to get it started again! We’ve been talking about moving this gathering earlier in the year for a while, and Meta’s availability helped us get it done. So mark your calendar for May 6-7, 2026, and join us in Menlo Park for two days of learning, collaboration, and connection around the future of GraphQL.

More details on registration, speakers, and schedules will be announced soon 

Seeking SMEs for GraphQL Conf 2026

blog

Kewei QuJanuary 22, 2026

Overview

The GraphQL AI Working Group met in January 2026 to continue advancing the foundational building blocks that enable agentic AI systems to safely and reliably construct GraphQL operations. Building on prior discussions around schema navigation and operation generation, this session focused on improving how agents understand schema intent, develop against GraphQL APIs without live backends, and adopt semantic techniques using accessible open source tooling.

The discussion centered on three related topics: Semantic Introspection, the directive for improving agentic development workflows, and an open source GraphQL embedding implementation.

Building Blocks for Agentic GraphQL Operation Construction

A recurring goal of the working group is to reduce hallucination, invalid field selection, and incorrect assumptions when AI agents generate GraphQL operations. The January meeting explored three complementary building blocks that strengthen agent grounding and developer experience.

Semantic Introspection

The group reviewed the Semantic Introspection RFC, which proposes extending standard GraphQL introspection with richer, semantics-aware metadata.

Traditional introspection exposes the structural shape of a schema, such as types, fields, and arguments. Semantic introspection builds on this by surfacing machine-readable signals about intent, meaning, and relationships between schema elements. These semantic hints allow agents to reason more effectively about which parts of a schema are relevant for a given task and how fields and types are expected to be used.

By providing higher-level context directly through introspection, this approach helps agents navigate large or complex schemas more intelligently, improves the accuracy of generated operations, and reduces reliance on heuristic or purely text-based schema exploration.

Directive for Agentic Development

The working group also discussed a proposed GraphQL mocking specification centered around a directive, designed to improve development and testing workflows for both humans and AI agents.

When an operation is annotated with , client tooling intercepts execution and returns predefined mock responses instead of making a network request to a live backend. Mock responses are typically defined in adjacent JSON files and must conform to the expected GraphQL response shape.

This approach enables rapid prototyping, predictable testing, and faster iteration cycles for agentic systems that generate and refine operations. It is particularly valuable when agents need to explore schema behavior, validate operation structure, or develop against APIs that are unavailable, unstable, or still under construction.

By standardizing how mocks are declared and consumed, this proposal lowers friction for agentic development and encourages more consistent tooling support across the GraphQL ecosystem.

Open Source GraphQL Embedding Implementation

Watson presented an open source embedding prototype that generates semantic embeddings at the GraphQL type and field level using an OLLAMA-based setup.

The implementation demonstrated that even with a lightweight open source model and as little as 8 GB of RAM, it is possible to generate embeddings that meaningfully support schema navigation and dynamic GraphQL operation construction. Despite using inexpensive infrastructure, the system was able to help agents identify relevant schema elements and compose valid operations in real time.

This work is particularly empowering for the broader GraphQL community, as it shows that semantic and agentic techniques are not limited to teams with access to state-of-the-art models or large compute budgets. Instead, open source and resource-efficient approaches can still deliver practical and impactful results.

Next Steps

The working group identified several areas of continued focus:

1. Refining the Semantic Introspection RFC and exploring reference implementations.
2. Iterating on the directive specification and evaluating client and tooling integration.
3. Expanding and benchmarking open source embedding approaches to further lower the barrier to entry for agentic GraphQL tooling.

Together, these efforts aim to make GraphQL an increasingly reliable and expressive interface for AI-driven systems, while preserving the strong typing, correctness, and clarity that GraphQL is known for.

Get Involved

Grab a calendar invite at https://calendar.graphql.org
To join, open a PR against the agenda at https://github.com/graphql/ai-wg/tree/main/agendas and add yourself. If you have not already signed the free GraphQL specification membership agreement, the EasyCLA robot will guide you through the process once you open the PR.

Like all GraphQL working groups, this one is open to everyone. Whether you are building AI APIs, researching agentic tooling, or simply curious about the intersection of GraphQL and AI, you are welcome to participate. If you cannot attend live, you can always catch up via the GraphQL Foundation Working Groups YouTube channel.

Seeking SMEs for GraphQL Conf 2026

blog

Kewei QuJanuary 20, 2026

Overview

The GraphQL AI Working Group met in November 2025 to continue its exploration of how large language model agents can safely and reliably interact with GraphQL APIs. Building on the October discussion, the session focused on techniques that help agents write valid GraphQL operations with minimal hallucination and execute those operations on behalf of users to unblock real world data access needs.

The discussion centered on two complementary approaches for guiding agents through large GraphQL schemas, followed by an update on early model benchmarking efforts.

Writing Valid GraphQL Operations with LLM Agents

A primary goal of the working group is to reduce incorrect field selection, invalid queries, and fabricated schema elements when LLMs generate GraphQL operations. Two approaches were discussed in depth.

Approach One: Similarity Search Over the Schema

The first approach uses semantic similarity search to help an agent navigate a GraphQL schema.

The agent begins at the root query and mutation fields of a given schema. From there, it performs a level based traversal, identifying relevant types and fields using similarity search against the user’s intent. The agent then recursively explores related types and fields, gradually constructing a valid GraphQL operation.

This method allows the agent to stay grounded in the actual schema structure while dynamically discovering only the parts of the schema that are relevant to the task at hand. It is particularly useful for large schemas where providing the entire schema to the model is impractical.

Approach Two: Checked In Subschemas

The second approach relies on checked in subschemas that are designed to fit comfortably within an LLM context window.

In this model, the agent is initially provided with an entry point subschema that contains all accessible root fields for queries and mutations, along with commonly used types. Additional schema dependencies are declared using a directive such as , which instructs the agent to load and reference other subschemas as needed.

This approach constrains the agent’s view of the schema while still allowing it to expand its knowledge in a controlled and explicit way. Detailed documentation and design discussion for this mechanism can be found in the working group issue tracker, specifically issue number 54 in the GraphQL AI Working Group repository.

Early Model Benchmarking Results

The working group also shared an update on early benchmarking efforts comparing how different LLMs perform at writing GraphQL operations.

At this stage, the group does not yet have a fully reliable GraphQL AST based grading system, which means results cannot be evaluated with complete certainty. Despite this limitation, early experiments show promising trends.

Initial results indicate that Claude Sonnet 4.5 models are producing the strongest outcomes in terms of correctness and schema adherence, with GPT 5 models following closely behind. These findings are considered preliminary and are intended to guide future, more rigorous evaluation work rather than serve as definitive rankings.

Next Steps

The working group identified several areas of focus for upcoming meetings and collaboration:

1. Developing reference implementations of LLM agents that apply schema similarity search and subschema based navigation.
2. Building a robust GraphQL AST based grading system to improve the accuracy of benchmarking.
3. Publishing shared benchmarks and example schemas to help the broader community evaluate and iterate on GraphQL aware AI agents.

These efforts aim to make GraphQL a reliable and first class interface for AI driven systems while preserving the strong typing and correctness guarantees that GraphQL provides.

Get Involved

Grab a calendar invite at calendar.graphql.org! To join, open a PR against the agenda and add yourself. If you’ve not already signed the free GraphQL specification membership agreement, the EasyCLA robot will guide you how to do so once you’ve opened the PR.

Like all GraphQL working groups, this one is open to everyone. Whether you’re building AI APIs, researching integrations, or just curious about the possibilities, you’re welcome to join. If you can’t make it, you can always catch up via the GraphQL Foundation Working Groups YouTube channel.

Seeking SMEs for GraphQL Conf 2026

blog

Kewei QuNovember 13, 2025

The GraphQL AI Working Group brings together community members who are exploring how GraphQL and AI can work together to shape the next generation of developer tools, APIs, and intelligent systems. We have contributors from many backgrounds, including long-term maintainers of GraphQL projects, technical leaders integrating GraphQL with AI systems, and newcomers eager to learn about open source collaboration. This combination of experience and curiosity made our first meeting both dynamic and inspiring.

GraphQL for Server to Server Communication

The meeting began with a discussion on GraphQL for server to server communication, especially in the context of the Model Context Protocol (MCP). Participants examined how GraphQL, traditionally used for client to server interactions, is increasingly being adopted for backend systems where one service calls another through GraphQL.

A number of important points surfaced. Some participants reflected on how earlier community guidance advised against this pattern, favoring federation for multi-service communication. Others described how in many systems, GraphQL resolvers have historically been thin wrappers around underlying endpoints that handle authentication close to the data source. When GraphQL is used between services, authentication becomes a more complex concern that may require new design patterns, such as identifying caller types or introducing middleware to handle access control and logging.

The group also discussed how GraphQL is not tied to any specific transport protocol, which makes it flexible compared to gRPC or REST. Several participants suggested that this versatility should be highlighted more clearly through educational content. As an action item, the group proposed a blog series on GraphQL for server to server communication to share practical examples and best practices.

The second major topic focused on how large language models author GraphQL operations. This includes both AI-assisted code generation, where models create queries to be committed to a codebase, and dynamic use cases where an LLM calls a GraphQL API through MCP.

Participants shared a wide range of experiences. Several observed that LLMs struggle with schema discovery and query construction, especially when schemas are large or deeply nested. Others noted that error feedback in GraphQL is written for human developers and could be made more structured to help models recover from mistakes automatically.

There was also discussion on schema size and token limits. In production environments, schemas can easily exceed the model context window, leading to experiments with schema reduction and incremental schema loading. Some participants mentioned using semantic search to bridge the gap, allowing models to reason over documentation rather than raw schema definitions.

Another recurring theme was the lack of machine-readable hints in existing schemas. Adding descriptors or annotations could help LLMs better understand relationships between fields and choose the correct path when multiple options exist. The group recognized this as a promising direction for future exploration.

Next Steps and Deliverables

To carry this work forward, the working group outlined several concrete goals:

• A GraphQL writer agent reference implementation that demonstrates how an AI system can construct, validate, and refine operations.

• An MCP reference implementation or specification to illustrate GraphQL as a structured protocol for AI-driven systems.

• A benchmark study comparing how different models perform at generating valid GraphQL operations.

• A public benchmark schema and test suite for the community to experiment with. This will provide a shared playground and a foundation for developing a reference agent proficient in GraphQL.

These discussions mark an exciting beginning for the GraphQL AI Working Group. The intersection of structured data and intelligent systems offers many opportunities for collaboration and innovation.

You can read the full meeting notes and follow future updates on the GraphQL AI Working Group Github page

Get Involved

Our next meeting is on November 27 - grab the calendar invite at calendar.graphql.org! To join, open PR against the agenda and add yourself, then follow the prompts to sign the EasyCLA.

Like all GraphQL working groups, this one is open to everyone. Whether you’re building AI APIs, researching integrations, or just curious about the possibilities, you’re welcome to join. If you can’t make it, you can always catch up via the GraphQL Foundation Working Groups YouTube channel.

GraphQL Locals 2025: Increasing Support

announcementsfoundation

Benjie GillamOctober 16, 2025

Since launching the GraphQL Local Initiative last year, communities around the world have been gathering to share knowledge, collaborate, and strengthen their local GraphQL ecosystems. Over the past year, we’ve seen:

• GraphQL London hosting three or four events a year — with another due in November
• GraphQL Sydney diving into hot topics like GraphQL nullability
• GraphQL Berlin meeting the day after GraphQLConf 2025 concluded in Amsterdam, requiring quick travel for Stephen and Michael!
• GraphQL Hyderabad celebrating a fantastic first meetup
• GraphQL Austin forming over ramen to plan a new series of events
• GraphQL Paris and GraphQL Oslo preparing to meet later this month

We also have local organizers working to bring people together in Białystok, Philadelphia, Chennai, Belgium, and more locations!

We’ve heard you

Feedback from organizers and attendees has been clear, so we’re launching our 2025 refresh of the Locals program:

• Simpler applications: Videos are no longer required — photos can substitute where needed
• More flexible events: Locals can now host more than just talks — discussions, workshops, hackathons, Q&As, live recordings, and more are now eligible for support
• Increased sponsorship: Support per event has doubled, from USD $200 to USD $400, to help with food, drinks, and venue costs
• Clearer TSC oversight: Independent meetups often die when the organizer steps down; by appointing a GraphQL TSC member as an admin, we can help ensure the continuity of the community over the long term

These updates come directly from your feedback. You’re building something amazing, and we want to support you!

Get involved

Find your nearest group in GraphQL Events & Meetups, or get help setting one up via the GraphQL Local Initiative.

Together, we’re building a global network of local communities — sharing ideas, growing connections, and keeping GraphQL vibrant everywhere.

blog

Kewei QuOctober 14, 2025

The GraphQL AI Working Group brings together community members who are exploring how GraphQL and AI can work together to shape the next generation of developer tools, APIs, and intelligent systems. We have contributors from many backgrounds, including long-term maintainers of GraphQL projects, technical leaders integrating GraphQL with AI systems, and newcomers eager to learn about open source collaboration. This combination of experience and curiosity made our first meeting both dynamic and inspiring.

GraphQL for Server to Server Communication

The meeting began with a discussion on GraphQL for server to server communication, especially in the context of the Model Context Protocol (MCP). Participants examined how GraphQL, traditionally used for client to server interactions, is increasingly being adopted for backend systems where one service calls another through GraphQL.

A number of important points surfaced. Some participants reflected on how earlier community guidance advised against this pattern, favoring federation for multi-service communication. Others described how in many systems, GraphQL resolvers have historically been thin wrappers around underlying endpoints that handle authentication close to the data source. When GraphQL is used between services, authentication becomes a more complex concern that may require new design patterns, such as identifying caller types or introducing middleware to handle access control and logging.

The group also discussed how GraphQL is not tied to any specific transport protocol, which makes it flexible compared to gRPC or REST. Several participants suggested that this versatility should be highlighted more clearly through educational content. As an action item, the group proposed a blog series on GraphQL for server to server communication to share practical examples and best practices.

The second major topic focused on how large language models author GraphQL operations. This includes both AI-assisted code generation, where models create queries to be committed to a codebase, and dynamic use cases where an LLM calls a GraphQL API through MCP.

Participants shared a wide range of experiences. Several observed that LLMs struggle with schema discovery and query construction, especially when schemas are large or deeply nested. Others noted that error feedback in GraphQL is written for human developers and could be made more structured to help models recover from mistakes automatically.

There was also discussion on schema size and token limits. In production environments, schemas can easily exceed the model context window, leading to experiments with schema reduction and incremental schema loading. Some participants mentioned using semantic search to bridge the gap, allowing models to reason over documentation rather than raw schema definitions.

Another recurring theme was the lack of machine-readable hints in existing schemas. Adding descriptors or annotations could help LLMs better understand relationships between fields and choose the correct path when multiple options exist. The group recognized this as a promising direction for future exploration.

Next Steps and Deliverables

To carry this work forward, the working group outlined several concrete goals:

• A GraphQL writer agent reference implementation that demonstrates how an AI system can construct, validate, and refine operations.

• An MCP reference implementation or specification to illustrate GraphQL as a structured protocol for AI-driven systems.

• A benchmark study comparing how different models perform at generating valid GraphQL operations.

• A public benchmark schema and test suite for the community to experiment with. This will provide a shared playground and a foundation for developing a reference agent proficient in GraphQL.

These discussions mark an exciting beginning for the GraphQL AI Working Group. The intersection of structured data and intelligent systems offers many opportunities for collaboration and innovation.

You can read the full meeting notes and follow future updates on the GraphQL AI Working Group Github page

Get Involved

Our next meeting is on November 27 - grab the calendar invite at calendar.graphql.org! To join, open PR against the agenda and add yourself, then follow the prompts to sign the EasyCLA.

Like all GraphQL working groups, this one is open to everyone. Whether you’re building AI APIs, researching integrations, or just curious about the possibilities, you’re welcome to join. If you can’t make it, you can always catch up via the GraphQL Foundation Working Groups YouTube channel.

Announcing GraphQL AI Working Group

announcements

Jeff Auriemma and Kewei QuOctober 14, 2025

We’re excited to share the launch of a new AI Working Group to explore how GraphQL can best support the growing needs of generative artificial intelligence and machine learning.

As AI adoption accelerates, developers are using GraphQL to power everything from MCP tools to vector search (Retrieval-Augmented Generation) and embeddings to streaming model responses. The AI Working Group will bring the community together to share use cases and challenges in AI + GraphQL and document common practices for using GraphQL with AI tooling.

We anticipate that the group will propose spec improvements and extensions to benefit both human and AI consumers, and raise opportunities to coordinate across organizations to support interoperability and compatibility.

Our first meeting is coming up on October 23 - grab the calendar invite at calendar.graphql.org! To join, open PR against the agenda and add yourself, then follow the prompts to sign the EasyCLA.

Like all GraphQL working groups, this one is open to everyone. Whether you’re building AI APIs, researching integrations, or just curious about the possibilities, you’re welcome to join. If you can’t make it, you can always catch up via the GraphQL Foundation Working Groups YouTube channel.

 Get involved:

• Follow updates on the GraphQL GitHub
• Subscribe for community calendar invites
• Bring your ideas and feedback to help shape the group’s work

AI is transforming software development, and GraphQL is uniquely suited to make AI systems more accessible and connected. We can’t wait to see what we’ll build together.

September 8, 2025 by Lee Byron

spec

It’s here: the September 2025 edition of the GraphQL specification!

This is the first edition of the specification since October 2021, and it reflects years of steady, collaborative work from the GraphQL community. More than 100 commits, hundreds of comments, and contributions from dozens of community members went into this update — all with the goal of keeping GraphQL stable, expressive, and primed for the next generation of AI-ready API development.

Since its initial release 10 years ago, GraphQL has grown into a critical layer of infrastructure at startups, enterprises, and platforms across industries. The spec has two guiding priorities:

Stability first: With so many tools and services built on GraphQL, the ecosystem relies on a solid foundation. This release fixes inconsistencies, addresses edge cases, and helps avoid performance pitfalls.

Expressiveness for API consumers: Developers use GraphQL because it’s intuitive, flexible, and powerful. This edition makes the language even more productive and expressive, particularly for AI-first applications.

Why It Matters

Several updates in this edition make GraphQL an even better foundation for AI assistants, codegen tools, and autonomous agents:

• Descriptions on executable documents give LLMs richer context for intent understanding and safer refactoring.
• Schema Coordinates provide a precise, both human- and machine-readable way to reference fields and types, improving traceability, evals, and automated PR feedback.
• OneOf input objects simplify schema entrypoints whilst maintaining type safety by expressing mutually exclusive inputs directly in the schema. This is particularly helpful for prompt and form generation.
• The clarified execution/error terminology and request make responses more predictable for deterministic parsers and toolchains.

• OneOf Input Objects (a.k.a. input unions)
  A long-requested feature! This unlocks more natural ways to model mutually exclusive inputs, leading to tidier schemas and unlocking use-cases that couldn’t be safely expressed previously - check out the blog post. RFC #825
  

• Schema Coordinates
  A standardized way to refer to parts of a schema, paving the way for better tooling, error reporting, and developer experience. RFC #794
  

• Descriptions on Documents
  Improved support for documenting queries and operations — helpful for humans and increasingly relevant for AI-powered tools. RFC #1170
  

• Expanded Deprecation Support
  Deprecation is now more broadly supported across schema elements, making it easier to evolve APIs without breaking clients. [RFCs #805, #1040, #1053, #1142]

• Full Unicode Support
  **The language grammar now supports the entire Unicode range, improving internationalization and accessibility. RFC #849
  

• Editorial Improvements
  The spec is clearer, more consistent, and easier to contribute to. Ambiguities have been reduced, and the style guide has been modernized.

Thank you, contributors!

This edition wouldn’t exist without the dedication of the GraphQL community. Dozens of contributors — from core maintainers to first-time spec authors — invested their time and expertise to make GraphQL better for everyone.

Special thanks to the many reviewers, implementers, and champions who shaped this release.

You can explore the full list of contributors in the changelog.

Get involved

GraphQL is a living standard. If you’re building APIs, tooling, or clients, your voice matters in shaping its future. Anyone can join working group meetings and contribute proposals, reviews, or feedback.

📖 Read the full spec: GraphQL September 2025 Specification
🔎 Review all changes: Full changelog & diff
🤝 Contribute: How to get involved

September 8, 2025 by Saihajpreet Singh & Piotr Monwid-Olechnowicz

announcement

After ten years of continuous growth and evolution, we’re excited to announce the complete redesign of GraphQL.org!

What started as a simple query language has transformed into the backbone of modern API development at companies like Meta, Netflix, GitHub, and thousands of others worldwide.

Why Now?

GraphQL has come a long way since its inception. As the ecosystem has matured and adoption has scaled globally, our website needed to evolve too. The previous design served us well as we expanded, but it was time for a refresh that truly reflects where GraphQL stands today and where it’s heading.

What’s New

Our redesigned homepage now clearly communicates not just what GraphQL is, but why it matters for modern development:

Clear Value Propositions: We’ve highlighted GraphQL’s three core benefits: delivering the best user experience, ensuring security and stability, and enabling efficient distributed development.

Proven at Scale: See how leading companies leverage GraphQL in production environments.

Use Case Guidance: Whether you’re building a mobile app, managing microservices, or developing AI-powered applications, discover if GraphQL is right for your project.

Enhanced Resources: From the five pillars of GraphQL to data colocation patterns, we’ve organized our content to help you succeed at every stage of your GraphQL journey.

Community Focus: Stronger connections to our vibrant community resources and contribution opportunities.

Behind the Scenes: Technical Craftsmanship

Beyond the visual refresh, this redesign showcases some interesting technical details that our community might appreciate:

Creative Problem-Solving: That smooth rotation animation you’ll see? It’s not just for aesthetics. It’s actually the only way to animate the element without breaking the highlight effects from the underlying wire graphics. Sometimes constraints lead to the most elegant solutions.

Developer Experience: We discovered it’s faster to iterate on syntax highlighting themes in VSCode than in our Nextra-shiki setup. This led us to accidentally create an entirely new custom syntax highlighting theme as a side effect of the redesign process.

Explore the New Experience

The redesigned GraphQL.org better reflects the maturity and sophistication of both the specification and its ecosystem. We’ve maintained our commitment to clear documentation while adding the context and guidance that today’s developers need.

Visit the new GraphQL.org →

Get Involved

This redesign represents input from our entire community. As always, we welcome your feedback and contributions. Join the conversation in our Community Working Group and help shape the future of GraphQL.

blog

In 2015, when GraphQL was first introduced, it solved a very human problem: helping developers query exactly the data they needed, no more and no less. It introduced a contract between client and server that was typed, introspectable, and composable, quickly reshaping the way we think about APIs.

Nearly a decade later, that same contract is proving essential for a very different kind of client: intelligent systems.

As large language models (LLMs) and agentic software grow more capable, a new challenge has emerged. These systems don’t just need access to raw data; they need structured context they can understand, explore, and act upon. And once again, GraphQL is rising to meet that need.

Intelligent Systems Need Structured Interfaces

LLMs and agentic architectures are powerful, but they’re inherently limited by the quality and structure of the context they receive. Whether summarizing customer data, retrieving internal documentation, or executing multi-step plans, they rely on clear, machine-navigable interfaces to understand their environment.

Traditional APIs like REST or RPC weren’t built for that. They expose data, but not semantics. They support integration, but not discovery.

GraphQL offers a better fit:

• A self-describing schema, so agents can explore what’s possible
• Strong typing, so models can reason about inputs and outputs
• Composability, enabling flexible, targeted access to data and functionality

These aren’t just developer conveniences. They are enablers of intelligent interaction.

MCP ❤️ GraphQL

The Model Context Protocol (MCP) is a new standard for giving LLMs and agents access to structured, machine-readable context. It defines how tools and APIs describe their capabilities in a consistent way, so models can plan, query, and act more intelligently.

GraphQL is a natural fit. With strong typing, clear semantics, and introspectable schemas, GraphQL addresses many of MCP’s core challenges out of the box. By making APIs self-describing and composable, GraphQL transforms static interfaces into dynamic environments that intelligent systems can understand and use effectively.

The Evolution of APIs in the AI Era

This reflects a broader shift from human-centered APIs to machine-navigable protocols. In this transition, GraphQL plays a unique role:

• It provides a shared contract between developers and intelligent systems
• It makes capabilities explicit, enabling dynamic interactions without hardcoding
• It supports tooling, validation, and composability at scale

These strengths, once used to streamline frontend and backend development, are now foundational for AI-native systems that must reason about the world in real time.

From Developer Tools to Intelligent Systems

GraphQL’s original mission was to help developers “describe the data they want, and get exactly that.” Today, the “developers” might be autonomous agents, orchestration layers, or LLMs writing queries on the fly.

We’re entering an era where APIs aren’t just for connecting systems; they’re for teaching models how to interact with them. That means APIs must be introspectable, type-safe, and composable—the very things GraphQL has offered from the beginning.

In the age of AI, structure matters. And GraphQL delivers structure, composability, and introspection like nothing else. If you’re building AI-native apps, it’s time to stop thinking of GraphQL as just a frontend tool—and start seeing it as the API protocol for intelligent systems.

blog

The GraphQL Foundation Governing Board met for its monthly board meeting on May 15 to share updates across community, technical, and operational committee initiatives. Here’s a quick look at what was covered:

🌐 Community & Website Updates

Work continues on the redesign of graphql.org, led by the Community Working Group. The new site will feature refreshed messaging, community-focused sections, and improved support for case studies. Community input is welcome via GitHub and monthly working group meetings. It’s looking great!

📅 GraphQL Conf 2025 Planning

Preparations for GraphQLConf 2025 are fully underway! The Call for Proposals has closed, and submissions are under review with support from 16 subject matter experts from the community and the TSC. Sponsorships are coming in from members like Apollo, Grafbase, and Meta, and attendance targets are on track. Two new local GraphQL meetup groups have launched in India, and discussions about a potential ambassador program are in development.

💸 Budget & Strategy

The Foundation is considering shifting its fiscal planning to align with the conference, which would simplify planning and help center GraphQLConf as a key milestone each year. Grant-funded projects are progressing well, including improvements to GraphiQL and documentation.

🔧 Technical Progress

The Technical Steering Committee (TSC) shared updates on several fronts:

• A release candidate for the new GraphQL over HTTP specification is nearly ready.
• Key proposals like Input Unions and updated deprecation rules have been accepted into the spec.
• Legacy versions of graphql-js have been formally deprecated, with a new versioning policy now in place.
• A new OpenTelemetry Working Group has launched to improve observability support for GraphQL.

📣 Get Involved

The Foundation is looking for help organizing the conference schedule, gathering community case studies, and contributing to ongoing spec work. If you’re interested in supporting the ecosystem, now’s a great time to jump in!

Stay tuned for more updates at graphql.org and follow us for the latest on GraphQLConf 2025.

blog

The GraphQL Foundation offers Community Grants to help incentivize key technical and community initiatives. As part of the grant, applicants commit to write a blog post report describing their work and its impact on the GraphQL community. The following report was written by grant recipient Sarah Sanders in June 2025, summarizing the documentation updates she contributed to the GraphQL.js reference guides during her project.

About the project

The GraphQL.js library is the reference implementation of the GraphQL specification in JavaScript, and it’s widely used both directly and indirectly by many GraphQL tools and servers. While the implementation itself is robust and actively maintained, the supporting documentation had room to grow—especially when it came to helping developers understand how GraphQL.js reflects the spec and how to use its APIs in real projects.

With that in mind, I applied for a GraphQL Foundation Community Grant to work on improving the GraphQL.js documentation. My goal was to make the guides more approachable for newcomers, more accurate for advanced users, and more aligned with the specification for everyone.

What I worked on

This project involved a full audit of the existing GraphQL.js guides, followed by targeted updates to improve clarity, structure, and completeness. I focused on areas that were either under-documented or potentially confusing, and worked to ensure the guides explained not just what GraphQL.js does, but why and how it does it.

Some key improvements include:

• Clearer explanations of schema construction and how types are defined in GraphQL.js
• Improved guidance on how execution and validation flow maps to the spec
• Expanded sections on custom scalars and other advanced patterns
• New guides on testing and production-readiness

All updates are live on the GraphQL.js docs site.

What’s next

I hope these updates help more developers learn and use GraphQL.js effectively, and serve as a foundation for future improvements to the reference documentation. There’s still more we can do and I’d love to see others in the community build on this work.

This project was a rewarding chance to contribute meaningfully to the GraphQL ecosystem, and I’m thankful to the maintainers who reviewed, discussed, and supported the updates throughout the process. If you’re considering a documentation or community contribution, I encourage you to explore the GraphQL Foundation’s Community Grant Program. It’s a great way to go deep, give back, and help others along the way.

Feel free to reach out if you’re thinking about submitting a proposal. I’m happy to share what I learned! You can reach me via GitHub or LinkedIn.

blog

Dear Community,

We’re excited to share a milestone in the GraphQL-JS journey, one that puts our community at the center of everything we do.

For years, GraphQL-JS documentation lived under the broader graphql.org umbrella at . While this made sense back then, we want to serve y’all better, we want upgrade guides and everything graphql-js specific to live in one easy to navigate place.

We’re thrilled to announce that GraphQL-JS has moved to its dedicated home at graphql-js.org.

This isn’t simply a change of address, it’s a commitment to the community that has made GraphQL-JS what it is today. This new home represents the first step in a larger mission: giving you the comprehensive documentation, clear upgrade paths, and responsive support that a project of this scale deserves.

What This Means for You

• Easier discovery: No more hunting through nested documentation structures
• Focused experience: Everything GraphQL-JS related in one dedicated space
• Better navigation: Documentation organized around your workflow, not our internal structure

Coming soon:

• Comprehensive upgrade guides: Clear, step-by-step paths between major versions, GraphQL V17 will be our first attempt at this
• Enhanced reference documentation: Every API documented with real-world examples

We see this move as an inflection point, a moment where we recommit to being the reference implementation the community deserves. GraphQL-JS isn’t just code; it’s the foundation that teams around the world build upon. Whether you’re implementing a new GraphQL server, debugging a complex schema, or upgrading between major versions, you deserve documentation and tooling that makes your job easier, not harder.

This is our promise: we’re not just maintaining GraphQL-JS, we’re investing in its future and yours.

The GraphQL-JS Maintainers

Questions or feedback about the new site? We’d love to hear from you in our GitHub discussions or on the GraphQL community Discord in channel .

blog

The GraphQL Foundation Governing Board met April 17 to discuss ongoing community efforts, technical progress, and upcoming events—read on for the highlights:

🖥️ Website Redesign Underway

The first version of the new GraphQL.org design is live for community feedback on GitHub! Championed by The Guild, the new site focuses on communicating GraphQL’s value to different types of users. Check it out on GitHub and Figma—your feedback is welcome.

🌍 Planning GraphQL All-Hands

We had fabulous input and a great turn out for our first public board meeting, which was held at GraphQLConf 2024. We’re building on that idea with a plan to host twice-a-year GraphQL All-Hands sessions. These gatherings will celebrate progress, share strategic updates, and foster open discussion. The next one will take place at GraphQLConf 2025 this fall!

📊 Community Survey Discussion

Several Board and community members are exploring a user survey to help shape technical priorities, improve documentation, and inform event content. The Board discussed options to help the effort start small and release iteratively—stay tuned!

💸 Budget & Membership

We’re exploring aligning our fiscal planning with GraphQLConf to better match our annual rhythm. We also celebrated progress on new community grants! 🎉

🎤 GraphQLConf 2025

We’re expanding community involvement in the CFP process by becoming a Subject Matter Expert—we’re looking for volunteers to help rank talks for the conference program. Also, we’re proud to support an ALS charity swim team happening before the conference. The CFP closed May 12.

blog

We’re excited to announce that this year, alongside GraphQLConf 2025 in Amsterdam, we’re diving into something a little different. This is your once in a lifetime opportunity to swim in the Amsterdam canals and craft some fin-tastic puns. We’ve created a team to participate in the Amsterdam City Swim, and we’d love for you to join the GraphQL Stream Team on Sunday, September 7th!

Why We’re Swimming

The Amsterdam City Swim isn’t just a unique athletic event—it’s a powerful fundraiser supporting research into ALS (amyotrophic lateral sclerosis), a devastating neurological disease that still has no cure. Every stroke we take helps raise money and awareness, and contributes to the ongoing fight against ALS.

As developers, technologists, and open source enthusiasts, we often work together to solve complex problems. Now, we’re channeling that same energy into something beyond our everyday work—supporting a cause that impacts lives around the world. Our goal is to raise €2,500.

Who Can Join?

Anyone is welcome, even if you aren’t able to attend GraphQLConf! All you need is a swimsuit/wetsuit and goggles. Whether you’re a seasoned swimmer or just in it for the adventure, we want you. There are two different distance options - 750m + 2.25 km.

Not a Fish?

We love a fan club! We’ll arrange a meetup spot for spectators and a post-swim soiree.

Ready to Take the Plunge?

• Sign up for our team: GraphQLConf Stream Team
• Make a donation
• Spread the word: Invite your colleagues, friends, and family
• Pack your swim gear for Amsterdam!

Let’s Make a Splash

GraphQLConf 2025 is already shaping up to be an unforgettable event. Let’s make it even more meaningful by showing what our community can do when we come together for a good cause.

Are you in? We welcome you with open fins!

blog

Note: The GraphQL Foundation Governing Board will be authoring monthly blog post summaries of their meetings. This is the first approved post, with more to come!

GraphQL Foundation’s Governing Board gathered on March 20 for a productive meeting focused on transparency, community growth, and continued technical progress. One key highlight was the board’s support for hosting biannual public “Town Hall”–style meetings, inspired by the first such meeting at GraphQLConf 2024. These events—one of which will be held during GraphQLConf 2025 in September—aim to bring more visibility to the Foundation’s work and encourage community participation and input.

On the technical front, the Technical Steering Committee (TSC) shared updates on nullability, upcoming changes to graphql-js, and ongoing work on the incremental delivery specification. The team also encouraged feedback from Board Members and the community on behalf of GraphQL over HTTP.

The new Community Working Group, under the TSC, reported strong early engagement, including work on a refreshed GraphQL.org landing page and an open, async collaboration model based on GitHub issues.

The Marketing & Content Committee reported that efforts are underway to produce a series of case studies and better support industry-specific adoption stories. The team is also exploring more tailored messaging and additional social media campaigns to promote the conference, Local initiatives, and GraphQL-related news.

Preparations for GraphQLConf 2025 in Amsterdam are well underway. The CFP has seen increased submissions compared to last year, and new voting tools will enable more inclusive talk selection. Ticket sales are tracking to plan, and the Foundation is actively seeking additional sponsors to support the event.

Finally, the Budget Committee presented a draft of a new membership pitch deck designed to better communicate the impact and benefits of joining the GraphQL Foundation. The committee is continuing to refine this deck and will solicit ongoing feedback on the messaging.

Stay tuned for more updates as we continue working together to support the GraphQL ecosystem and community. If your organization is interested in sponsoring GraphQL Conf or contributing a case study, we’d love to hear from you!

blog

By the end of this blog, you’ll know:

• how to write a conference proposal, and
• how to maximise your chance of getting selected to speak

Speaking at a conference is a goal you can achieve now. You don’t have to wait until you’ve “made it” as a principal engineer.

I’m going to share with you what I’ve learned from speaking at the GraphQL Conference and how I maximised my chances of getting selected. I’m going to share the full text of my successful conference proposal so you can see how achievable this is. I will also share advice from Benjie, a GraphQL Conference proposal reviewer and member of the Technical Steering Committee.

By this end of this blog, you will have the skills and confidence to write your own successful conference proposal.

Why you should speak at a conference

Speaking at conferences is a great way to share knowledge and a fantastic opportunity to meet and learn from your peers. The GraphQL Conference is a fantastic way to connect with the community in person.

Although it is not the primary motivation, speaking at a conference helps you stand out as an engineer. It demonstrates that you are an expert on the topic.

You are already enough

Many developers want to speak at a conference, yet I’m sure the next thought most people have is “but I’m not senior or good enough to do that!”

You don’t need to wait until you are a big deal principal engineer to give a conference talk. At any stage of your career, you have valuable information to share. I’m sure you have already achieved something worth sharing in a conference talk.

In this blog I will explain how to take the experiences you already have, and present it as a winning conference proposal. You are already enough!

Selecting conference talk ideas

You will maximise your chance of getting selected if you choose a topic that more engineers are interested in.

Before I became a software engineer, I was a stand-up comedian. When making jokes is your job, you need a systematic way to generate many ideas (jokes) and test them with audiences. You can use the same approach for selecting conference topic ideas.

Generating talk ideas

Comedians have to generate new ideas (jokes) all the time. Demanding jobs such as Saturday Night Live require new scripts every week. It’s part of the job, so quickly generating ideas is the first skill they teach you at comedy school.

Here’s what I learned at The Second City (the comedy school where Tina Fey, Stephen Colbert, and Steve Carell studied). To generate heaps of ideas, get a blank piece of paper (or digital equivalent) and start writing down ideas without judging them or editing them. I suggest setting a short timer to timebox the activity, for example 10 minutes.

The most important point about this exercise is not pre-judging yourself. Humans are not good at multi-threading. If you’re busy judging your ideas, you don’t have enough brain power to be creative. Give yourself the permission to come up with crappy ideas. This is only an exercise and nobody is going to see what you write down.

You can also use prompts to help you think of talk ideas:

• What have I worked on in the last 12 months (or longer)?
• Where have I been spending my time over the past year?
• What are the technologies that I’m interested in?
• What have I been reading about?

After the timer is up and you have your ideas, then you can look through and start selecting your most promising ideas. Remember, only start judging after finishing writing down all the ideas.

Testing talk ideas

It’s useful to think about the conference proposal selection process from the perspective of a conference organiser. I interviewed Benjie, part of the team organising the GraphQL Conference and Technical Steering Committee, for his advice. He told me, the most important thing he looked for was interesting topics and unique perspectives. The most important factor in getting accepted to speak at a conference is having an idea that resonates.

So how do you know if your idea is interesting? An effective way to assess your talk ideas is to test them with colleagues. If your idea resonates with them, you’ve probably found an idea that many developers want to learn about.

Test your conference ideas where it’s appropriate. Perhaps a team demo, brown bags, meetups, writing an internal blog, or simply talking to colleagues. What grabs their attention? Which conversation topics come up again and again?

Narrowing down the list

To maximise your chances of getting selected, you should only submit your most promising talk ideas.

Try and rank your remaining conference talk ideas with these prompts (you’ll see why in the next section):

• Which of these ideas resonated most with colleagues?
• Which of these ideas do I have the most expertise in?
• Which of these ideas am I most proud of, or most excited by?

I usually only have one or two proposals at a time, which I submit to many conferences. You might have more ideas, but try and keep your list short. Be efficient with your time and only submit the ideas you are sure about.

Writing the proposal

Here are my top tips, including suggestions from Benjie.

After explaining these tips, in the next section I’ll share the full text of my GraphQL Conference proposal, so you can see how achievable this is.

Get straight to the point

A conference organiser needs to understand what your proposal is about within the first few seconds of reading your proposal. Get straight to the point about what you are going to share.

Conference organisers don’t have time to call you and ask for clarification, so you must make sure what you write is very clear. Ask colleagues and friends to review your proposal for clarity.

A proposal is like a movie trailer

You’ll see below, a proposal is very short. You’ll usually be given a small word limit.

You only have enough room to explain the main idea of your talk. You don’t have enough room to explain all the points you will present in the talk. This is like a movie trailer. Show just enough excitement to grab a person’s interest, but don’t give the full story away. If they want to know all the details, they’ll have to accept your talk first!

The proposal never contains slides nor speech content. You write slides and the speech after being accepted, so don’t worry about having this ready beforehand.

Explain why you’re the best person to give the talk

Demonstrate your credentials and why you’re the best person to give this talk. Explain why you are knowledgeable about the topic.

Benjie said he was looking for unique perspectives. Demonstrate why you’re uniquely qualified to deliver this talk.

A conference organiser might not know who you are. Explaining your credentials is essential so the organiser trusts you to deliver on your talk proposal.

Emphasis community connections (optional)

If you have participated in the community, write about how you’ve contributed to the community. Similar to the previous point, a conference organiser doesn’t know anything about most applicants. If the organisers have seen or interacted with you already, they will have more trust in you.

I’ve been involved in the GraphQL community as a maintainer of GraphQL Java and contributed to the specification. The conference organisers trusted me to deliver the talk because they could see I was already contributing to the community.

Save your work

Save your proposal, so you can recycle the proposal for other conferences. It also means you’re protected in case a website loses your work.

My GraphQL Conference proposal in full

This was the conference proposal that got accepted for the GraphQL Conference in 2023. See how I used the tips above in the additional notes below.

Title: How to make your first open source contribution (1)

Description: Have you always wanted to make an open source contribution, but not sure where to start? (2)

Getting started with open source is much easier than it seems.

A year ago, I started regularly contributing to GraphQL Java and the GraphQL Scalars project. I caught the open source bug and made it a habit, and now I’m a maintainer of GraphQL Java (3). It has been an incredible learning experience, and it has been very rewarding to meet the engineers using the library all over the world.

But it wasn’t always an open source fairytale! Many years ago I tried to contribute to another project, and it was a total failure. I didn’t have a great experience and it put me off open source for a long time. In this talk, I want to explain what I did differently to succeed this time around (4).

Speaker bio: I am a maintainer of GraphQL Java and software engineer at Atlassian (5). I’ve published a book, GraphQL with Java and Spring, all about the official Spring for GraphQL integration and the GraphQL Java library.

Notice my proposal was very short, but it was also very clear. A tip: when you ask colleagues to review your proposal, don’t ask them “was it clear?” because they’ll probably say “yes” to be polite. If you want more accurate feedback, instead ask them to explain the proposal back to you.

Additional commentary on my proposal

1. Straight to the point in the title: My talk is going to be about how a beginner can make their first open source contribution. I would avoid puns, jokes, and pop culture references in the title because they might not make sense to a reviewer and can detract from your message.
2. Why this talk is interesting: this is a common question many engineers have.
3. Emphasise your credentials to build trust, and emphasise community connections.
4. Why this talk is interesting: I didn’t always succeed. I initially failed miserably, but made changes and then became a maintainer. Note that I don’t actually explain any steps for how to make an open source contribution in this short proposal. I deliberately stopped short of explaining so you’ll only find out if you accept my conference talk! Remember, this is like a movie trailer. Show just enough excitement to grab a person’s interest, but don’t give the story away.
5. Explaining my credentials, why I’m uniquely qualified to give this talk. I also mentioned where I work and the book so it’s easier to verify my credentials.

Dealing with rejection

Rejection sucks, particularly after putting in so much effort to write a proposal. Even great talk proposals can still be rejected. Perhaps the conference organisers were looking for different topics, or there was some other factor you can’t control.

This is why I want to prepare you upfront, you will be applying to many conferences. If you keep trying, you will eventually get accepted. You can reuse most of your talk proposal for other conferences, so your effort is not wasted. You should only spend a few minutes on each subsequent application.

If it helps, I tried to reframe my disappointment of getting rejected. Instead, I tried to make a game out of collecting rejections. My goal was to collect 100 conference rejections, because I knew every submission was improving my chances. Although I was rejected from quite a few conferences, I didn’t achieve my “goal” of 100 rejections.

When a rejection happens, it’s worth remembering your reasons for wanting to speak at a conference, which I wrote about at the top of this page. I promise the payoff is worth the uncomfortable feeling of getting rejected. Don’t give up.

While I encourage you to continue trying, each rejection also gives you the opportunity to assess if there is anything you can do better next time. In my experience, conference organisers are usually too busy to deliver detailed feedback. You could instead ask a colleague or friend for help. Try to ask colleagues who have already spoken at conferences, as they’ve already achieved what you’re aiming for.

Apply for GraphQLConf 2025

In this page we walked through every thing you need to know for writing a successful conference proposal.

You already have what it takes. I encourage you to apply to speak at GraphQLConf 2025! The call for proposals is open, apply now!.

foundation

The GraphQL Technical Steering Committee is the body responsible for the technical oversight of all our open source projects and management of our open source community. Every year we vote on self-nominees to rotate up to half of TSC members, and we’ve just concluded the most recent vote.

Welcoming our new TSC members

I’m excited to share that we have elected two new members to the GraphQL Technical Steering Committee (TSC), Martin Bonnin and Pascal Senn, technical leads at Apollo and ChilliCream respectively. They have been consistent contributors to the GraphQL open source project over the last few years and I’m thrilled to have their help in and commitment to guiding and advancing the GraphQL technical project and broader ecosystem.

In addition, we also re-elected three existing members, Kewei Qu a technical lead at Meta working on the original GraphQL deployment, Rob Richard an engineer at 1stDibs at the lead of the Streaming GraphQL project, and Uri Goldshtein founder of The Guild. These all join our existing TSC members.

Open Working Groups and the Role of the TSC

GraphQL is an open project. All are welcome to join our working group meetings, champion proposals for project-wide improvements, or contribute directly across our open source projects.

It has been critical to keep access to these working groups open, but it does mean a rotating cast of contributors over time. The primary role of the TSC is to provide continuity as the stewards of this group and our processes, and co-owners of our technical projects.

While the TSC is a closed group, our focus is always on strengthening the work that happens in our open Working Group meetings—that is where technical work moves forward.

Our Processes

To learn more about the TSC and how we work, check out these resources:

• 2025 TSC Elections — we use Github issues for most things across the Working Group and TSC, and this one tracked the TSC election itself. Anyone could self-nominate via a Google Form, and we held a vote via OpaVote.
• TSC Charter — this lists out in detail how the TSC is governed, which contains more detail about when and how we take votes, and what we’re accountable for.
• GraphQL Working Group — this is where we organize meetings and contribution across the Working Group, where you’ll find past and upcoming agendas and can join an upcoming meeting simply by adding yourself to the next agenda file in a PR.

I’m beyond lucky to get to work with such a talented group of volunteers both directly on the TSC and across the GraphQL community.

Welcome, Martin and Pascal!

— Lee

announcements

Mark your calendars - GraphQLConf is set to take place in the vibrant and historic city of Amsterdam, Netherlands, on September 8-10, 2025!

After a successful 2024 event, we’re thrilled to announce that GraphQLConf is heading to Europe for the very first time in 2025! This milestone reflects an overwhelming interest and passion from the European developer community, making GraphQL more accessible for developers and innovators worldwide. Get ready to immerse yourself in three days of learning, connecting, and celebrating the GraphQL ecosystem with a truly diverse, international community.

What to Expect

🚀 High-Quality Content

Hear from the pioneers of GraphQL and influential thought leaders shaping the future of APIs and developer experience. From the original creators to cutting-edge contributors, our stage will host the best minds in the industry.

💡 Hands-On Workshops

Level up your GraphQL skills with immersive, hands-on workshops. Whether you’re a beginner or a seasoned pro, we’ll have sessions tailored to help you build faster, query smarter, and optimize better.

🌐 Community Connections

Network with developers, maintainers, and contributors from around the world. The conference will feature meetups, collaboration zones, and plenty of space to share ideas.

🎉 A Memorable Venue

Amsterdam offers a perfect blend of historic charm and modern innovation. From the canals to the cutting-edge tech scene, the city provides an inspiring backdrop for this year’s event.

Why Amsterdam?

As one of Europe’s most tech-forward cities, Amsterdam is an innovative environment with a thriving GraphQL developer community. Its central location makes it easily accessible for attendees from across Europe and beyond. Plus, its rich culture and welcoming vibe ensure you’ll leave with more than just new knowledge—you’ll have memories to last a lifetime.

Save the Date & Get Your Ticket

📅 When? September 8-10, 2025

📍 Where? Pakhuis de Zwijger - Amsterdam, Netherlands

Mark your calendars and secure your spot at the best rates - early bird registration is a great way to spend any remaining 2024 budget!

Get Involved

Want to help shape the GraphQLConf 2025 experience? Here’s how you can participate:

• Speak at the Event: We’re looking for diverse voices to share innovative ideas, technical insights, and real-world GraphQL success stories. Our CFP will open in early 2025.
• Become a Sponsor: Align your brand with the global GraphQL community and connect with influential developers. As a GraphQLConf sponsor, you’ll be an authoritative voice on cutting edge API topics.
• Join the Community Team: Help us make the event unforgettable and highly relevant by volunteering with our programming committee or hosting local meetups leading up to the conference.

Questions about getting involved? Send us a note at graphqlconf@graphql.org.

Follow for Updates

Stay connected for announcements about speakers, schedules, and registration. Follow us on Bluesky, Twitter/X andLinkedIn and join the conversation with #GraphQLConf2025.

We can’t wait to see you in Amsterdam!

grants

The GraphQL Foundation offers Community Grants to help incentivize key technical and community initiatives. As part of the grant, applicants commit to write a blog post report describing their work and its impact on the GraphQL community. The following report was written by successful grant applicant Mandi Wise in November 2024, detailing the documentation updates she submitted during October and November of that year.

The opportunity

The Learn documentation has been a key resource on this site since its launch. And because of their search engine ranking, the tutorial pages are often one of the first stops for someone starting their GraphQL learning journey. They’re also a great resource for those already working on GraphQL projects who want to ensure they implement best practices.

The Learn docs have undergone some maintenance and iteration since their initial publication, but there were some long-outstanding tasks for this section of the site, as well as several open docs-related issues in the repository that had been submitted by community members. I have some experience teaching and writing about GraphQL, so in late August, I decided to submit a proposal to the GraphQL Community Grant program so I could make a focused effort to address a collection of the open issues, as well as fill in some other content gaps that had emerged as the specification has evolved and certain best practices have become well-established in the community.

The grant application was approved by the GraphQL Foundation a few weeks later into September, and I started work on the project by early October, with a goal of completing the work by the end of November.

Doing the work

The scope of my approved project was to review and edit most of the pages in the Learn section of the site, create several new pages, and split some of the existing pages into more focused topics with expanded content. After my proposal was approved, I further refined the scope of this work by completing a more detailed content audit that was reviewed by members of the GraphQL TSC before I proceeded.

Now that the work has been completed, some notable changes include:

• A new and improved landing page for the docs
• Dedicated pages for Queries and Mutations with additional examples, plus a new Subscriptions page
• A new Response page with content about data and error formats
• An overhauled Serving over HTTP page so that it aligns with the draft GraphQL over HTTP specification
• New pages in the Best Practices section covering Performance and Security topics

In addition to these content changes, I also standardized the page formatting with subtitles and summaries, made some additions to the SWAPI schema to support the new examples in the docs, and made a quality of life improvement to the mini GraphiQL component to add labels to each of the panels in the editor.

To complete this work, I submitted PRs to the graphql.github.io repo and I typically sent one PR per docs page to keep the review process manageable. This approach also allowed us to incrementally release updated pages to the site when they were ready. In total, I submitted 12 PRs that addressed 8 open issues in the repository.

Refining and publishing the docs content was a collaborative process, and I’d like to give a big shout-out to Benjie Gillam for the time he committed to reviewing all of my PRs and providing feedback throughout this process. I’d like to thank Uri Goldshtein, Saihajpreet Singh, Eddy Nguyen, and Dimitri POSTOLOV for their feedback during this project too.

What’s next?

The Learn docs have been broadly updated now, but there’s still potential for additional enhancements. Some ideas that were discussed but that ultimately fell outside the scope of this project included new pages on trusted documents, composite schemas, and migrating from REST, as well as developing expanded content for the existing Caching page.

If you’re interested in any of these topics, I’d encourage you to send a PR or even submit a grant proposal too if you’re inspired to take on a larger project. Feel free to reach out to me on Discord (@mandi.wise) or Github and I’d be happy to provide input or help.

blog

We are excited to announce the Call for Participation for the FOSDEM 2025 APIs: GraphQL, OpenAPI, AsyncAPI & Friends Devroom.

What is FOSDEM?

FOSDEM is a two day, free and non-commercial event held in Brussels, Belguim, in February each year. It brings together over 8,000 software developers to meet, share ideas and collaborate on free and open source software. The FOSDEM team feel it is very important that developers get to meet offline and so run Devrooms to facilitate this - rooms with talks, panels and showcases centered around one theme where developers can share ideas and publicly present their latest findings, news and projects in a collaborative atmosphere.

What is the APIs & Friends Devroom?

A platform for developers, technologists, and enthusiasts to come together to discuss, learn, and collaborate on topics around APIs and Open Source. Open collaboration is a driving force behind APIs and open-source projects, and we look forward to talks on community-driven technologies such as OpenAPI, GraphQL, AsyncAPI, gRPC and webhooks.

Suggested Topics

We welcome submissions about, but not limited to:

• Your favourite Open Source project: tooling, frameworks, SDKs, API gateway, etc.
• Topics related to API standards such as OpenAPI, GraphQL, JSON Schema or AsyncAPI.
• API Design Principles: best practices for designing clean, efficient, and developer-friendly APIs.
• Topics related to versioning, authentication, rate limiting, and error handling.
• Real-world API Use Cases.
• Developer Experience and API Documentation.

Important Dates

• Sunday Dec 1st 2024: Submission deadline (Closes at midnight Brussels time)
• Sunday Dec 15th 2024: Announcement of selected talks
• Sunday Feb 2nd 2025: Devroom at 1pm, in person at ULB Solbosch Campus, Brussels, Belguim

Recording

Please be aware of the fact that, barring any technical difficulties, devroom talks at FOSDEM will be recorded. By submitting a proposal you agree to be recorded and to have your talk made available from the FOSDEM video platform.

How to submit a talk

• Talk submissions can be 20 to 25 minutes, allowing a short Q&A time to fill the rest of the 30 minute slot
• Shorter (lightning) talks should be 10-12 minutes and should indicate “lightning talk” in the description
• Go to FOSDEM pretalx website
• Select ‘APIs: GraphQL, OpenAPI, AsyncAPI, and friends’ from the ‘Track’ field

Code of Conduct

The code of conduct for FOSDEM is available at https://fosdem.org/2025/practical/conduct/

Questions

You can reach the devroom organisers at: api-devroom-manager AT fosdem.org The APIs: GraphQL, OpenAPI, AsyncAPI & Friends Devroom is organised by volunteers who also ran the API & Friends devroom last year, and joining forces with members of the GraphQL Technical Steering Committee to bring a GraphQL focus as well as fostering collaboration with folks representing OpenAPI and AsyncAPI projects.

blog

We are thrilled to announce a new co-maintainer of GraphQL.js: Yaacov Rydzinski @Yaacov Rydzinski has been approved as a co-maintainer of GraphQL.js!

Yaacov’s journey into open source and GraphQL is unique, having earned degrees in both Medicine and Computer Science. Whereas most maintainers are employed as software developers, Yaacov is a radiologist by day and star GraphQL contributor by night. Yaacov brings real-world, end-user experience building APIs and tools for the medical field - sounds like a superhero to us!

GraphQL.js is a fundamental library in the GraphQL ecosystem, serving as the reference implementation of the GraphQL specification in JavaScript. It provides the essential building blocks for defining GraphQL schemas, executing queries, and validating data, making it a critical tool for developers building GraphQL APIs. As the backbone of many GraphQL-based applications and services, GraphQL.js plays a pivotal role in driving the adoption and evolution of GraphQL technology across the web development community.

The GraphQL.js maintainers ensure the project’s health by managing contributions, reviewing code, addressing issues, and guiding its evolution. Their role is vital in maintaining the quality, security, and relevance of the software, fostering a collaborative environment, and engaging with the community.

Please join us in welcoming Yaacov to the GraphQL.js team, and join us for an upcoming GraphQL.js Working Group meeting!

blog

A GraphQL endpoint usually returns a JSON payload. While you can use the result as a dynamic object, the GraphQL type system gives us a lot of information about what is inside that JSON payload.

If you’re not using code generation, you’re missing out on a lot, especially if you’re using a type-safe language such as TypeScript, Swift or Kotlin.

By using code generation, you get:

• compile time guarantees about your code and the data it manipulates, and
• autocomplete and inline documentation in your favorite IDE.

All of that without having to write and maintain types manually!

For simplicity, this post uses TypeScript for code blocks but the same concepts can be applied to Swift/Kotlin.

A common mistake is to attempt to use the GraphQL schema directly for type generation, but this is not type-safe since GraphQL only returns the fields that you ask for, and allows you to alias fields in the response. Instead, types should be generated based on the GraphQL operations (requests) that you issue. Here’s an illustration of the issue:

Problem: Generating code from schema types loses nullability information

Let’s assume this schema:

A translation to TypeScript might yield the following:

Pretty neat, right? Typescript and GraphQL look really similar… Unfortunately, this is not type safe!

Let’s perform a query that doesn’t request the product name:

Returned product:

It’s now impossible to map that returned value to our type because must be non-null.

We can also apply aliases:

Returned product:

Note that the , despite being non-null, does not match up with the expected field.

We simply cannot safely use the schema types to represent requests unless we fetch every single field on every single type, which would go against GraphQL’s very nature!

Thankfully, we can solve this by generating code based on operations instead (queries, mutations, and subscriptions).

Solution: Generating code from GraphQL operations

By generating code from GraphQL operations, we are now certain that the TypeScript fields always represent GraphQL fields that have been requested.

Reusing our first example:

TypeScript:

With this type:

• is not present in the generated type because it was not queried.
• is not-nullable, as intended. A product always has an .
• and are nullable, as intended. If , it means the product doesn’t have a description/price.

This is what we expected!

Conclusion

By using code generation based on operations, you get type safety from your backend all the way to your UI. On top of that, your IDE can use the generated code to provide autocomplete and a better experience overall.

All the major code generators (graphql-code-generator, Relay, Apollo iOS, Apollo Kotlin, …) generate code based on operations.

If you have not already, try them out!

And look out for a new post soon on the improvements we’re hoping to bring to GraphQL nullability!

blog

The GraphQL Foundation’s primary mission is to ensure the continued evolution of the GraphQL specification and reference implementations. As part of this mission, we strive to provide collaboration infrastructure that fosters a culture of community and innovation. Local get-togethers play a crucial role in this, bringing together developers, library maintainers, vendors, and enthusiasts to share knowledge and collaborate.

That’s why we’ve expanded our support for local communities with the launch of the GraphQL Local Initiative. This initiative aims to recognize and support local efforts by providing a framework and resources for organizing local GraphQL events.

What the GraphQL Local Initiative Offers

We recognize how much effort is required to organize local events: from finding venues, speakers, sponsors and refreshments to preparing slides, driving awareness, ensuring inclusivity, and much more - there’s a lot to do! The GraphQL Local Initiative enables us to lighten your load a little by offering a modest sponsorship, slide templates, code of conduct, guidelines, swag, promotion, and more.

Requirements for GraphQL Locals

To ensure the success and consistency of these local events, organizers must adhere to the GraphQL Code of Conduct and Brand Guidelines, and ensure events are inclusive and accessible. For the full list of requirements, see the program page.

How to Get Involved

We encourage all community members passionate about GraphQL to get involved. Whether you want to organize an event in your local city or simply participate, your involvement helps strengthen the GraphQL community.

To find out more and apply for official recognition and support for your local event, please visit the GraphQL Local Initiative page.

Let’s keep building a vibrant, supportive, and innovative GraphQL community together!

announcements

We are thrilled to announce that Jovi De Croock @JoviDeCroock has been approved as a co-maintainer of GraphQL.js! Jovi brings a wealth of experience and a deep passion for the GraphQL ecosystem, making him an invaluable addition to the team.

GraphQL.js is a fundamental library in the GraphQL ecosystem, serving as the reference implementation of the GraphQL specification. It provides essential building blocks for defining GraphQL schemas, executing queries, and validating data, making it a critical tool for developers building GraphQL APIs in JavaScript/TypeScript and acting as the backbone of many GraphQL-based applications and services. As the reference implementation, it aids anyone wishing to implement GraphQL in another programming language. These roles make GraphQL.js pivotal in driving the adoption and evolution of GraphQL technology across the web development community.

The GraphQL.js maintainers ensure the project’s health by managing contributions, reviewing code, addressing issues, and guiding its evolution alongside the GraphQL specification. The maintainer role is vital in ensuring the quality, security, and relevance of the software, fostering a collaborative environment, and engaging with the community.

Please join us in welcoming Jovi De Croock to the GraphQL.js team, and join us for an upcoming GraphQL.js Working Group meeting!

announcements

In 2019, Apollo introduced GraphQL Federation as a way of splitting the task of building a GraphQL schema along team boundaries. It proposed a compelling alternative to prior techniques such as schema stitching and delegation, focussing on addressing the collaboration problems inherent in building a coherent schema within a large organization. Federation clearly filled a need and was adopted widely by platform engineers and API developers, a compelling way to compose microservices into a single access layer while retaining service boundaries and team ownership. Solutions from other vendors arose, tackling the same problems in similar ways but with different trade-offs, and some of the world’s largest enterprises have adopted these various patterns and are betting on GraphQL to solve some of their biggest pain points.

Adopting this style of collaboration has become a standard way of creating API platforms, with wide support from an array of vendors. Common patterns and best practices have been established around the various implementations and the underlying architecture has proven effective at scale. Today there are many approaches to collaborative GraphQL schema design, requiring different ways of defining the underlying schemas and composing the resulting architecture; for example Federation and Fusion take an approach that optimizes for collaborative schema composition, whereas Mesh and Hasura prioritize flexibility with a variety of heterogenous services or even databases. API architects are having to make hard decisions early on in their projects, deciding which of the many patterns to follow.

Organizations large and small are making huge investments in GraphQL, and those investments are even more sound when they are underwritten by open standards. That’s why the GraphQL Specification Working Group is proud to announce that the Composite Schemas Subcommittee re-convened earlier this year and is making steady progress toward a common specification describing composition and distributed execution across multiple collaborative GraphQL services. The focus is on standardizing common aspects to enable interoperability whilst leaving significant room for innovation so consumers can find the best solution for their needs. Engineers from a wide variety of organizations including Apollo GraphQL, ChilliCream, Google, Graphile, The Guild, Hasura, and IBM have brought their valuable insights to meetings so far; and the community is abuzz with possibilities!

As with any GraphQL Working Group, anyone is welcome to join and contribute! To get involved, add yourself to an upcoming agenda or watch all former meetings on the official YouTube channel.

announcements

Inviting innovators, decision-makers, and GraphQL aficionados alike! GraphQL Foundation are thrilled to announce the return of GraphQLConf, the much-anticipated official conference for anyone working with GraphQL. After a very successful inaugural conference last year, we are setting the stage for an even bigger event, returning once again to San Francisco — but this time to the heart of this vibrant city! Mark your calendars for September 10-12, 2024, as we invite you to join us at the stunning JW Marriott in San Francisco Union Square for a three-day celebration of learning, innovation, networking, and community.

? What To Expect?

• Production Insights: Gain exclusive insights into how leading companies of all sizes are leveraging GraphQL to drive innovation, streamline operations, and enhance their tech stack’s efficiency.
• Access to Innovators: GraphQLConf offers a rare opportunity to meet the visionaries and maintainers behind GraphQL’s groundbreaking projects. Engage with the minds shaping the future of API technology.
• Interactive Workshops: By popular demand, we’re bringing back a dedicated hands-on workshop day, allowing you to dive deep into practical GraphQL applications and techniques firsthand.
• Diverse Perspectives: If GraphQL is on your radar, this is the place to sharpen your understanding, evaluate its impact, and envision its role in your organization’s future. Whether you’re CTO, architect, system integrator, API developer or frontend engineer, if it’s about GraphQL, we want to hear from you!
• Prime Location: We’re moving from the outskirts to the beating heart of San Francisco! We’ll have the city’s dynamic vibe as our backdrop, with plenty of space for gathering, meeting, and collaborating.

? Navigating API Innovation

For technology leaders navigating the complexities of modern API architectures, GraphQLConf 2024 is more than just a conference. It’s a strategic platform to foresee industry trends, meet the pioneers, and evaluate how GraphQL can fit into and enhance your technology strategy. Whether you’re assessing GraphQL for your next project, looking to optimize existing infrastructures, or keen to foster innovation within your team, GraphQLConf promises a wealth of knowledge and networking opportunities to help steer your decisions in the right direction.

? Call for Proposals (CFP) is OPEN!

Do you have a big idea, a transformative project, or an insightful case study? We want you on our stage! The CFP is officially open, and we’re on the lookout for speakers who can bring fresh perspectives and valuable knowledge to our community. Don’t miss this chance to showcase your expertise and contribute to the collective learning of the GraphQL ecosystem. Submit your proposal now—CFP closes on May 22, 2024, at 11:59 pm PDT.

?️ Snag Your Early Bird Tickets!

Early birds get the worm, or in this case, the best deal on tickets! Early bird registration is open until May 22, offering you the chance to secure your spot at a special rate. Don’t wait too long, though - we anticipate a sold-out event!

? Mark Your Calendars

• CFP Deadline: May 22, 2024, at 11:59 pm PDT
• Early Bird Registration Ends: May 22, 2024
• Schedule Announcement: June 26, 2024
• Event Dates: September 10-12, 2024

? Get Ready to Connect and Collaborate

GraphQLConf 2024 is not just another tech conference; it’s a gathering of diverse and vibrant community members who are passionate about pushing the boundaries of GraphQL and building the future of APIs together. Whether you’re a seasoned GraphQL user, or just looking to understand how GraphQL can help your business, GraphQLConf is a can’t-miss opportunity to be part of this ecosystem.

We can’t wait to see you in San Francisco! Stay tuned for more updates, and don’t forget to check out our conference page here for the latest news and announcements.

March 12, 2024 by Jory Burson

blog

We’re thrilled to announce that Copilot Travel is now a General Member of the GraphQL Foundation. This partnership underscores our shared commitment to driving innovation and collaboration within the GraphQL ecosystem.

With Copilot Travel’s expertise in leveraging cutting-edge technologies to enhance the travel experience, their involvement will undoubtedly enrich our community. Together, we anticipate active participation in working groups, contributions to open-source projects, and collaborative efforts to advance GraphQL adoption across various industries.

At the GraphQL Foundation, we recognize the transformative power of collaboration in shaping the future of technology. With Copilot Travel on board, we’re excited to embark on this journey of exploration and innovation, unlocking new possibilities for GraphQL in the connected travel industry.

Check out our Landscape to learn more about our Member organizations and how other companies leverage GraphQL: https://landscape.graphql.org/

blog

The GraphQL Foundation is thrilled to announce significant updates to our Community Grant Program, now more streamlined and aligned with the foundation’s core projects!

Improved process

We’ve revamped the application process to accept submissions year-round, ensuring your innovative ideas get the attention they deserve promptly. Our focus is sharper than ever, with grants specifically aimed at projects tied closely to the GraphQL Foundation’s efforts, including code and documentation contributions to our repositories on GitHub and enhancements to the graphql.org website.

Rather than our previous twice-annual review process, our new process will perform basic appropriateness checks on a much higher cadence, and will pass suitable applications to the TSC for review. This should result in faster turnaround times, ensuring that your critical work gets the support it needs when it needs it!

Apply now!

Whether it’s completing an important RFC task, polishing a major pull request, educating users with excellent content and documentation, engaging in community advocacy, or improving the user experience on our platforms, we’re looking for your unique contributions. Don’t miss this chance to make an impact on the GraphQL ecosystem.

For a detailed overview of the grant scope, application guidelines, and how your project can contribute to the GraphQL community, we invite you to visit our dedicated program page.

Join us in shaping the future of GraphQL; apply today and make your mark!

blog

blog

We are pleased to announce the results of this year’s GraphQL Technical Steering Committee (TSC) elections. Every year, five of the ten TSC seats are up for election, and this year has seen some changes in the committee lineup.

Outgoing Member: Marc-André Giroux

Firstly, we would like to extend our gratitude to Marc-André Giroux, who chose not to seek re–election this year. Marc-André has been a valuable member of the TSC, contributing significantly to the GraphQL ecosystem. We appreciate his dedication to the GraphQL Foundation!

Continuing Members: Benjie Gillam, Ivan Goncharov, Matt Mohoney, and Michael Staib

We are pleased to announce that the four other TSC members whose seats were up for election — Benjie Gillam, Ivan Goncharov, Matt Mohoney, and Michael Staib — have been re–elected and will continue to serve on the TSC. Their ongoing commitment and expertise will undoubtedly contribute to the continued success of GraphQL.

Welcoming Denis Badurina

Joining the TSC this year is Denis Badurina, who will be filling the seat vacated by Marc-André Giroux. You may know Denis from his work on the project, the reference implementation of GraphQL-over-HTTP and a test suite to help ensure compliance across all the servers in the ecosystem. Denis brings a wealth of experience and a fresh perspective to the committee, and we look forward to working with him to shape the future of GraphQL.

About the GraphQL TSC

Composed of ten elected members and led by Executive Director Lee Byron, the GraphQL Technical Steering Committee is responsible for technical oversight for all of the GraphQL Foundation’s open source projects, both software and specifications. However, we believe in the power of collaboration and recognize that impactful contributions can come from all corners of our community. While the TSC plays a crucial role in overseeing the technical aspects of our projects, we want to emphasize that one doesn’t need to be a TSC member to make a significant impact.

We actively encourage working groups to manage themselves autonomously, fostering a sense of ownership and innovation within each group. The TSC is here to provide support and guidance, and to perform administrative actions that cannot be delegated. We value the diverse talents and expertise within our community, and we believe that every individual has the potential to contribute meaningfully to the success of our projects.

Expressing Gratitude

We would like to express our gratitude to everyone who participated in the election process, especially the candidates who stepped forward — your involvement is vital to the success of the GraphQL ecosystem.

Looking Ahead

As we move forward, the GraphQL TSC remains dedicated to fostering collaboration, inclusivity, and technical excellence within the GraphQL community. We are excited about the future of GraphQL and the continued impact it will have on API development and beyond; if you’re interested in helping us on this mission then get involved in the GraphQL Working Group and maybe even consider nominating yourself for a TSC position in the December election!

Outgoing Member: Marc-André Giroux#

Firstly, we would like to extend our gratitude to Marc-André Giroux, who chose not to seek re–election this year. Marc-André has been a valuable member of the TSC, contributing significantly to the GraphQL ecosystem. We appreciate his dedication to the GraphQL Foundation!

Continuing Members: Benjie Gillam, Ivan Goncharov, Matt Mohoney, and Michael Staib#

We are pleased to announce that the four other TSC members whose seats were up for election — Benjie Gillam, Ivan Goncharov, Matt Mohoney, and Michael Staib — have been re–elected and will continue to serve on the TSC. Their ongoing commitment and expertise will undoubtedly contribute to the continued success of GraphQL.

Welcoming Denis Badurina#

Joining the TSC this year is Denis Badurina, who will be filling the seat vacated by Marc-André Giroux. You may know Denis from his work on the graphql-http project, the reference implementation of GraphQL-over-HTTP and a test suite to help ensure compliance across all the servers in the ecosystem. Denis brings a wealth of experience and a fresh perspective to the committee, and we look forward to working with him to shape the future of GraphQL.

About the GraphQL TSC#

Composed of ten elected members and led by Executive Director Lee Byron, the GraphQL Technical Steering Committee is responsible for technical oversight for all of the GraphQL Foundation's open source projects, both software and specifications. However, we believe in the power of collaboration and recognize that impactful contributions can come from all corners of our community. While the TSC plays a crucial role in overseeing the technical aspects of our projects, we want to emphasize that one doesn't need to be a TSC member to make a significant impact.

We actively encourage working groups to manage themselves autonomously, fostering a sense of ownership and innovation within each group. The TSC is here to provide support and guidance, and to perform administrative actions that cannot be delegated. We value the diverse talents and expertise within our community, and we believe that every individual has the potential to contribute meaningfully to the success of our projects.

Expressing Gratitude#

We would like to express our gratitude to everyone who participated in the election process, especially the candidates who stepped forward — your involvement is vital to the success of the GraphQL ecosystem.

Looking Ahead#

As we move forward, the GraphQL TSC remains dedicated to fostering collaboration, inclusivity, and technical excellence within the GraphQL community. We are excited about the future of GraphQL and the continued impact it will have on API development and beyond; if you're interested in helping us on this mission then get involved in the GraphQL Working Group and maybe even consider nominating yourself for a TSC position in the December election!

blog

We are thrilled to announce the recipients of grants from the GraphQL Foundation, which were selected from an application process initiated in late 2022. Awardees were selected after an extensive review and vote of the GraphQL TSC. These grant awards recognize and support important projects that advance GraphQL technologies, particularly in the realms of GraphQL over HTTP and the GraphQL Language Service Server.

Bolstering GraphQL over HTTP — Denis Badurina

The first grant has been awarded to a project focussed on increasing interoperability between the various implementations of GraphQL clients and servers using HTTP as the transport layer. The GraphQL–over–HTTP subcommittee was formed with the goal of writing a specification to increase interoperability between clients and servers that expose GraphQL schemas via HTTP endpoints. At a recent GraphQL Working Group, the GraphQL–over–HTTP spec was advanced to Stage 2 (Draft) status. This achievement was thanks in a large part to Denis Badurina’s development and maintenance of the reference implementation of the GraphQL–over–HTTP specification: graphql-http and the associated testing tool. This tool can be used to test if any GraphQL API is compliant with the GraphQL–over–HTTP specification, no matter what language it is written in. Denis has worked tirelessly with maintainers of various servers to ensure that the tool, the server, and the specification are aligned.

This grant will enable Denis to continue to invest into maintenance and development of this important project for GraphQL interoperability and collaboration. When informed he was to be a grant awardee, Denis said: “this is awesome news! I’ll start by saying thank you. I am very humbled, excited and happy that my work has a worthwhile impact on the GraphQL ecosystem. Thank you for choosing me, I will continue doing my best.”

Future–proofing the GraphQL Language Service Server — Rikki Schulte

The second grant recognizes a project that is vital for consumers of GraphQL. One of the most popular tools in the GraphQL toolbox is GraphiQL — our in–browser IDE that enables exploring and querying a GraphQL API. It’s often the first experience that potential users have with GraphQL, and very quickly helps them to “grok” some core concepts such as the built in documentation, type safety, and only receiving what you ask for. Underlying this beautifully simple interface is a powerful and complex combination of tools and libraries which also power other projects such as alternative GraphQL IDEs and code editor integrations. Key to this is the GraphQL Language Server and associated libraries.

Rikki Schulte, one of the long term maintainers of GraphiQL and the associated projects, is the recipient of this second grant. The grant will support her to improve the stability and maintainability of the GraphQL Language Server by providing a more comprehensive end–to–end test suite which should enable an overhaul of its aging architecture. Building on the Language Server’s existing schema–aware auto–complete, jump to definition, and real–time error feedback; the ultimate goal of the Language Server project is to give all GraphQL programmers access to advanced features such as support for more languages and sophisticated refactoring tools whilst keeping astride of advances to the GraphQL specification itself.

What makes this project particularly exciting is its commitment to making GraphQL development more accessible and efficient. By providing tools that integrate seamlessly into existing development environments, Rikki hopes to lower the barrier to entry for new GraphQL developers and increase productivity for seasoned professionals. Rikki commented:

“I’m thrilled to receive this grant, as it will help me to focus on improving the stability and maintainability of the LSP server and vscode reference implementation, so that we can refactor for improved performance and contributor experience, and to introduce new exciting features with greater confidence. I owe it all to the GraphQL community!”

A Commitment to Ecosystem and Community Growth

Both projects embody the GraphQL Foundation’s commitment to open source and community–driven development. By supporting these initiatives, the foundation is not only investing in individual technologies but also in the broader GraphQL community. These grants will facilitate collaboration, knowledge sharing and innovation, fostering a vibrant ecosystem around GraphQL.

In recognition of the work required to tend to such an ecosystem, the GraphQL Foundation together with the TSC has also funded Benjie Gillam to support the crucial “gardening” work that helps keep the GraphQL community moving forward, together. Benjie will continue to serve as our Community Manager in 2024 on contract with the Foundation, commenting:

“It has been a joy and a privilege helping to cultivate the vibrant ecosystem of the GraphQL community, and this support from the GraphQL Foundation will help me to continue this work: welcoming new members, fostering collaboration across the Foundation’s own projects and beyond, and helping the wheels of progress to keep turning smoothly. Thank you GraphQL community!”

Looking Forward

As we celebrate the recipients of this year’s grants, we also look forward to the impact their work will have on the GraphQL community and the tech industry at large. Their projects are not just about advancing individual technologies; they are about shaping the future of how we build and interact with GraphQL APIs.

The GraphQL Foundation is proud to support these talented individuals and teams, and we are excited to see their projects come to fruition. We believe their work will be instrumental in driving the next wave of innovation in GraphQL technology.

Stay tuned for updates on these projects and their contributions to the GraphQL ecosystem. We are just at the beginning of a new chapter in GraphQL’s story, and the best is yet to come!

Bolstering GraphQL over HTTP — Denis Badurina

The first grant has been awarded to a project focussed on increasing interoperability between the various implementations of GraphQL clients and servers using HTTP as the transport layer. The GraphQL–over–HTTP subcommittee was formed with the goal of writing a specification to increase interoperability between clients and servers that expose GraphQL schemas via HTTP endpoints. At a recent GraphQL Working Group, the GraphQL–over–HTTP spec was advanced to Stage 2 (Draft) status. This achievement was thanks in a large part to Denis Badurina's development and maintenance of the reference implementation of the GraphQL–over–HTTP specification: graphql-http and the associated testing tool. This tool can be used to test if any GraphQL API is compliant with the GraphQL–over–HTTP specification, no matter what language it is written in. Denis has worked tirelessly with maintainers of various servers to ensure that the tool, the server, and the specification are aligned.

This grant will enable Denis to continue to invest into maintenance and development of this important project for GraphQL interoperability and collaboration. When informed he was to be a grant awardee, Denis said: "this is awesome news! I'll start by saying thank you. I am very humbled, excited and happy that my work has a worthwhile impact on the GraphQL ecosystem. Thank you for choosing me, I will continue doing my best."

Future–proofing the GraphQL Language Service Server — Rikki Schulte

The second grant recognizes a project that is vital for consumers of GraphQL. One of the most popular tools in the GraphQL toolbox is GraphiQL — our in–browser IDE that enables exploring and querying a GraphQL API. It's often the first experience that potential users have with GraphQL, and very quickly helps them to "grok" some core concepts such as the built in documentation, type safety, and only receiving what you ask for. Underlying this beautifully simple interface is a powerful and complex combination of tools and libraries which also power other projects such as alternative GraphQL IDEs and code editor integrations. Key to this is the GraphQL Language Server and associated libraries.

Rikki Schulte, one of the long term maintainers of GraphiQL and the associated projects, is the recipient of this second grant. The grant will support her to improve the stability and maintainability of the GraphQL Language Server by providing a more comprehensive end–to–end test suite which should enable an overhaul of its aging architecture. Building on the Language Server's existing schema–aware auto–complete, jump to definition, and real–time error feedback; the ultimate goal of the Language Server project is to give all GraphQL programmers access to advanced features such as support for more languages and sophisticated refactoring tools whilst keeping astride of advances to the GraphQL specification itself.

What makes this project particularly exciting is its commitment to making GraphQL development more accessible and efficient. By providing tools that integrate seamlessly into existing development environments, Rikki hopes to lower the barrier to entry for new GraphQL developers and increase productivity for seasoned professionals. Rikki commented:

"I'm thrilled to receive this grant, as it will help me to focus on improving the stability and maintainability of the LSP server and vscode reference implementation, so that we can refactor for improved performance and contributor experience, and to introduce new exciting features with greater confidence. I owe it all to the GraphQL community!"

A Commitment to Ecosystem and Community Growth

Both projects embody the GraphQL Foundation's commitment to open source and community–driven development. By supporting these initiatives, the foundation is not only investing in individual technologies but also in the broader GraphQL community. These grants will facilitate collaboration, knowledge sharing and innovation, fostering a vibrant ecosystem around GraphQL.

In recognition of the work required to tend to such an ecosystem, the GraphQL Foundation together with the TSC has also funded Benjie Gillam to support the crucial “gardening” work that helps keep the GraphQL community moving forward, together. Benjie will continue to serve as our Community Manager in 2024 on contract with the Foundation, commenting:

"It has been a joy and a privilege helping to cultivate the vibrant ecosystem of the GraphQL community, and this support from the GraphQL Foundation will help me to continue this work: welcoming new members, fostering collaboration across the Foundation's own projects and beyond, and helping the wheels of progress to keep turning smoothly. Thank you GraphQL community!"

Looking Forward

As we celebrate the recipients of this year's grants, we also look forward to the impact their work will have on the GraphQL community and the tech industry at large. Their projects are not just about advancing individual technologies; they are about shaping the future of how we build and interact with GraphQL APIs.

The GraphQL Foundation is proud to support these talented individuals and teams, and we are excited to see their projects come to fruition. We believe their work will be instrumental in driving the next wave of innovation in GraphQL technology.

Stay tuned for updates on these projects and their contributions to the GraphQL ecosystem. We are just at the beginning of a new chapter in GraphQL's story, and the best is yet to come!

blog

The inaugural event for the GraphQL Foundation, GraphQLConf, delivers the best GraphQL content available.

SAN FRANCISCO, August 24, 2023 – The GraphQL Foundation, dedicated to promoting widespread adoption and accelerating development of the surrounding ecosystem, today announced the schedule for GraphQLConf 2023. The conference will be held in the San Francisco Bay area, CA, September 19-21, 2023.

GraphQLConf brings together the creators of some of the most important technologies behind GraphQL. Speakers from a wide range of organizations working with GraphQL at enterprise scale will share their experience, insights and knowledge as they discuss the challenges facing the growing GraphQL ecosystem. The program was developed by a community-led committee, which selected over 60 sessions after an open CFP that produced a large and diverse set of submissions that span topics from technical challenges and deep dives to end-user stories and introductory content.

“This event is a truly special moment for the GraphQL community,” said Lee Byron, Co-creator of GraphQL and Executive Director of the GraphQL Foundation. “GraphQLConf is the only vendor-agnostic, community-focused conference for developers. We’re thrilled to bring everyone together and celebrate big milestones for our projects and the spec.”

The GraphQLConf community-curated schedule will feature talks from leaders in the industry, and will focus on the most important and relevant topics facing the ecosystem, such as new specifications and features, GraphQL Gateways, GraphQL Security, interoperability between GraphQL and other API protocols, Generative AI and GraphQL performance, caching and no-code tools.

Keynote sessions from developer-entrepreneurs Idit Levine, Marc-Andre Giroux, Tanmai Gopal, and Theo Browne will be featured, along with workshops and breakout sessions on using GraphQL across tech stacks, languages, and deployment technologies. There will also be community-driven unconference sessions held on Sept. 19.

Registration

GraphQLConf will be held at the Hyatt Regency SFO September 19-21 and registration is open at https://graphql.org/conf. Attendees are encouraged to register for in-person attendance by September 4 before prices increase.

Thank You to Our Sponsors

GraphQLConf is made possible with support from our Diamond Sponsors: Hasura, Postman, and The Guild, Platinum Sponsors: Hygraph and Solo.io, and Gold Sponsors: StepZen, Inigo, and The Graph.

About the GraphQL Foundation

The GraphQL Foundation is a neutral foundation founded by global technology and application development companies. The GraphQL Foundation encourages contributions, stewardship, and a shared investment from a broad group in vendor-neutral events, documentation, tools, and support for GraphQL.

GraphQL was created in 2012 and open sourced by Facebook in 2015. In 2019, Facebook and others created the GraphQL Foundation as a neutral, non-profit home for the GraphQL assets and ongoing collaboration, and hosted by The Linux Foundation. The GraphQL Foundation is a fully neutral home for the GraphQL trademark, and provides a means of collecting and distributing membership dues to support core community infrastructure and programs. For more information about the GraphQL Foundation, please visit https://graphql.org.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page. Linux is a registered trademark of Linus Torvalds.

Media Contact

Jory Burson

Linux Foundation

jburson@linuxfoundation.org

SAN FRANCISCO, August 24, 2023 – The GraphQL Foundation, dedicated to promoting widespread adoption and accelerating development of the surrounding ecosystem, today announced the schedule for GraphQLConf 2023. The conference will be held in the San Francisco Bay area, CA, September 19-21, 2023.

GraphQLConf brings together the creators of some of the most important technologies behind GraphQL. Speakers from a wide range of organizations working with GraphQL at enterprise scale will share their experience, insights and knowledge as they discuss the challenges facing the growing GraphQL ecosystem. The program was developed by a community-led committee, which selected over 60 sessions after an open CFP that produced a large and diverse set of submissions that span topics from technical challenges and deep dives to end-user stories and introductory content.

“This event is a truly special moment for the GraphQL community,” said Lee Byron, Co-creator of GraphQL and Executive Director of the GraphQL Foundation. “GraphQLConf is the only vendor-agnostic, community-focused conference for developers. We’re thrilled to bring everyone together and celebrate big milestones for our projects and the spec.”

The GraphQLConf community-curated schedule will feature talks from leaders in the industry, and will focus on the most important and relevant topics facing the ecosystem, such as new specifications and features, GraphQL Gateways, GraphQL Security, interoperability between GraphQL and other API protocols, Generative AI and GraphQL performance, caching and no-code tools.

Keynote sessions from developer-entrepreneurs Idit Levine, Marc-Andre Giroux, Tanmai Gopal, and Theo Browne will be featured, along with workshops and breakout sessions on using GraphQL across tech stacks, languages, and deployment technologies. There will also be community-driven unconference sessions held on Sept. 19.

Registration#

GraphQLConf will be held at the Hyatt Regency SFO September 19-21 and registration is open at https://graphql.org/conf/. Attendees are encouraged to register for in-person attendance by September 4 before prices increase.

Thank You to Our Sponsors#

GraphQLConf is made possible with support from our Diamond Sponsors: Hasura, Postman, and The Guild, Platinum Sponsors: Hygraph and Solo.io, and Gold Sponsors: StepZen, Inigo, and The Graph.

About the GraphQL Foundation#

The GraphQL Foundation is a neutral foundation founded by global technology and application development companies. The GraphQL Foundation encourages contributions, stewardship, and a shared investment from a broad group in vendor-neutral events, documentation, tools, and support for GraphQL.

GraphQL was created in 2012 and open sourced by Facebook in 2015. In 2019, Facebook and others created the GraphQL Foundation as a neutral, non-profit home for the GraphQL assets and ongoing collaboration, and hosted by The Linux Foundation. The GraphQL Foundation is a fully neutral home for the GraphQL trademark, and provides a means of collecting and distributing membership dues to support core community infrastructure and programs. For more information about the GraphQL Foundation, please visit https://graphql.org/.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page. Linux is a registered trademark of Linus Torvalds.

Media Contact

Jory Burson

Linux Foundation

jburson@linuxfoundation.org

blog

As the adage goes, unity is strength. The premier GraphQL EU “unconference”, held in Berlin, is a testament to this belief. This phenomenal event was the result of immense collaboration between various companies and providers within our vibrant ecosystem. The partnership among these key players, backed by the tireless efforts of the GraphQL Foundation, truly highlighted the strength of our community and the unity we foster.

Such dedication from all corners reinforces our commitment to growing and strengthening the global GraphQL community. We understand that a robust community is not built on grand events alone, but through localized meetups and smaller gatherings that allow enthusiasts and experts to exchange knowledge and ideas on a more intimate level.

To that end, we encourage and are excited to support local contributors eager to organize GraphQL meetups. A shining example of a successful local event was the recent gathering in Amsterdam, which saw a vibrant mix of participants sharing their GraphQL journeys, learning from each other, and expanding their networks. Now, with the backing of the GraphQL Foundation, anyone with the zeal and passion to bring the GraphQL community together at a local level can do so with our full support.

GraphQL EU

The “unconference” format encourages an open dialogue; it provides a platform for all participants to express their ideas, facilitating enriching discussions about their daily experiences with GraphQL, both the victories and the challenges.

After everyone had gathered and invigorated themselves with coffee and croissants (it was a tad too early for currywurst), we proceeded to convene in the main hall.

The Day

The day kicked off with brief presentations from all sponsors - Mirumee Software, The Guild Software, Stellate, Saleor Commerce, Hasura, Escape. Far from being standard sponsor speeches, each speaker conveyed an inspiring experience that would later spark a day brimming with engaging discussions.

After the sponsor presentations concluded, Van Riper did an outstanding job outlining the subsequent plan of action, ensuring we kept to the allocated timetable!

Each participant was given a card to jot down their discussion topic, followed by a 20-second slot on stage to present it. Once we deciphered the correct usage of sticky tape, these cards were affixed to the whiteboards. This interactive activity essentially laid down the structure for the remainder of the day’s events.

Round 1

The moment had come to choose a topic and dive right in! We were allocated approximately an hour to join a section of the hall for in-depth topic discussions.

Given the multitude of subjects presented on various whiteboards, selecting just one posed quite a challenge.

I chose to participate in the conversation at location R1/D, which encompassed three related topics:

1. Enhancing the GraphQL Developer Experience
2. Simplifying GraphQL Servers (with a gateway)
3. Identifying missing elements in GraphQL Developer Tooling

Even though the discussion adhered to the set time limit, it undoubtedly contained a wealth of material.

The primary conclusion drawn from this conversation was the pressing need for additional standards, or even better, detailed specifications for GraphQL implementation on both the server and client side. Developers frequently find themselves reapplying identical logic across different languages due to a lack of standardization. This often results in using one language as a foundation for the next.

However, if there’s a deviation from the original, it could negatively impact the developer experience, especially for those working with numerous languages across different stacks.

Creating a specification doesn’t have to be a complex process, nor does it need the sanction of anyone to be beneficial. Several years ago, Jayden Seric introduced the GraphQL multipart request specification. Anyone who is implementing multipart uploads will appreciate the guidance and insights offered by such a singular specification, allowing developers to concentrate on the tasks of building and delivering their applications.

During the first round’s intermission, I had the chance to observe Uri Goldshtein guiding the Beyond GraphQL group. This intriguing dialogue explored how GraphQL’s concepts could be integrated with other tools and standards, including OpenAPI and gRPC. The group also pondered over the existing divide and potential ways to bridge these specifications, aiming for a more unified landscape where the right tool can be chosen for the job.

The discussion, under Uri’s skillful moderation, took an exciting turn as they probed the potential for repurposing existing APIs using GraphQL by means of automation. Numerous organizations and tools like GraphQL Mesh, Grafbase, SOFA, Hasura, and Wundergraph are already navigating these waters. They invite and appreciate the participation of anyone interested in contributing to this evolving domain through open-source projects.

In his concluding remarks, Uri underscored, “The moment has arrived for the discourse within the GraphQL ecosystem to evolve beyond the ‘GraphQL vs. REST’ debate. Instead, we should focus on how we can apply GraphQL’s robust features to enrich other existing APIs.”

Round 2

Choosing the next discussion to attend proved to be quite a difficult task that saw me staring at a board of topic cards longer than I would like to admit. I was torn between the following topics:

• Relay
• Federation in Practice / Combining and Extending GraphQL APIs

Given my day-to-day role involves guiding and assisting developers to excel in extending GraphQL APIs with Grafbase, I felt a strong inclination towards this topic. However, my intuition, coupled with the palpable growing support for Relay, guided my decision in the end.

Hearing from Denis Badurina, Marion Schleifer, Stephan Schneider, and others about their experiences with Relay was enlightening.

I openly admitted to the group that it had been several years since my last encounter with Relay (which, admittedly, was not entirely successful), but I was eager to understand the current usage patterns and share some of the narratives I’ve come across in my GraphQL journey regarding why developers often don’t select Relay as their first choice.

As the session neared its end, it became evident that there were some common reasons why Relay wasn’t the first choice for developers:

• A perceived steep learning curve, mainly resulting from the mental model shift surrounding components and data dependencies.
• Setting up the compiler configuration was frequently a tedious task.

Interestingly, those developers who do use Relay are indeed very fond of it!

Round 3

As the day was nearing its conclusion, it was time to choose a topic that would potentially ignite conversations even during the evening reception drinks. And I must say, I certainly opted for such a topic!

The subject at R3/C centred around the role of GraphQL in the era of TRPC and RSC. I commend Bogdan for his audacity to bring up such a contentious topic. But then again, we were at a GraphQL event, so the reactions wouldn’t have been as fiery as they would have been if this topic had emerged on a tweet.

All participants were given the opportunity to express their opinions and explain why the topic stirred up so much controversy. Uri Goldshtein introduced some impressive open source projects within the community, particularly Garph/GQty, which aim to close the gap and simplify the process of generating types for end-to-end type safety.

The omnipresence of React is no secret. Its adoption is surging across the board, a trend further amplified by the significant influence that Next.js has exerted within the ecosystem.

State of JavaScript 2022: Front-end Frameworks

It’s also well-known that the rise of Next.js and RSC is stirring up numerous concerns and questions, and encountering some challenges, as it propels the community forward with their runtime implementation of React Server Components. I believe GraphQL is also at a crossroads, trying to determine its ideal niche within this evolving React ecosystem.

However, it’s crucial to remember that while React and Next.js are prevalent choices, there are many other languages and frameworks that can leverage GraphQL. As a community, we sometimes overlook these alternatives.

If you haven’t yet used Houdini GraphQL and Svelte, you’re in for a treat. Houdini offers a refreshing approach to constructing type-safe web applications powered by GraphQL.

Overall, it seemed that GraphQL was continuing to expand, but its applications were shifting. Developers who are building web and mobile applications seem to be moving towards simpler routing mechanisms, like Tanstack and React Router, coupled with Relay for client-side data loading and caching.

Key Insights from GraphQL EU

While I couldn’t be part of every conversation, a myriad of topics were undoubtedly discussed during the reception after-party, and even the after-after-party.

Below are the main insights I jotted down in my Notes App throughout the day:

• Despite its initial complexity and paradigm shift, Relay is increasingly adopted by those with more GraphQL experience, especially due to its ability to co-locate fragments with their respective components.
• While tRPC is attractive, not all companies have total control over their tech stacks and rely on external GraphQL APIs. Consequently, more developers are utilizing gateway or federation methods to integrate these APIs.
• Ensuring GraphQL APIs are versionless is vital for mobile applications to function smoothly, given users frequently lag in updating their apps.
• For SPAs or mobile apps, where client fetching is preferable, GraphQL still offers a superior experience. React Server Components (RSC), particularly with Next.js, doesn’t provide much scope for GraphQL, and that’s acceptable.
• For server-rendered applications, GraphQL remains a viable choice. As a simple function or network call, it can facilitate integration with multiple APIs more efficiently than having to install numerous SDKs.

What’s next for GraphQL?

As significant as this event was, we are set to surpass it with the official GraphQL Conf, scheduled for September 19-21 in San Francisco. If you thought this event was insightful, I guarantee you that the upcoming conference is going to be a game-changer!

You wouldn’t want to miss out, so grab your tickets soon! I look forward to seeing many familiar faces and meeting new ones at the conference.

• Buy a Ticket!
• See the schedule
• Become a sponsor

Get involved

Though the aforementioned reflections encapsulate my journey, I encourage you to contribute your unique experiences to our collective narrative. Connect with us on Discord and enrich the GraphQL community with your insights.

See you in San Francisco!

Such dedication from all corners reinforces our commitment to growing and strengthening the global GraphQL community. We understand that a robust community is not built on grand events alone, but through localized meetups and smaller gatherings that allow enthusiasts and experts to exchange knowledge and ideas on a more intimate level.

To that end, we encourage and are excited to support local contributors eager to organize GraphQL meetups. A shining example of a successful local event was the recent gathering in Amsterdam, which saw a vibrant mix of participants sharing their GraphQL journeys, learning from each other, and expanding their networks. Now, with the backing of the GraphQL Foundation, anyone with the zeal and passion to bring the GraphQL community together at a local level can do so with our full support.

GraphQL EU#

The "unconference" format encourages an open dialogue; it provides a platform for all participants to express their ideas, facilitating enriching discussions about their daily experiences with GraphQL, both the victories and the challenges.

After everyone had gathered and invigorated themselves with coffee and croissants (it was a tad too early for currywurst), we proceeded to convene in the main hall.

The Day#

The day kicked off with brief presentations from all sponsors - Mirumee Software, The Guild Software, Stellate, Saleor Commerce, Hasura, Escape. Far from being standard sponsor speeches, each speaker conveyed an inspiring experience that would later spark a day brimming with engaging discussions.

After the sponsor presentations concluded, Van Riper did an outstanding job outlining the subsequent plan of action, ensuring we kept to the allocated timetable!

Each participant was given a card to jot down their discussion topic, followed by a 20-second slot on stage to present it. Once we deciphered the correct usage of sticky tape, these cards were affixed to the whiteboards. This interactive activity essentially laid down the structure for the remainder of the day's events.

Round 1#

The moment had come to choose a topic and dive right in! We were allocated approximately an hour to join a section of the hall for in-depth topic discussions.

Given the multitude of subjects presented on various whiteboards, selecting just one posed quite a challenge.

I chose to participate in the conversation at location R1/D, which encompassed three related topics:

1. Enhancing the GraphQL Developer Experience
2. Simplifying GraphQL Servers (with a gateway)
3. Identifying missing elements in GraphQL Developer Tooling

Even though the discussion adhered to the set time limit, it undoubtedly contained a wealth of material.

The primary conclusion drawn from this conversation was the pressing need for additional standards, or even better, detailed specifications for GraphQL implementation on both the server and client side. Developers frequently find themselves reapplying identical logic across different languages due to a lack of standardization. This often results in using one language as a foundation for the next.

However, if there's a deviation from the original, it could negatively impact the developer experience, especially for those working with numerous languages across different stacks.

Creating a specification doesn't have to be a complex process, nor does it need the sanction of anyone to be beneficial. Several years ago, Jayden Seric introduced the GraphQL multipart request specification. Anyone who is implementing multipart uploads will appreciate the guidance and insights offered by such a singular specification, allowing developers to concentrate on the tasks of building and delivering their applications.

During the first round's intermission, I had the chance to observe Uri Goldshtein guiding the Beyond GraphQL group. This intriguing dialogue explored how GraphQL's concepts could be integrated with other tools and standards, including OpenAPI and gRPC. The group also pondered over the existing divide and potential ways to bridge these specifications, aiming for a more unified landscape where the right tool can be chosen for the job.

The discussion, under Uri's skillful moderation, took an exciting turn as they probed the potential for repurposing existing APIs using GraphQL by means of automation. Numerous organizations and tools like GraphQL Mesh, Grafbase, SOFA, Hasura, and Wundergraph are already navigating these waters. They invite and appreciate the participation of anyone interested in contributing to this evolving domain through open-source projects.

In his concluding remarks, Uri underscored, "The moment has arrived for the discourse within the GraphQL ecosystem to evolve beyond the 'GraphQL vs. REST' debate. Instead, we should focus on how we can apply GraphQL's robust features to enrich other existing APIs."

Round 2#

Choosing the next discussion to attend proved to be quite a difficult task that saw me staring at a board of topic cards longer than I would like to admit. I was torn between the following topics:

• Relay
• Federation in Practice / Combining and Extending GraphQL APIs

Given my day-to-day role involves guiding and assisting developers to excel in extending GraphQL APIs with Grafbase, I felt a strong inclination towards this topic. However, my intuition, coupled with the palpable growing support for Relay, guided my decision in the end.

Hearing from Denis Badurina, Marion Schleifer, Stephan Schneider, and others about their experiences with Relay was enlightening.

I openly admitted to the group that it had been several years since my last encounter with Relay (which, admittedly, was not entirely successful), but I was eager to understand the current usage patterns and share some of the narratives I've come across in my GraphQL journey regarding why developers often don't select Relay as their first choice.

As the session neared its end, it became evident that there were some common reasons why Relay wasn't the first choice for developers:

• A perceived steep learning curve, mainly resulting from the mental model shift surrounding components and data dependencies.
• Setting up the compiler configuration was frequently a tedious task.

Interestingly, those developers who do use Relay are indeed very fond of it!

Round 3#

As the day was nearing its conclusion, it was time to choose a topic that would potentially ignite conversations even during the evening reception drinks. And I must say, I certainly opted for such a topic!

The subject at R3/C centred around the role of GraphQL in the era of TRPC and RSC. I commend Bogdan for his audacity to bring up such a contentious topic. But then again, we were at a GraphQL event, so the reactions wouldn't have been as fiery as they would have been if this topic had emerged on a tweet.

All participants were given the opportunity to express their opinions and explain why the topic stirred up so much controversy. Uri Goldshtein introduced some impressive open source projects within the community, particularly Garph/GQty, which aim to close the gap and simplify the process of generating types for end-to-end type safety.

The omnipresence of React is no secret. Its adoption is surging across the board, a trend further amplified by the significant influence that Next.js has exerted within the ecosystem.

State of JavaScript 2022: Front-end Frameworks

It's also well-known that the rise of Next.js and RSC is stirring up numerous concerns and questions, and encountering some challenges, as it propels the community forward with their runtime implementation of React Server Components. I believe GraphQL is also at a crossroads, trying to determine its ideal niche within this evolving React ecosystem.

However, it's crucial to remember that while React and Next.js are prevalent choices, there are many other languages and frameworks that can leverage GraphQL. As a community, we sometimes overlook these alternatives.

If you haven't yet used Houdini GraphQL and Svelte, you're in for a treat. Houdini offers a refreshing approach to constructing type-safe web applications powered by GraphQL.

Overall, it seemed that GraphQL was continuing to expand, but its applications were shifting. Developers who are building web and mobile applications seem to be moving towards simpler routing mechanisms, like Tanstack and React Router, coupled with Relay for client-side data loading and caching.

Key Insights from GraphQL EU#

While I couldn't be part of every conversation, a myriad of topics were undoubtedly discussed during the reception after-party, and even the after-after-party.

Below are the main insights I jotted down in my Notes App throughout the day:

• Despite its initial complexity and paradigm shift, Relay is increasingly adopted by those with more GraphQL experience, especially due to its ability to co-locate fragments with their respective components.
• While tRPC is attractive, not all companies have total control over their tech stacks and rely on external GraphQL APIs. Consequently, more developers are utilizing gateway or federation methods to integrate these APIs.
• Ensuring GraphQL APIs are versionless is vital for mobile applications to function smoothly, given users frequently lag in updating their apps.
• For SPAs or mobile apps, where client fetching is preferable, GraphQL still offers a superior experience. React Server Components (RSC), particularly with Next.js, doesn't provide much scope for GraphQL, and that's acceptable.
• For server-rendered applications, GraphQL remains a viable choice. As a simple function or network call, it can facilitate integration with multiple APIs more efficiently than having to install numerous SDKs.

What's next for GraphQL?#

As significant as this event was, we are set to surpass it with the official GraphQL Conf, scheduled for September 19-21 in San Francisco. If you thought this event was insightful, I guarantee you that the upcoming conference is going to be a game-changer!

You wouldn't want to miss out, so grab your tickets soon! I look forward to seeing many familiar faces and meeting new ones at the conference.

Get involved#

Though the aforementioned reflections encapsulate my journey, I encourage you to contribute your unique experiences to our collective narrative. Connect with us on Discord and enrich the GraphQL community with your insights.

See you in San Francisco!

BlogRecapping our latest Q&A Session - Scaling UI Development with Relay GraphQL

blog

Jory BursonJuly 19, 2023

On July 12, we hosted an an enlightening Q&A session on scaling UI development with Relay GraphQL. Participants included several experts from Hasura as well as interested attendees from our Discord community. The Q&A session was all about discussing the power of Relay in the realm of UI development. Tanmai Gopal, CEO of Hasura, and Akshaya Acharya, developer at Hasura, led the conversation, sharing their experiences and knowledge about the utilization of Relay and GraphQL in managing UI projects.

For those who couldn’t make it, we’ve captured the highlights and insights shared during the discussion. Read on, and join us for our next Q&A Session on July 26 for another discussion about GraphQL at Scale on the GraphQL Community Discord server!

1. Scaling UI development with Relay GraphQL: The Hasura team discussed how Relay GraphQL can facilitate scaling UI development, emphasizing how it can be a practical solution to prevent in-house development of similar mechanisms.

2. Relay and React Server Component (RSC): They discussed their learnings from comparing and trying Relay with React’s next-gen features like RSC and server actions. They pointed out that Relay fits well into things like RSC and solves issues that RSC alone does not handle, such as “compose API fetching across different types of components and craft the best / minimal set of queries.”

3. Migration to Relay: The Hasura team shared their ongoing experience of migrating existing UI to Relay to improve team productivity. They emphasized the need to introduce Relay in independent and then closely connected components to avoid data inconsistency issues.

4. Nullable-by-default schema with client controlled nullability: The team also discussed the idea of using a nullable-by-default schema with client-controlled nullability. They noted that, while this approach can solve problems related to resolver errors and changes in the data model, it requires careful handling on the client side.

5. Integration of Relay with NextJS: Examples were shared on how to integrate Relay with the NextJS App Router and NextJS Pages Router.

6. Development Tools for Relay: They showed interest in the tools the community is using to build a backend Relay server, and the challenges faced while working with Relay.

7. Relay and backend practices: The Hasura team mentioned that they have not enforced nullable-by-default schemas yet and they can handle breaking changes rapidly due to their ability to iterate quickly on their GraphQL server.

The discussion provided valuable insights into how Relay GraphQL can ease and scale UI development. Notably, the real-world experiences shared by the Hasura team brought home the potential and practical advantages of using Relay in handling large-scale UI projects.

For those who missed it or wish to revisit, the full transcript is available on our Discord channel.

Stay tuned for more such interactive Q&A sessions about modern topics and opportunities with GraphQL. If you have an idea or request for a Q&A session, please let us know!

July 6, 2023 by Jory Burson

blog

Have you been missing out on recent GraphQL Working Group meetings? Want to catch up on the latest conversations about Incremental Delivery, GraphQL over HTTP, and Input Unions? Thanks to Benjie Gillam, now you can!

Benjie has done the onerous job of updating the GraphQL Foundation’s YouTube playlists with all the latest recordings of GraphQL Working Group meetings, which are now available for you to view here: https://youtube.com/@GraphQLFoundation/playlists

GraphQL technical working group meetings are open to the public, and can be found on our calendar at https://calendar.graphql.org. Community members can subscribe to the whole calendar or to a specific meeting series for personal updates. For those who can’t make it, we encourage you to subscribe to the YouTube channel to get notified when working group meetings are posted.

blog

blog

In the fast-paced world of software development, staying updated with the latest technologies and best practices is crucial. GraphQL, a query language for APIs, has gained immense popularity for its flexibility and efficiency in fetching data. To delve deeper into the realm of GraphQL and its impact, a recent Q&A session with members of The Guild, an organization of open source contributors, provided valuable insights and recommendations. Let’s explore the highlights of this session and gain a better understanding of the power of GraphQL.

Philosophies and structure for open source organizations

During the Q&A session, The Guild members emphasized that their organization was created for the main purpose of long term open source maintenance. This decision led the organization to structure the group’s work in a different way, such as having all of their projects under individual contributors names and not under the Guild’s GitHub org, like Yoga, Mesh and others.

They also focused on hiring people who were already community contributors before joining The Guild, in order to ensure that they support existing open source contributors and reduce bias in the selection process (by focusing on the individual’s work, rather than their location or identity). That led into a diverse team from all across the globe, and they have written more about that model in their about page.

During the Q&A, The Guild emphasized their support for local Meetup groups and their history of helping to start new ones. This commitment to community involvement reflects their dedication to fostering knowledge sharing and collaboration, which is essential for sustainable open source projects.

Authorization and Shielding with Envelop

The Guild team recommended using Envelop, a plugin system that manipulates the execution flow, for authorization and shielding in GraphQL APIs. This approach provides a powerful alternative to directly wrapping resolvers, ensuring robust security measures are in place. By leveraging Envelop, developers can enhance the authorization control in their GraphQL APIs.

Granular Authorization Control with Postgres’ Row-Level Security

In addition to Envelop, the discussion highlighted the use of Postgres’ Row-Level Security as a means of achieving more granular authorization control. This feature allows developers to define security policies at the database level, ensuring that only authorized users can access specific rows of data. By incorporating Postgres’ Row-Level Security, developers can further fortify their GraphQL APIs against unauthorized access.

The Advantages of “Non-Spec” GraphQL and Envelop/Yoga plugins

The discussion also touched upon the benefits of using “non-spec” GraphQL features. With Envelop, you can safely use advanced GraphQL features before they are included in the official spec, which releases less frequently.

These tools offer additional functionalities and optimizations, enabling developers to maximize the potential of GraphQL in their projects. The Guild team emphasized the value of exploring these options to enhance performance and streamline development processes while also giving valuable feedback from real production usage to the GraphQL Working Group about these features.

Caching GraphQL Operations

Participants in the session raised intriguing points about caching GraphQL operations. The Guild team acknowledged the potential advantages of adding caching to GraphQL requests, optimizing response times and reducing unnecessary network traffic. The point was raised that one can achieve more granular caching with GraphQL than with REST, and a primary reason people think caching is harder in GraphQL is the lack of knowledge about tools like Stellate and Yoga’s response caching support.

GraphQL Workflows at scale

In discussing larger-scale usage of GraphQL, The Guild participants referenced some of their work helping large teams manage GraphQL APIs using workflows and tools using tools such as GraphQL Hive, an open source schema registry. Some of the new features recently released to Hive, such as the schema policy feature, enable organizations to enforce best practices and schema rules across many different teams automatically.

Community Stewardship and Future Collaborations

The Guild team acknowledged the importance of community contributions and discussed their efforts to improve and simplify the GraphQL community website, and emphasized the importance of fostering a vibrant and inclusive GraphQL community. The Q&A session with The Guild offered a wealth of knowledge and insights into the world of GraphQL. Furthermore, the session highlighted areas for improvement and opportunities for community members to contribute. For more information check out The Guild’s projects and blog and our GraphQL official community page.

As the GraphQL ecosystem continues to evolve, sessions like these provide valuable guidance and foster a sense of community among developers, paving the way for innovation and growth in our exciting ecosystem. Please join us on June 28 for our next Discord Q&A session featuring engineering leaders from Hasura.

Philosophies and structure for open source organizations:

During the Q&A session, The Guild members emphasized that their organization was created for the main purpose of long term open source maintenance. This decision led the organization to structure the group's work in a different way, such as having all of their projects under individual contributors names and not under the Guild’s GitHub org, like Yoga, Mesh and others.

They also focused on hiring people who were already community contributors before joining The Guild, in order to ensure that they support existing open source contributors and reduce bias in the selection process (by focusing on the individual's work, rather than their location or identity). That led into a diverse team from all across the globe, and they have written more about that model in their about page.

During the Q&A, The Guild emphasized their support for local Meetup groups and their history of helping to start new ones. This commitment to community involvement reflects their dedication to fostering knowledge sharing and collaboration, which is essential for sustainable open source projects.

Authorization and Shielding with Envelop:

The Guild team recommended using Envelop, a plugin system that manipulates the execution flow, for authorization and shielding in GraphQL APIs. This approach provides a powerful alternative to directly wrapping resolvers, ensuring robust security measures are in place. By leveraging Envelop, developers can enhance the authorization control in their GraphQL APIs.

Granular Authorization Control with Postgres's Row-Level Security:

In addition to Envelop, the discussion highlighted the use of Postgres's Row-Level Security as a means of achieving more granular authorization control. This feature allows developers to define security policies at the database level, ensuring that only authorized users can access specific rows of data. By incorporating Postgres's Row-Level Security, developers can further fortify their GraphQL APIs against unauthorized access.

The Advantages of "Non-Spec" GraphQL and Envelop/Yoga plugins:

The discussion also touched upon the benefits of using "non-spec" GraphQL features. With Envelop, you can safely use advanced GraphQL features before they are included in the official spec, which releases less frequently.

These tools offer additional functionalities and optimizations, enabling developers to maximize the potential of GraphQL in their projects. The Guild team emphasized the value of exploring these options to enhance performance and streamline development processes while also giving valuable feedback from real production usage to the GraphQL Working Group about these features.

Caching GraphQL Operations:

Participants in the session raised intriguing points about caching GraphQL operations. The Guild team acknowledged the potential advantages of adding caching to GraphQL requests, optimizing response times and reducing unnecessary network traffic. The point was raised that one can achieve more granular caching with GraphQL than with REST, and a primary reason people think caching is harder in GraphQL is the lack of knowledge about tools like Stellate and Yoga’s response caching support.

GraphQL Workflows at scale:

In discussing larger-scale usage of GraphQL, The Guild participants referenced some of their work helping large teams manage GraphQL APIs using workflows and tools using tools sluch as GraphQL Hive, an open source schema registry. Some of the new features recently released to Hive, such as the schema policy feature, enable organizations to enforce best practices and schema rules across many different teams automatically.

Community Stewardship and Future Collaborations:

The Guild team acknowledged the importance of community contributions and discussed their efforts to improve and simplify the GraphQL community website, and emphasized the importance of fostering a vibrant and inclusive GraphQL community. The Q&A session with The Guild offered a wealth of knowledge and insights into the world of GraphQL. Furthermore, the session highlighted areas for improvement and opportunities for community members to contribute. For more information check out The Guild’s projects and blog and our GraphQL official community page.

As the GraphQL ecosystem continues to evolve, sessions like these provide valuable guidance and foster a sense of community among developers, paving the way for innovation and growth in our exciting ecosystem. Please join us on June 28 for our next Discord Q&A session featuring engineering leaders from Hasura.

grants

The GraphQL Foundation offers Community Grants to help incentivize key technical and community initiatives. As part of the grant, applicants commit to write a blog post report describing their work and its impact on the GraphQL community. The following report was written by successful grant applicant Benjie Gillam in August 2022, detailing the community gardening he performed during May, June and July of that year.

Backstory

In 2019 I started turning up to GraphQL Working Group meetings regularly and helping take the notes. Back then we had a system for filing and reviewing action items, but very few people used it, so items would easily get lost. Further, the notes and videos would be uploaded in batches every few months, which prevented attendees referring to them in the interim.

Over the next couple years I set about trying to improve these processes. I started by filing the action items myself. After a while, I started categorizing them into GitHub projects, one for each meeting, which made keeping track of them (particularly the old ones) much easier and helped us to see progress. Later I introduced a new “ready for review” label that enabled us to quickly focus on the action items that needed discussion rather than trying to go over every item (or skip the lot entirely) each meeting. These processes were very much appreciated by the working group, but were quite time consuming for one person. As time went on my I found myself contributing to GraphQL in more and more ways, and as the time I could dedicate to these tasks dwindled, my ability to keep these processes running smoothly diminished.

Funding approved

In May 2022, the GraphQL Foundation kindly approved my application for a GraphQL Community Grant to enable me to dedicate more time to these tasks. I’m a community-funded open source developer, so I rely on sponsorship to fund my open source endeavors - both on my own open source projects (the Graphile suite) and also my contributions to the GraphQL Working Groups. Since being approved for the grant, I’ve been better able to execute the role of community gardener; let me tell you about some of the ways in which the Foundation’s grant has enabled me to better support you, the GraphQL community!

The main GraphQL working group meets each month; and it is recorded on Zoom and made available via the Foundation’s YouTube channel. Soon after each meeting I’ve been uploading the videos not just for the main meeting but also for the various other subcommittees (GraphiQL WG, GraphQL.js WG, GraphQL-over-HTTP WG, Metadata WG, Composite Schemas WG) that may have met during the previous month. Whilst uploading the video of the main meeting, I file its notes and the action items, while also categorizing them making sure they’re assigned to the relevant person. Recently, I’ve also started adding timestamped links to the YouTube video for each action item, so we can hear the original instructions rather than just the paraphrased summaries from the notes - I think this makes them even more useful!

Empowering other contributors

As part of my aim to document our processes and streamline things, I’ve created a template repository that can be used whenever a new GraphQL subcommittee is created. This enables all subcommittees to adopt the GraphQL meeting practices with minimal effort from the committee chair - just a small list of edits that take about 5 minutes when setting up the repository and of course the regular scheduling.

I’ve also been working with the Linux Foundation to get subcommittee meetings scheduled onto the GraphQL calendar, and to expand EasyCLA to the new repositories to ensure that everyone contributing has signed the GraphQL Membership Agreement. This should make releasing future versions of the spec and any subcommittee deliverables much easier since the intellectual property paperwork is in place from the start.

Thanks to the new funding I’ve also been able to be more active on GitHub issues, PRs, discussions and in the GraphQL Discord server, enabling me to offer assistance to people interested in contributing, and to help moderate these environments. This includes explaining how to become a champion, performing timely moderation actions when the Discord server suffers from spam, and giving guidance on how to improve PRs.

Extra-curricular activities

Whilst not technically under the umbrella of the grant, having the time spent on the above tasks funded by the GraphQL Grant has freed me up to dedicate more time to other key issues in GraphQL - for example I recently revived the GraphQL-over-HTTP project and we’re well on the way towards v1 of that specification. I’ve also helped kick-start the GraphQL Composite Schemas working group for the community to collaborate on shared solutions to common problems felt across all the different ways of building a GraphQL schema by combining other GraphQL schemas together. I’ve also finally been able to follow through on my intent to push the “GraphQL Metadata” topic forward including researching, digesting, and sharing my analysis of the existing solutions and their problems at the GraphQL Conference, and suggesting a solution of my own. Another thing that this reduced pressure on my time has enabled is the new SpecNews podcast in which my co-host Jem and I summarize the latest GraphQL Specification Working Group session in just 5-10 minutes.

Get involved!

If you’re interested in contributing to GraphQL and need help getting started, feel free to reach out to me, @benjie, on Discord or via a GitHub issue or PR, and I’ll do my best to help!

The GraphQL Foundation offers Community Grants to help incentivize key technical and community initiatives. As part of the grant, applicants commit to write a blog post report describing their work and its impact on the GraphQL community. The following report was written by successful grant applicant Benjie Gillam in August 2022, detailing the community gardening he performed during May, June and July of that year.

Backstory#

In 2019 I started turning up to GraphQL Working Group meetings regularly and helping take the notes. Back then we had a system for filing and reviewing action items, but very few people used it, so items would easily get lost. Further, the notes and videos would be uploaded in batches every few months, which prevented attendees referring to them in the interim.

Over the next couple years I set about trying to improve these processes. I started by filing the action items myself. After a while, I started categorizing them into GitHub projects, one for each meeting, which made keeping track of them (particularly the old ones) much easier and helped us to see progress. Later I introduced a new "ready for review" label that enabled us to quickly focus on the action items that needed discussion rather than trying to go over every item (or skip the lot entirely) each meeting. These processes were very much appreciated by the working group, but were quite time consuming for one person. As time went on my I found myself contributing to GraphQL in more and more ways, and as the time I could dedicate to these tasks dwindled, my ability to keep these processes running smoothly diminished.

Funding approved#

In May 2022, the GraphQL Foundation kindly approved my application for a GraphQL Community Grant to enable me to dedicate more time to these tasks. I'm a community-funded open source developer, so I rely on sponsorship to fund my open source endeavors - both on my own open source projects (the Graphile suite) and also my contributions to the GraphQL Working Groups. Since being approved for the grant, I've been better able to execute the role of community gardener; let me tell you about some of the ways in which the Foundation's grant has enabled me to better support you, the GraphQL community!

The main GraphQL working group meets each month; and it is recorded on Zoom and made available via the Foundation's YouTube channel. Soon after each meeting I've been uploading the videos not just for the main meeting but also for the various other subcommittees (GraphiQL WG, GraphQL.js WG, GraphQL-over-HTTP WG, Metadata WG, Composite Schemas WG) that may have met during the previous month. Whilst uploading the video of the main meeting, I file its notes and the action items, while also categorizing them making sure they're assigned to the relevant person. Recently, I've also started adding timestamped links to the YouTube video for each action item, so we can hear the original instructions rather than just the paraphrased summaries from the notes - I think this makes them even more useful!

Empowering other contributors#

As part of my aim to document our processes and streamline things, I've created a template repository that can be used whenever a new GraphQL subcommittee is created. This enables all subcommittees to adopt the GraphQL meeting practices with minimal effort from the committee chair - just a small list of edits that take about 5 minutes when setting up the repository and of course the regular scheduling.

I've also been working with the Linux Foundation to get subcommittee meetings scheduled onto the GraphQL calendar, and to expand EasyCLA to the new repositories to ensure that everyone contributing has signed the GraphQL Membership Agreement. This should make releasing future versions of the spec and any subcommittee deliverables much easier since the intellectual property paperwork is in place from the start.

Thanks to the new funding I've also been able to be more active on GitHub issues, PRs, discussions and in the GraphQL Discord server, enabling me to offer assistance to people interested in contributing, and to help moderate these environments. This includes explaining how to become a champion, performing timely moderation actions when the Discord server suffers from spam, and giving guidance on how to improve PRs.

Extra-curricular activities#

Whilst not technically under the umbrella of the grant, having the time spent on the above tasks funded by the GraphQL Grant has freed me up to dedicate more time to other key issues in GraphQL - for example I recently revived the GraphQL-over-HTTP project and we're well on the way towards v1 of that specification. I've also helped kick-start the GraphQL Composite Schemas working group for the community to collaborate on shared solutions to common problems felt across all the different ways of building a GraphQL schema by combining other GraphQL schemas together. I've also finally been able to follow through on my intent to push the "GraphQL Metadata" topic forward including researching, digesting, and sharing my analysis of the existing solutions and their problems at the GraphQL Conference, and suggesting a solution of my own. Another thing that this reduced pressure on my time has enabled is the new SpecNews podcast in which my co-host Jem and I summarize the latest GraphQL Specification Working Group session in just 5-10 minutes.

Get involved!#

If you're interested in contributing to GraphQL and need help getting started, feel free to reach out to me, @benjie, on Discord or via a GitHub issue or PR and I'll do my best to help!

announcements

announcements

We are very happy to announce the official home for contributed GraphQL custom scalar specifications at scalars.graphql.org.

You are welcome to contribute custom scalar specifications (abbreviated as “specs”). Once your spec is merged in, it will be hosted at . See how to contribute on the contribution guide.

Our first contributed spec is for DateTime. You can point users to the spec’s URL with the built-in directive in your GraphQL schema.

Elevating the GraphQL type system with custom scalars

Custom scalars have been part of the GraphQL spec since day one. They have the unique ability to extend the GraphQL type system with custom types. While custom scalars are powerful, they were more like a black box for the consumers of the API.

Originally, it was very hard for consumers to understand custom scalars as a GraphQL schema did not provide any information apart from its name. For example, it was difficult to understand the exact format of a custom scalar. It was also difficult to know whether the custom scalar in API A was exactly the same as the in API B.

We added the built-in directive some time ago, which assigns a URL for the spec of a custom scalar. This provides a standard way to document custom scalars. The directive is also introspectable.

However, we have since learned that this was not enough. The burden of writing a custom scalar specs and hosting them was left for each API itself to solve.

With the custom scalar spec project, we provide templates for writing custom scalar specs and also host the specs at a GraphQL Foundation owned domain scalars.graphql.org. This greatly reduces the effort to clearly document and share your custom scalar specs.

Our hope is that this enables an ecosystem of clearly documented custom scalars and eliminates the need to reinvent popular ones again and again. Ultimately, a popular enough custom scalar will be practically indistinguishable from the built-in ones and elevate the GraphQL type system.

Get involved!

See how to contribute a custom scalar spec on the contribution guide.

If you have any comments or questions, please open an issue on the graphql-scalars GitHub repository.

announcements

newsletter

GraphQL is most commonly served over HTTP. However, despite GraphQL being well specified, this HTTP transport is not. To correct for this, the GraphQL working group has been working on the GraphQL over HTTP specification.

Alongside a specification, we prefer a true implementation to have as a reference. This ensures the ideas we specify can be implemented well, and that as edge-cases arise in software we can ensure their solutions are reflected in the specification as well.

For GraphQL over HTTP, this has nominally been express-graphql. This package makes it easy to create a GraphQL serving endpoint from an express server. However, as the Node community has grown over the years, alternatives to express have emerged and there is no longer one framework to align to. Also, as our maintenance bandwidth has focused on other projects, express-graphql has fallen behind.

Luckily, thanks to the focused efforts of Denis Badurina, we have an alternative in graphql-http. Denis has been part of the committee working on the GraphQL over HTTP specification, and sought to build a dependency-free compliant GraphQL server that works with most all existing Node.js and Deno HTTP frameworks.

The decision was made to adopt the graphql-http project into the GraphQL Foundation (with Denis continuing as the lead maintainer), as well as to make it the official reference implementation of GraphQL over HTTP.

We will be deprecating express-graphql as part of this change, and recommending those using it migrate to graphql-http.

newsletter

newsletter

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 /

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…

• Database, Trends & Applications: Hasura Adds the Ability to Access Existing Data and Move it with GraphQL API
• InfoQ: Rebuilding Twitter’s Public API
• ZDNet: MuleSoft adds DataGraph to Anypoint Platform to streamline API requests

Upcoming Events

• GraphQL Conf. 2021 - September 29th

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.

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!

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...#

• Database, Trends & Applications: Hasura Adds the Ability to Access Existing Data and Move it with GraphQL API
• InfoQ: Rebuilding Twitter's Public API
• ZDNet: MuleSoft adds DataGraph to Anypoint Platform to streamline API requests

Upcoming Events:#

• GraphQL Conf. 2021 - September 29th

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.

newsletter

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.

Spec cut

There are few more final phase proposals still waiting on review, as well as updating the version of the legal text). The next step will include having the TSC take a formal vote to cut the draft.

TypeScript migration for GraphQL.js

Representing almost 6 million downloads per week. TypeScript is in need of additional clean up, including GraphQLList and GraphQLNonNull. The WG decided to drop Flow types, and have a PR for converting to TypeScript. The plan is to incorporate the fixes into the main release, which is very close to being done. Once finished, it will be added to release 16.0.0-alpha.1. Once that is complete it will merge the PR and convert to TypeScript.

Adding descriptions to queries and fragments

The purpose of this discussion is to add necessary comments for various business use cases. As of now we have to parse SDL data and it’s problematic when people add other comments. The WG is working on the best way to solve this issue.

Schema introspection extensions

First implemented by GraphQL Java,then some issues were found and it was discovered there was some additional work to be done before turning it into an RFC. The Working Group is planning to address these issues shortly.

In Other News…

• Dgraph announces v21.03 - Resilient Rocket Release
• Read: GraphQL API Security best practices with AWS AppSync and Amplify
• AWS AppSync is a fully managed service which allows developers to deploy and interact with serverless scalable GraphQL backends on AWS.
• Neo4j announces GraphQL Library Beta Release
• TechTarget: Dgraph GraphQL database users detail graph use cases
• Devops.com: Apollo GraphQL Makes Federated Server More Accessible
• The New Stack: Why Shopify Favors GraphQL over REST for Its APIs
• Code Story: E17: Matt Debergalis, Apollo GraphQL

Upcoming Events

• Hasura Con ‘21: The Big Hasura User Conference The 2021 installment of Hasura Con will take place on June 23rd and 24th. The event brings together users from all over the world to celebrate all things Hasura and will feature top-notch speakers and workshops. Sign up today to attend Hasura Con ‘21 or submit a talk proposal to share your knowledge at the event.

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.

newsletter

newsletter

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.

Allowing fields to diverge more

This is one of the most complicated validation rules, which is about overlapping fields and not forcing to ensure every field is unique in a query, especially if you compose queries. They have to be merged together and ensure the field is only executed once. There’s a rule to ensure this merging can be done.

The working group has agreed to add prose or a non-normative note to this validation rule to explain this.

Operation Expressions

Operation expressions is an extension to the Schema Coordinates syntax that allows for a host of new use cases. Outlined here are some of the use cases that have been discussed so far, and have iterated on the syntax, but everything in this is very much in flux.

Directions via introspection report

Custom directives are not currently introspectable. This has been a big discussion over the years. Recently, graphql-java has implemented (almost merged) the ability to query directive by introspection.

Oneof Input Objects and Oneof Fields

Oneof Input Objects are a special variant of Input Objects where the type system asserts that exactly one of the fields must be set and non-null, all others being omitted. This is represented in introspection with the field, and in SDL via the directive on the input object. The working group has agreed to Contribute syntax thoughts and on the RFC itself, and write an implementation in GraphQL.js

In Other News…

• ZDNet: Databases, graphs, and GraphQL: The past, present, and future
• ZDNet: Hasura connects GraphQL to the REST of the world
• ADT Mag: Netflix Open Sources GraphQL for Spring Boot
• ProgrammableWeb: Facebook Adds Relay Hooks for Improved GraphQL Data Fetching
• Dgraph Labs Launches Slash GraphQL, Industry’s First GraphQL-Native Database Backend-As-A-Service
• How Square accelerates product development with Apollo GraphQL
• Netflix: Beyond REST Rapid Development with GraphQL Microservices
• The Guild announce early access to GraphQL Hive - A new Schema Registry for your GraphQL Workflows

Upcoming Events

• The GraphQL community will come together once again for GraphQL Summit April 7th & 8th

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.

newsletter

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

Advancing no introspection at root of Subscription operation

The group decided to disallow since it doesn’t work in the reference implementation. During the graphql-js implementation some issues were discovered around fragments that are being fixed. Read more here.

Default value coercion update

Currently this is a case where infinite loops can occur. The WG is working to figure out how to avoid this in the spec here.

Defer/stream updates

The official experimental branch of graphql-js/express-graphql. The WG is working to update the initialCount, validation rule in GraphQL.js, and the spec.

Schema Coordinates Spec

The RFC and spec edit have been out for a few months with credit due to everyone who has reviewed those. Last time the field arguments were the discussion there were two main contenders: versus . The WG is looking for consensus. The discussion summarized can be found here.

_Typename is not valid at subscription root

does not return an async iterator and has been deemed not useful at the root of a subscription operation, yet it is allowed by GraphQL validation. This field has caused some confusion in the community, and the WG has proposed explicitly validating it to prevent the field to catch these issues earlier.

Default value coercion

There’s inconsistency in the handling of default values between user-supplied defaults (i.e. variables in operation documents) and schema-supplied defaults (for arguments or input object fields). The WG discussed ways in which a poorly constructed GraphQL schema can break the type safety guarantees of GraphQL and proposed addressing this by making schema defaults operate in a more expected manner. Next steps are to get an implementation finished so that we can advance the spec changes to stage 2.

In Other News…

• Federated GraphQL @ Walmart
• Apollo Extends Explorer GraphQL IDE to Development Environments
• How Netflix Scales its API with GraphQL Federation (Part 2)
• Hasura launched a 3 week series of articles, live-streams, and A.M.As for GraphQL beginners and experts.
• Prisma announced Nexus 1.0: A Major Release for Type-Safe, Code-First GraphQL APIs
• ZDNet: 2021 Technology trend review: Cloud, Kubernetes, and GraphQL
• TechTarget: Enterprise application trends that will impact 2021: GraphQL vs. REST choice steers microservices development
• Top 20 GraphQL Jobs Postings
• GraphQL Galaxy’s talk uploaded online, check out the Keynote!
• The new Schema Stitching Handbook was released, together with examples and video walkthrough with everything you need to know about Federated/Distributed GraphQL Gateways
• The Guild announced GraphQL Modules 1.0 as a major rewrite after 3 years of experience. The new version includes better simplicity and performance
• With GraphQL Mesh you can now wrap any existing API and add reactivity to it - check out this blog post about how to do it
• spotify-graphql is approaching v2.0 as a complete rewrite, instead of manual code it uses GraphQL Mesh under the hood to generate the API
• Software Engineering Daily: Podcast with DGraph’s Manit Jain

Upcoming Events

• Asia’s largest GraphQL conference is back! February 24th & 25th

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.

Rob Richard and Liliana Matos are front-end engineers at 1stDibs.com. They have been working with the GraphQL Working Group as champions of the the @defer and @stream directives.

The @defer and @stream directives have been a much anticipated set of features ever since Lee Byron first talked about it at GraphQL Europe 2016. For most of 2020, we have been working with the GraphQL Working Group to standardize this feature. It is now a Stage 2 proposal, but to advance further, we are looking to the GraphQL community to try using these directives and provide feedback. We have released experimental versions of GraphQL.js and express-graphql. They are published to npm under graphql@experimental-stream-defer and express-graphql@experimental-stream-defer. We encourage everyone interested in this feature to try out these releases and let us know how it goes in the issue created for feedback. Read on to find out more about what this proposal offers.

One of the disadvantages of GraphQL’s request/response model is that the GraphQL response is not returned to clients until the entire request has finished processing. However, not all requested data may be of equal importance, and in some use cases it may be possible for applications to act on a subset of the requested data. An application can speed up its time-to-interactive if the GraphQL server can send the most important data as soon as it’s ready. The new @defer and @stream directives allow GraphQL servers to do exactly that by returning multiple payloads from a single GraphQL response.

The @defer directive can be applied to fragment spreads and inline fragments. It is a declarative way for developers to mark parts of a query as non-essential for immediate return.

Here’s an example of the @defer directive:

Request#

query{

person(id:"cGVvcGxlOjE="){

name

...HomeworldFragment @defer(label:"homeworldDefer")

}

fragment HomeworldFragment on Person {

homeworld {

name

}

}

Response#

Payload 1

{

"data":{

"person":{

"name":"Luke Skywalker"

}

},

"hasNext":true

}

Payload 2

{

"label":"homeworldDefer",

"path":["person"],

"data":{

"homeworld":{

"name":"Tatooine"

}

},

"hasNext":false

}

When the GraphQL execution engine encounters the @defer directive, it will fork execution and begin to resolve those fields asynchronously. While the deferred payload is still being prepared, the client can receive and act on the initial payload. This is most useful when the deferred data is large, expensive to load, or not on the critical path for interactivity.

Similar to @defer, the @stream directive also allows the client to receive data before the entire result is ready. @stream can be used on list fields. Here’s an example of the @stream directive:

Request#

query{

person(id:"cGVvcGxlOjE="){

name

films @stream(initialCount:2,label:"filmsStream"){

title

}

}

Response#

Payload 1

{

"data":{

"person":{

"name":"Luke Skywalker",

"films":[

{"title":"A New Hope"},

{"title":"The Empire Strikes Back"}

]

}

},

"hasNext":true

}

Payload 2

{

"label":"filmsStream",

"path":["person","films",2],

"data":{

"title":"Return of the Jedi"

},

"hasNext":true

}

Payload 3

{

"label":"filmsStream",

"path":["person","films",3],

"data":{

"title":"Revenge of the Sith"

},

"hasNext":false

}

When the GraphQL execution engine encounters the @stream directive, it will resolve as many list items specified by the initialCount argument. The rest will be resolved asynchronously. This is especially useful for an interface where only a few elements can be rendered above the fold. The client can render these elements as soon as possible while the server is still resolving the rest of the data.

While the GraphQL specification doesn’t specify transport protocols, we expect the most common transport for queries with @defer/@stream to be HTTP with chunked transfer encoding. This allows a GraphQL server to keep a standard HTTP connection open, while streaming each payload to the client as soon as it’s ready. It has low overhead, has been supported by browsers for decades, and can work easily with most infrastructure.

You can learn more about these directives at:

• The @defer/@stream RFC
• The proposed spec edits
• The GraphQL Incremental Delivery over HTTP RFC
• Our talk at GraphQL Summit 2020

– Rob Richard, Liliana Matos, Front-End Engineering, 1stDibs.com

announcements

Rob Richard and Liliana Matos are front-end engineers at 1stDibs.com. They have been working with the GraphQL Working Group as champions of the and directives.

The and directives have been a much anticipated set of features ever since Lee Byron first talked about it at GraphQL Europe 2016. For most of 2020, we have been working with the GraphQL Working Group to standardize this feature. It is now a Stage 2 proposal, but to advance further, we are looking to the GraphQL community to try using these directives and provide feedback. We have released experimental versions of and . They are published to npm under and . We encourage everyone interested in this feature to try out these releases and let us know how it goes in the issue created for feedback. Read on to find out more about what this proposal offers.

One of the disadvantages of GraphQL’s request/response model is that the GraphQL response is not returned to clients until the entire request has finished processing. However, not all requested data may be of equal importance, and in some use cases it may be possible for applications to act on a subset of the requested data. An application can speed up its time-to-interactive if the GraphQL server can send the most important data as soon as it’s ready. The new and directives allow GraphQL servers to do exactly that by returning multiple payloads from a single GraphQL response.

The directive can be applied to fragment spreads and inline fragments. It is a declarative way for developers to mark parts of a query as non-essential for immediate return.

Here’s an example of the directive:

Request Response Payload 1 Payload 2 When the GraphQL execution engine encounters the directive, it will fork execution and begin to resolve those fields asynchronously. While the deferred payload is still being prepared, the client can receive and act on the initial payload. This is most useful when the deferred data is large, expensive to load, or not on the critical path for interactivity. Similar to , the directive also allows the client to receive data before the entire result is ready. can be used on list fields. Here’s an example of the directive: Request Response Payload 1 Payload 2 Payload 3 When the GraphQL execution engine encounters the directive, it will resolve as many list items specified by the argument. The rest will be resolved asynchronously. This is especially useful for an interface where only a few elements can be rendered above the fold. The client can render these elements as soon as possible while the server is still resolving the rest of the data. While the GraphQL specification doesn’t specify transport protocols, we expect the most common transport for queries with / to be HTTP with chunked transfer encoding. This allows a GraphQL server to keep a standard HTTP connection open, while streaming each payload to the client as soon as it’s ready. It has low overhead, has been supported by browsers for decades, and can work easily with most infrastructure. You can learn more about these directives at: The @defer/@stream RFC The proposed spec edits The GraphQL Incremental Delivery over HTTP RFC Our talk at GraphQL Summit 2020 – Rob Richard, Liliana Matos, Front-End Engineering, 1stDibs.com

newsletter

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.

WG Updates

The GraphQL Working Group meets monthly, and records detailed minutes. You can also listen to the replays of GraphQL technical meetings on YouTube.

Query ambiguity: discussion of replacement terms

In the GraphQL ecosystem the term “query” can seem overloaded and ambiguous - sometimes it refers to the query operation type or a query operation, sometimes it refers to a GraphQL request or a GraphQL document containing operations, sometimes it refers to the contents of selection sets (as in “query reuse”), and sometimes it is used as a verb to refer to the generic act of querying a server for information.

The WG discussed the best way to remove this ambiguity and how to move forward.

Schema Coordinates RFC check in

The RFC is filed, and the next action is to turn this into an actual spec edit.

Tagged type update

This is an RFC for a new “Tagged type” to be added to GraphQL. It replaces the “@oneField directive” proposal following feedback from the Input Unions Working Group. Please note that “Tagged type” is the working name, and may change if we come up with a better name for it.

A Tagged type defines a list of named members each with an associated type (like the fields in Object types and Input Object types), but differs from Object types and Input Object types in that exactly one of those members must be present.

The aim of the Tagged type is to introduce a form of polymorphism in GraphQL that can be symmetric between input and output. In output, it can generally be used as an alternative to Union (the differences will be outlined below). It goes beyond interfaces and unions in that it allows the same type to be specified more than once, which is particularly useful to represent filters such as this pseudocode .

In Other News…

• Vox Media evaluates Apollo GraphQL Federation and The Guild Schema Stitching for the best GraphQL platform to manage “a chorus of applications working together to publish modern media”
• AWS released a “Decision Guide to GraphQL Implementation”
• Netflix discusses how it scales its API with Apollo GraphQL Federation via its next generation architecture, “Studio Edge”, which uses federation as a critical element.
• Building a GraphQL server with GraphQL Helix, a newly released library for building GraphQL APIs. The aim of GraphQL Helix is to allow developers to use new features that are not yet supported in other libraries and to prevent vendor lock-in.
• GraphQL Tools v7 was released to deliver the next generation GraphQL API Gateway, bringing a new way to federate multiple GraphQL servers, focusing on standard spec compliant GraphQ
• We’ve already announced that The Guild has recently joined the GraphQL Foundation and now they wrote a blog post about it. Who will be the next to join?

Upcoming Events

• Nov 17: GraphQL Contributor Days, in partnership with Hasura, will give important updates to the community, and provide a forum for anyone using GraphQL to have direct access to core contributors and authors of various libraries and frameworks through live chat and an online broadcast.
• Dec 2: Relay Meetup is a global, online meetup on Relay, the GraphQL client. This event will feature a conversation about the @defer and @stream directives and why it should be brought to the official GraphQL specification.
• Dec 7-8: GraphQL Galaxy Conference is a new remote conference focusing on all things GraphQL.
• Missed Apollo Day on Nov. 10th? Check out some of the great talks on Twitch.

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.

newsletter

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.

WG Updates

Allowing deprecation of inputs

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

Querying Query query queries: “query” ambiguity

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.

Other topics discussed

• TypeScript Migration Progress in graphql-js
• How to bootstrap graphql-js working group?
• GitHub infrastructure for managing Working groups
• Custom Scalars subproject

Ecosystem Updates

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.

In Other News…

• Dgraph Labs launched Slash GraphQL, a product that can help you get a working GraphQL backend in minutes
• A new library for the WebSocket Protocol has been created. Read more here.
• The Guild has created a new GraphQL-ESLint library for linting your GraphQL schemas and operations with community and custom rules. Read more here.
• GraphQL CLI 4.1 has been released. Read here about the new functionality.
• You can now consume WebHooks as GraphQL Subscriptions thanks to the new version of GraphQL Mesh. Read more here.
• Hasura’s Enterprise GraphQL Conf is taking place October 20-22. There is still time to register
• AWS released a new webinar “Build Modern Serverless Applications with GraphQL APIs and AWS AppSync”
• Catch up on recent talks from the GraphQL Berlin Meetup
• GraphQL Amsterdam, GraphQL Copenhagen, React GraphQL Academy and The Guild are collaborating on an online GraphQL Meetup. Check out the details here.
• Apollo created an Error Handling Visualizer tool, which provides an interactive playground to visualize the relationship between nullability and error handling in GraphQL, specifically with Apollo Client.

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.

Carolyn Stransky is a frontend developer and journalist based in Berlin, Germany. She is selected for Google Season of Docs 2020 - GraphQL Foundation under the mentorship of Ivan Goncharov. In this post, she will share her plans on how she is going to spend the next couple of months contributing to the GraphQL Foundation.

When I first heard about GraphQL three years ago, I thought that it was a programming language that constructed charts or plotted points on graphs. After building my first application with GraphQL, I would have categorized it as React-specific tooling, like Redux or React Router. Months later, I was still convinced it was just another Twitter-fueled programming trend.

Looking back now, it’s clear that my initial perceptions of GraphQL were incorrect… but they weren’t uncommon.

Learning a new technology comes with a lot of questions - and GraphQL is no exception. There are so many misconceptions about what GraphQL is and how it can be used. And I wasn’t the only GraphQL newbie holding on to those same, inaccurate beliefs.

After gaining a solid understanding of what GraphQL really is, I started giving presentations at conferences about how difficult I found the learning process (literally the talk title was Life is hard and so is learning GraphQL). This talk was cathartic, both for me and the audiences I was presenting to. Through my research, I also realized that while graphql.org thoroughly covers the core concepts, it doesn’t directly address some of the questions you face as a new learner.

Fortunately, GraphQL has evolved enough that the information is out there and available. It’s more a matter of finding it because that information is scattered throughout various resources and programming communities. That’s why I was excited to see a Frequently Asked Questions (FAQ) page as one of the proposed Season of Docs projects. And as someone who has openly critiqued the GraphQL documentation, I wanted to play a part in actively improving them.

There are two main goals behind this FAQ page:

1. Build a centralized resource for everyone. As of now, much of the GraphQL ecosystem is focused on JavaScript due to the early ties with Relay and React. But GraphQL is for everyone, regardless of programming language, so this resource should be too. To ensure this, the FAQ content will be framework agnostic and vendor-neutral.
2. Become a truly community-owned resource. GraphQL was initially passed down from Facebook, but it’s no longer maintained solely by Facebook. This should be a resource that everyone is welcome to contribute to and the community feels empowered to change and grow. That way, common questions won’t be left unanswered.

The plan for exactly how to tackle this page will morph and evolve throughout the next two and a half months. My hope, though, is that keeping these goals in mind will lead to a new resource that will help both newcomers and seasoned GraphQL users thrive.

In preparation for the documentation development part of Season of Docs, I became familiar with the repository behind graphql.org by triaging issues and reviewing open pull requests. I also helped with the ongoing migration to Gatsby because I’ll be building the new FAQ page in Gatsby (there are still open issues if you want to contribute). You can read more details about the community bonding phase on my blog.

The next step is to create the inaugural batch of FAQ content. This will be about 10-15 questions sourced from various areas of the Internet and in consultation with prominent GraphQL teachers. Once those are complete with thorough answers and built into the new Gatsby site, I’ll get feedback from the community (that’s you) and continue to iterate on the content, design, layout - everything!

If you have opinions or would like to follow the project’s progress, open an issue or lurk around the website repository.

– Carolyn Stransky, GSoD 2020, Graphql Foundation

announcements

Carolyn Stransky is a frontend developer and journalist based in Berlin, Germany. She is selected for Google Season of Docs 2020 - GraphQL Foundation under the mentorship of Ivan Goncharov. In this post, she will share her plans on how she is going to spend the next couple of months contributing to the GraphQL Foundation.

When I first heard about GraphQL three years ago, I thought that it was a programming language that constructed charts or plotted points on graphs. After building my first application with GraphQL, I would have categorized it as React-specific tooling, like Redux or React Router. Months later, I was still convinced it was just another Twitter-fueled programming trend.

Looking back now, it’s clear that my initial perceptions of GraphQL were incorrect… but they weren’t uncommon.

Learning a new technology comes with a lot of questions - and GraphQL is no exception. There are so many misconceptions about what GraphQL is and how it can be used. And I wasn’t the only GraphQL newbie holding on to those same, inaccurate beliefs.

After gaining a solid understanding of what GraphQL really is, I started giving presentations at conferences about how difficult I found the learning process (literally the talk title was Life is hard and so is learning GraphQL). This talk was cathartic, both for me and the audiences I was presenting to. Through my research, I also realized that while graphql.org thoroughly covers the core concepts, it doesn’t directly address some of the questions you face as a new learner.

Fortunately, GraphQL has evolved enough that the information is out there and available. It’s more a matter of finding it because that information is scattered throughout various resources and programming communities. That’s why I was excited to see a Frequently Asked Questions (FAQ) page as one of the proposed Season of Docs projects. And as someone who has openly critiqued the GraphQL documentation, I wanted to play a part in actively improving them.

There are two main goals behind this FAQ page:

1. Build a centralized resource for everyone. As of now, much of the GraphQL ecosystem is focused on JavaScript due to the early ties with Relay and React. But GraphQL is for everyone, regardless of programming language, so this resource should be too. To ensure this, the FAQ content will be framework agnostic and vendor-neutral.
2. Become a truly community-owned resource. GraphQL was initially passed down from Facebook, but it’s no longer maintained solely by Facebook. This should be a resource that everyone is welcome to contribute to and the community feels empowered to change and grow. That way, common questions won’t be left unanswered.

The plan for exactly how to tackle this page will morph and evolve throughout the next two and a half months. My hope, though, is that keeping these goals in mind will lead to a new resource that will help both newcomers and seasoned GraphQL users thrive.

In preparation for the documentation development part of Season of Docs, I became familiar with the repository behind graphql.org by triaging issues and reviewing open pull requests. I also helped with the ongoing migration to Gatsby because I’ll be building the new FAQ page in Gatsby (there are still open issues if you want to contribute). You can read more details about the community bonding phase on my blog.

The next step is to create the inaugural batch of FAQ content. This will be about 10-15 questions sourced from various areas of the Internet and in consultation with prominent GraphQL teachers. Once those are complete with thorough answers and built into the new Gatsby site, I’ll get feedback from the community (that’s you) and continue to iterate on the content, design, layout - everything!

If you have opinions or would like to follow the project’s progress, open an issue or lurk around the website repository.

– Carolyn Stransky, GSoD 2020, GraphQL Foundation

newsletter

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

Updates

GraphQL over WebSocket refresh, existing issues and security implications

This discussion topic proposes taking on the following two critical items of security and bypassing the onConnect event. And possibly re-writing the WebSocket protocol from scratch with full RFCs

Tagged Type RFC

This is an RFC for a new “Tagged” type to be added to GraphQL, to help address the input polymorphism feature gap. Originally proposed as the @oneField directive, the Tagged type has evolved into an entire new type in the type system, and is currently the lead proposal from the Input Unions Working Group.

A Tagged type defines a list of named member fields each with an associated type (like the fields in Object and Input Object types); but with the stipulation that exactly one of these fields must be present (no more, no less). Depending on the types of the member fields, a Tagged type could be appropriate for input, output, or both, which is proving to be quite controversial; it’s possible that the tagged type might be scoped to input only before release. The Tagged type was most recently introduced to the GraphQL Working Group in August and is undergoing feedback and revision before an expected update with the working group in October or November.

If you have use-cases for input polymorphism, please take a look - feedback is very welcome.

Standardize naming for Field coordinates

This PR proposes the following 2 RFCs

1. Formalizing the naming and definition of field coordinates (as discussed in #735)
2. Formalizing the way in which a Field Node (and list thereof) contained within a query document can be serialized as field coordinates

Adding generics to DocumentNode and Source to allow TypeScript type inference

@dotansimha from The Guild had recently implemented an improved version of DocumentNode, called TypedDocumentNode, that allows type generics for result type and variable type and contributed it to graphql-js.

This improved version allows TypeScript to infer the types automatically when an object that matches the signature is used.

You can learn more by reading about it on his blog post.

In Other News

• We recently welcomed the newest member of the GraphQL Foundation - The Guild. Here you can find the list of all current members of the foundation.
• @hereisnaman successfully finished his Google Summer of Code (GSoC) project and is in the process of merging hisPR. Learn more about it here.
• GraphQL was accepted to the Google Season of Docs (GSoD) and @carolstran will be working on the FAQ section of graphql.org
• GraphQL over HTTP was moved and is now under GraphQL Foundation
• @lilianammmatos and @robrichard have made big progress on . Yo can learn more by watching their talk about it at the GraphQL Summit:
• @andimarek and @eapache started the GraphQL Scalars initiative. You can also learn more by watching their talk about it at the GraphQL Summit.
• All WG recordings were published on YouTube.

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.

Naman Kumar is a Computer Science & Engineering student from New Delhi, India and a FullStack Engineer at ProductHunt. He is selected for Google Summer of Code 2020 - GraphQL Foundation under the mentorship of Ivan Goncharov. In this post he will share his plans on how he is going to spend his summer contributing to the Graphql Foundation.

Hi, GraphQL is a technology I use everyday at my work place and other projects building platforms with 200 to 2 million users. I am surely in love with it, acknowledging how much it improves the development speed and removes the overhead of documentation for starters.

I have huge respect for Open Source organisations and really inspired by the work the whole graphql community is doing to make lives of developers easier. I have always wanted to participating in GSOC, which I assure you is a dream of every student.

I got to know about the acceptance of Graphql Foundation under GSOC from Ivan’s talk at GraphQL Asia Submit 2020. I was really excited about having a chance to contribute to the tools which are used not only by me but are powering applications used by billions of people on the planet.

Having a keen interest in compiler design, the project idea of working on the graphql.js reference parser looked really interesting to me. Fortunately being selected for the program, I am going to spend the summer of 2020 working on Graphql.js reference parser and GraphiQL parser, to merge the two together. Graphql.js reference parser do not have streaming support or the best error recovery setup. The goal is to take inspiration from the GraphiQL parser and implement the streaming support in the reference parser so that it can be used by IDEs and other development tools.

I spent the community bonding period getting to know both the people in the graphql community and getting myself familiar with the projects. I explored the code base and solved few minor bugs with the help of Ivan. The graphql.js reference parser which is well maintained has a really good code quality and readability which helped me gain it's understanding really quickly, on the other hand the GraphiQL parser with just 1000 lines of pure “old is gold” code base, implemented 3 years ago, looks difficult to grasp at first but with proper understanding is a very simple and cute state machine.

Ivan and I also spent the time ideating about dividing the whole project into 3 milestones and breaking those into smaller goals. As the graphiql parser is not actively maintained and has zero test coverage it was really important to have the parser fully covered before we make any changes. Our goal was to enable the graphql.js parser be able to used by the IDEs and performance is a major factor we need to care about for that. Considering it, we also decided to do benchmarking of the GraphiQL parser. Ergo the first milestones includes reaching 100% test coverage for the GraphiQL parser and thorough benchmarking.

The next steps will be to use the graphql.js reference parser’s lexer in the GraphiQL parser and construct a plan to merge the parsers. Once the graphql.js parser reaches the capabilities as that of the GraphiQL parser, we can migrate the GraphiQL IDE to use graphql.js parser. Near to the completion of the first milestone I am really happy with the new thing I have learned under the mentorship of Ivan and really excited to work on the upcoming tasks.

– Naman Kumar, GSOC 2020, Graphql Foundation

announcements

Naman Kumar is a Computer Science & Engineering student from New Delhi, India and a FullStack Engineer at ProductHunt. He is selected for Google Summer of Code 2020 - GraphQL Foundation under the mentorship of Ivan Goncharov. In this post he will share his plans on how he is going to spend his summer contributing to the Graphql Foundation.

Hi, GraphQL is a technology I use everyday at my work place and other projects building platforms with 200 to 2 million users. I am surely in love with it, acknowledging how much it improves the development speed and removes the overhead of documentation for starters.

I have huge respect for Open Source organisations and really inspired by the work the whole graphql community is doing to make lives of developers easier. I have always wanted to participating in GSOC, which I assure you is a dream of every student.

I got to know about the acceptance of Graphql Foundation under GSOC from Ivan’s talk at GraphQL Asia Submit 2020. I was really excited about having a chance to contribute to the tools which are used not only by me but are powering applications used by billions of people on the planet.

Having a keen interest in compiler design, the project idea of working on the graphql.js reference parser looked really interesting to me. Fortunately being selected for the program, I am going to spend the summer of 2020 working on Graphql.js reference parser and GraphiQL parser, to merge the two together. Graphql.js reference parser do not have streaming support or the best error recovery setup. The goal is to take inspiration from the GraphiQL parser and implement the streaming support in the reference parser so that it can be used by IDEs and other development tools.

I spent the community bonding period getting to know both the people in the graphql community and getting myself familiar with the projects. I explored the code base and solved few minor bugs with the help of Ivan. The graphql.js reference parser which is well maintained has a really good code quality and readability which helped me gain it’s understanding really quickly, on the other hand the GraphiQL parser with just 1000 lines of pure “old is gold” code base, implemented 3 years ago, looks difficult to grasp at first but with proper understanding is a very simple and cute state machine.

Ivan and I also spent the time ideating about dividing the whole project into 3 milestones and breaking those into smaller goals. As the graphiql parser is not actively maintained and has zero test coverage it was really important to have the parser fully covered before we make any changes. Our goal was to enable the graphql.js parser be able to used by the IDEs and performance is a major factor we need to care about for that. Considering it, we also decided to do benchmarking of the GraphiQL parser. Ergo the first milestones includes reaching 100% test coverage for the GraphiQL parser and thorough benchmarking.

The next steps will be to use the graphql.js reference parser’s lexer in the GraphiQL parser and construct a plan to merge the parsers. Once the graphql.js parser reaches the capabilities as that of the GraphiQL parser, we can migrate the GraphiQL IDE to use graphql.js parser. Near to the completion of the first milestone I am really happy with the new thing I have learned under the mentorship of Ivan and really excited to work on the upcoming tasks.

– Naman Kumar, GSOC 2020, GraphQL Foundation

announcements

Open source communities are one of the best ways to collaborate with a larger scale of developers, it incorporates the best part of learning, mentorship, and collaboration on a large scale. Open-source software has been proven to create large effective ecosystems of users that improve quality. It has been known for many years that the more a piece of software is used, the quicker bugs will be identified. In the open-source community when a bug is found, users contribute fixes. GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data. GraphQL was developed internally by Facebook in 2012 before being publicly released in 2015.

What is Google Season of Docs?

The Google Season of Docs is the intersection of technical writing, open-source contribution, and mentorship. In this three month program, you will be working closely with maintainers of open source projects to improve on existing documentation and processes to better the community.

For technical writers who are new to open source, the program provides an opportunity to gain experience in contributing to open source projects.

For technical writers who’re already working in open source, the program provides a potentially new way of working together. Season of Docs also gives open source projects an opportunity to engage more of the technical writing community.

How can I be a part of this?

Open source organizations apply to be mentor organizations in the Season of Docs which includes a list of documentation project ideas with their applications. Technical writers can look through the list of proposals here are the project ideas for the GraphQL organization. When you have selected a project you would like to work on, write up a project proposal and submit it to Season of Docs. You may continue to refine your proposals until July 9th. If you need clarifications, please contact Ivan Goncharov and Uri Goldshtein by sending a message to mentorship@lists.foundation.graphql.org.

The GraphQL organization will reach out to you after they have evaluated the proposals. The accepted technical writers spend a few months working with mentors from the open-source organizations to complete their projects. At the end of the program, the Google program administrators announce the projects that finished successfully. Check out the official technical writer guide.

How long is this program?

The technical writing applications started on June 9th, 2020 and will last till July 9th, 2020. The selection process for the proposals submitted to organizations lasts till July 31st, 2020. Then Doc development officially begins September 14th, 2020, and ends December 5th, 2020. For a more detailed timeline check out the official season of docs timeline.

– Obinna Ekwuno, Software Engineer, DevRel GatsbyJS

GraphiQL's beginnings#

The initial public commit to GraphiQL was in 2014.

When Lee Byron, Hyo Jeong and Angel Gomez first published it, the intention was to create a minimal reference IDE development ecosystem for GraphQL. Greg Hurrell created the streaming graphql-language-service-parser, designed to empower the codemirror-graphql mode.

The goal was to give people the utility packages they needed to build their own web based or desktop IDE tool, and at its core, a relatively simple tool for folks to start learning and applying the language, and for exploring schemas. At the time, LSP was not yet a commonly accepted standard, and VSCode had yet to become the incredibly popular development tool it is today.

Last year, these original engineers handed over to the graphql foundation three repositories: GraphiQL, codemirror-graphql and the graphql-language-service packages.

Fast forward to now, and GraphiQL is now used by GraphQL implementations in dozens of languages, as well as hundreds of frameworks and runtimes. It's used for everything from HTTP operations, to querying local schemas, data science tools, and even for data transmission for IOT platforms. You'll find it in the AWS dashboard, GitHub developer tools, and many more places we are honored to see this library used.

Enter Playground#

Alongside GraphiQL, many of us are familiar with its sibling - the handsome & feature-full GraphQL Playground. Following GraphiQL's lead, it uses our codemirror-graphql (Insomnia, Altair and many others are also in this club!). This is why there are so many similarities between the direct editing experience of these tools.

Playground is exactly what we wanted to happen. It helped drive the development of our language ecosystem, and gave users an easier option than the more customization-oriented GraphiQL. It provided a ton of excellent features - graphql-config support, multiple tabs, i18n, and http server middlewares.

Prisma Donates Playground to GraphQL Foundation#

As many have successfully guessed, Prisma is donating Playground to the GraphQL Foundation. Entering 2019 Prisma envisioned an eventual Playground 2.0 but then the advent of a modular GraphiQL 2 project showed an opportunity for great synergy, made all the more natural by Prisma's pivot toward modular database tooling for developers.

Playground 1.x has been a community effort of dozens of contributors. Prisma thanks all contributors who helped out along the way. Prisma remains deeply committed to supporting the future of the GraphQL language. For example the Prisma Labs team continues to focus on GraphQL API layer and recently announced the transition of Nexus from a schema building library into a full fledged GraphQL API framework.

The Playground Features you love#

In the interest of parity, we will keep a lot of the same features, whether by introducing them to the core or proving plugins that will ship with the playground preset.

• multiple tabs (GraphiQL Core)
• headers tab per operation tab (plugin)
• tracing tab (plugin)
• playground doc explorer (plugin)
• internationalization (GraphiQL Core)
• graphql-config support, with new features thanks to our fantastic colleagues at the Guild Dev, who Prisma has entrusted with many other projects.
• easy to use middlewares

New Features#

These new features will come with the new graphql@2.0.0:

• vscode style command palette (via monaco-editor)
• jump to fragment or other type definitions
• generate a collection of operations from your project's source files
• more customizable network options - default headers per project, as well as headers per-operation
• helpers for integrating custom authentication flows
• extensive theme, layout, and component customization abilities (you can start with the playground theme preset and work from there!)
• custom tabs and panels
• a first-class graphiql-explorer plugin in partnership with the original creators, our colleagues at OneGraph

How will it be re-implemented?#

Playground 2.0 will be a GraphiQL preset that includes the custom theme as well as the custom playground doc explorer plugin (as an alternative to the new doc explorer proposed by @orta and other users), HTTP headers and tracing tab plugins. You can find more technical detail, ongoing discussion and things to work on the GraphiQL Plugin API Meta Issue or in other playground related discussion issues in the GraphiQL monorepo.

While the Playground team's baseline goal will be relative parity with Playground 1.0, the team will be accepting proposals for new features and plugins that build on the existing GraphQL Playground experience. The Features Roundup project is a great place to see what we have planned already for plugins that Playground's preset can use, or you can also create a proposal if you don't see what you're looking for.

graphql-playground repository next steps#

The existing graphql-playground repository will get one or two more maintenance/bugfix releases before it will be archived. You can still fork it of course. You can learn more about this in the graphql-playground issue we created for this migration.

Call for Contributors#

We're also looking for contributors to form a team to develop, support and maintain a playground preset. The goal would be for them to help iterate on and stabilize the plugin API effort, as well as work towards the effort of contributing to and maintaining the playground preset and its associated plugins. If you are interested leave comment in the Call for Contributors Github issue.

You can also follow the Plugin API Proposal discussion issue for updates, and get involved in our discord channel we've created just for the playground initiative.

announcements

GraphiQL’s beginnings

The initial public commit to GraphiQL was in 2014.

When Lee Byron, Hyo Jeong and Angel Gomez first published it, the intention was to create a minimal reference IDE development ecosystem for GraphQL. Greg Hurrell created the streaming , designed to empower the mode.

The goal was to give people the utility packages they needed to build their own web based or desktop IDE tool, and at its core, a relatively simple tool for folks to start learning and applying the language, and for exploring schemas. At the time, LSP was not yet a commonly accepted standard, and VSCode had yet to become the incredibly popular development tool it is today.

Last year, these original engineers handed over to the graphql foundation three repositories: GraphiQL, and the packages.

Fast forward to now, and GraphiQL is now used by GraphQL implementations in dozens of languages, as well as hundreds of frameworks and runtimes. It’s used for everything from HTTP operations, to querying local schemas, data science tools, and even for data transmission for IOT platforms. You’ll find it in the AWS dashboard, GitHub developer tools, and many more places we are honored to see this library used.

Enter Playground

Alongside GraphiQL, many of us are familiar with its sibling - the handsome & feature-full GraphQL Playground. Following GraphiQL’s lead, it uses our (Insomnia, Altair and many others are also in this club!). This is why there are so many similarities between the direct editing experience of these tools.

Playground is exactly what we wanted to happen. It helped drive the development of our language ecosystem, and gave users an easier option than the more customization-oriented GraphiQL. It provided a ton of excellent features - support, multiple tabs, i18n, and http server middlewares.

Prisma Donates Playground to GraphQL Foundation

As many have successfully guessed, Prisma is donating Playground to the GraphQL Foundation. Entering 2019 Prisma envisioned an eventual Playground 2.0 but then the advent of a modular GraphiQL 2 project showed an opportunity for great synergy, made all the more natural by Prisma’s pivot toward modular database tooling for developers.

Playground 1.x has been a community effort of dozens of contributors. Prisma thanks all contributors who helped out along the way. Prisma remains deeply committed to supporting the future of the GraphQL language. For example the Prisma Labs team continues to focus on GraphQL API layer and recently announced the transition of Nexus from a schema building library into a full fledged GraphQL API framework.

The Playground Features you love

In the interest of parity, we will keep a lot of the same features, whether by introducing them to the core or proving plugins that will ship with the playground preset.

• multiple tabs (GraphiQL Core)
• headers tab per operation tab (plugin)
• tracing tab (plugin)
• playground doc explorer (plugin)
• internationalization (GraphiQL Core)
• support, with new features thanks to our fantastic colleagues at the Guild Dev, who Prisma has entrusted with many other projects.
• easy to use middlewares

New Features

These new features will come with the new :

• vscode style command palette (via )
• jump to fragment or other type definitions
• generate a collection of operations from your project’s source files
• more customizable network options - default headers per project, as well as headers per-operation
• helpers for integrating custom authentication flows
• extensive theme, layout, and component customization abilities (you can start with the playground theme preset and work from there!)
• custom tabs and panels
• a first-class plugin in partnership with the original creators, our colleagues at OneGraph

How will it be re-implemented?

Playground 2.0 will be a GraphiQL preset that includes the custom theme as well as the custom playground doc explorer plugin (as an alternative to the new doc explorer proposed by @orta and other users), HTTP headers and tracing tab plugins. You can find more technical detail, ongoing discussion and things to work on the GraphiQL Plugin API Meta Issue or in other playground related discussion issues in the GraphiQL monorepo.

While the Playground team’s baseline goal will be relative parity with Playground 1.0, the team will be accepting proposals for new features and plugins that build on the existing GraphQL Playground experience. The Features Roundup project is a great place to see what we have planned already for plugins that Playground’s preset can use, or you can also create a proposal if you don’t see what you’re looking for.

repository next steps

The existing repository will get one or two more maintenance/bugfix releases before it will be archived. You can still fork it of course. You can learn more about this in the graphql-playground issue we created for this migration.

Call for Contributors

We’re also looking for contributors to form a team to develop, support and maintain a playground preset. The goal would be for them to help iterate on and stabilize the plugin API effort, as well as work towards the effort of contributing to and maintaining the playground preset and its associated plugins. If you are interested leave comment in the Call for Contributors Github issue.

You can also follow the Plugin API Proposal discussion issue for updates, and get involved in our discord channel we’ve created just for the playground initiative.

The annual report details the accomplishments of the organization in its first year, along with a forward looking statement for 2020 and beyond from Lee Byron, the GraphQL Foundation Executive Director:

The annual report details the accomplishments of the organization in its first year, along with a forward looking statement for 2020 and beyond from Lee Byron, the GraphQL Foundation Executive Director:

GraphQL is revolutionizing the way developers are building APIs for web, mobile and even databases. But what exactly is GraphQL? GraphQL is an open source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data.

This course explains what GraphQL is and why it is getting so much attention from software engineers. It covers the advantages over REST, what types of software architectures to use it with, and why it benefits both frontend and backend developers. The student practices GraphQL queries in an interactive playground, and learns advanced topics such as how to implement a GraphQL server on the backend, how to use a GraphQL server with a client, and how to keep the GraphQL server secure. The course content was originally created by Prisma, and updated and maintained by Novvum.

"Since open sourcing GraphQL, I have been blown away by the growth of the technology and community. I'm excited to see the introduction of more educational material which I hope will help our community continue to grow and reach developers world-wide." – Lee Byron, Executive Director, GraphQL Foundation, and GraphQL Co-Creator

This course will help programmers gain the skills needed to use GraphQL for a small project or professionally in production. They will feel comfortable getting started with the right tools for their use case.

For the nontechnical person, this course will help them improve communication with developers and to participate in conversations about GraphQL. They will understand when and why to use GraphQL for a project.

Exploring GraphQL: A Query Language for APIs is available at no cost, with content access for up to 7 weeks. Learners may upgrade to the verified track for $99, which includes all graded assessments, unlimited access to the course content and the ability to earn a Verified Certificate upon passing the course.

About The Linux Foundation#

The Linux Foundation is the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and industry adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found at www.linuxfoundation.org.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage.

Linux is a registered trademark of Linus Torvalds.

# # #

Media Contact:#

Clyde Seepersad
The Linux Foundation
404-964-6973
cseepersad@linuxfoundation.org

announcements

The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today announced enrollment is now open for a new, free, course – Exploring GraphQL: A Query Language for APIs. This course is offered through edX, the trusted platform for learning.

GraphQL is revolutionizing the way developers are building APIs for web, mobile and even databases. But what exactly is GraphQL? GraphQL is an open source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data.

This course explains what GraphQL is and why it is getting so much attention from software engineers. It covers the advantages over REST, what types of software architectures to use it with, and why it benefits both frontend and backend developers. The student practices GraphQL queries in an interactive playground, and learns advanced topics such as how to implement a GraphQL server on the backend, how to use a GraphQL server with a client, and how to keep the GraphQL server secure. The course content was originally created by Prisma, and updated and maintained by Novvum.

”Since open sourcing GraphQL, I have been blown away by the growth of the technology and community. I’m excited to see the introduction of more educational material which I hope will help our community continue to grow and reach developers world-wide.” – Lee Byron, Executive Director, GraphQL Foundation, and GraphQL Co-Creator

This course will help programmers gain the skills needed to use GraphQL for a small project or professionally in production. They will feel comfortable getting started with the right tools for their use case.

For the nontechnical person, this course will help them improve communication with developers and to participate in conversations about GraphQL. They will understand when and why to use GraphQL for a project.

Exploring GraphQL: A Query Language for APIs is available at no cost, with content access for up to 7 weeks. Learners may upgrade to the verified track for $99, which includes all graded assessments, unlimited access to the course content and the ability to earn a Verified Certificate upon passing the course.

About The Linux Foundation

The Linux Foundation is the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and industry adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found at https://linuxfoundation.org.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://linuxfoundation.org/trademark-usage.

Linux is a registered trademark of Linus Torvalds.

Media Contact

The GraphQL Landscape is a dynamically generated tool designed to help explore the burgeoning GraphQL community of projects, adopters and member organizations. Currently, it is comprised of 100+ cards representing a market cap of more than $3.4T.

"When we first created GraphQL, we set out to make product development easier with APIs driven by the needs of mobile and app developers and dramatic simplifications of how APIs are built and maintained," said Lee Byron, Director of the GraphQL Foundation. "I'm thrilled to see this influx of multi-industry support for GraphQL and a commitment to increase developer productivity, showcased throughout the impressive and growing landscape."

"I'm thrilled to help launch the GraphQL Foundation's first landscape, displaying GraphQL's vast range of projects, adopters and members," said Chris Aniszczyk, VP of Developer Relations and CTO of CNCF at the Linux Foundation. "This interactive resource has been a labor of love from and for our community, and I look forward to watching it grow into the same standard for real-time ecosystem information that the CNCF Landscape has been for the cloud native space."

GraphQL is a next­-generation API technology developed internally by Facebook in 2012 before being publicly open sourced in 2015. Unlike REST-­based APIs, which take advantage of HTTP and existing protocols, GraphQL APIs provide developers with the flexibility to query the exact data they need from a diverse set of cloud data sources, with less code, greater performance and security, and a faster development cycle. Not only does this enable developers to rapidly build top­ quality apps, it also helps them achieve consistency and feature parity across multiple platforms such as web, iOS, Android, and embedded and IoT applications.

Brian Warner of The Linux Foundation has joined the GraphQL Foundation as its Program Director, helping to support the growing community and the project's ongoing needs. "I look forward to working with Lee and the governing board to establish the infrastructure and support needed to ensure the health and sustainability of the vibrant GraphQL community."

GraphQL is being used in production by a variety of high scale companies such as Airbnb, Atlassian, Audi, CNBC, GitHub, Major League Soccer, Netflix, Shopify, The New York Times, Twitter, Pinterest and Yelp. GraphQL also powers hundreds of billions of API calls a day at Facebook.

Member Quotes#

"Open source specifications rely on strong collaboration and proper stewardship. 8base loves GraphQL and we joined the GraphQL Foundation to be involved in the specification's future with other leading-edge technology companies. Our hope is that, with our involvement, the surrounding ecosystem continues to flourish at an accelerated pace." - Albert Santalo, CEO & Founder, 8base

"It's truly surreal to see GraphQL grow from its conception to spread throughout the entire technology industry. The Foundation provides the infrastructure to make this a true industry standard, backed by stable, trusted, company-neutral governance." - Nick Schrock, Founder, Elementl

"At Expedia Group, GraphQL is helping us build better experiences for our travelers. As a rapidly adopted technology in software development, we believe an open and community supported GraphQL specification and ecosystem is critical to its continued success." - Trevor Livingston, Principal Architect, Expedia Group (VRBO)

"At Fauna, we have seen first-hand the productivity and architectural benefits GraphQL offers developers. We believe that an open ecosystem and shared specification are a benefit to all. We're excited to contribute to the GraphQL community and collaborate on its continued innovation." - Matt Freels, CTO, Fauna, Inc.

"We are thrilled to be a part of the GraphQL Foundation. We see GraphQL as one of the most important emerging API technologies and strongly believe in its bright future! We're excited to continue investing in the GraphQL ecosystem and community with tools, events and educational content." - Johannes Schickling, CEO, Prisma

"We're deliberate about the technology we build and adopt. That's why we're excited to double-down on our investment in GraphQL as a foundational technology at Shopify. We believe GraphQL provides great tools for our internal teams and app developers to extend our platform and create faster merchant experiences." - Jean-Michel Lemieux, CTO, Shopify

"GraphQL plays a key part in helping us serve the public conversation on Twitter by enabling faster product iteration across our teams. As GraphQL is gaining tremendous adoption as one of the best protocols for remote retrieval of large object graphs, we are very excited to support the GraphQL Foundation." - Anna Sulkina Engineering Director, Core Services Group, Twitter

About the GraphQL Foundation#

The GraphQL Foundation is an open, neutral organization that provides oversight of funding, operations, and marketing resources for the GraphQL community to enable widespread adoption and help accelerate development of the broader ecosystem. The GraphQL specification, GraphQL.js reference implementation, DataLoader library, and GraphiQL developer tool are technical projects supported by the GraphQL Foundation. More details can be found at https://foundation.graphql.org.

About The Linux Foundation#

The Linux Foundation is the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and industry adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found at www.linuxfoundation.org.

# # #

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

announcements

The GraphQL Foundation, a neutral home for the GraphQL community to accelerate development of the surrounding ecosystem, today announced seven new members to support the Foundation’s efforts, along with the launch of the GraphQL Landscape.

The GraphQL Landscape is a dynamically generated tool designed to help explore the burgeoning GraphQL community of projects, adopters and member organizations. Currently, it is comprised of 100+ cards representing a market cap of more than $3.4T.

”When we first created GraphQL, we set out to make product development easier with APIs driven by the needs of mobile and app developers and dramatic simplifications of how APIs are built and maintained,” said Lee Byron, Director of the GraphQL Foundation. “I’m thrilled to see this influx of multi-industry support for GraphQL and a commitment to increase developer productivity, showcased throughout the impressive and growing landscape."

"I’m thrilled to help launch the GraphQL Foundation’s first landscape, displaying GraphQL’s vast range of projects, adopters and members,” said Chris Aniszczyk, VP of Developer Relations and CTO of CNCF at the Linux Foundation. “This interactive resource has been a labor of love from and for our community, and I look forward to watching it grow into the same standard for real-time ecosystem information that the CNCF Landscape has been for the cloud native space.”

GraphQL is a next­-generation API technology developed internally by Facebook in 2012 before being publicly open sourced in 2015. Unlike REST-­based APIs, which take advantage of HTTP and existing protocols, GraphQL APIs provide developers with the flexibility to query the exact data they need from a diverse set of cloud data sources, with less code, greater performance and security, and a faster development cycle. Not only does this enable developers to rapidly build top­ quality apps, it also helps them achieve consistency and feature parity across multiple platforms such as web, iOS, Android, and embedded and IoT applications.

Brian Warner of The Linux Foundation has joined the GraphQL Foundation as its Program Director, helping to support the growing community and the project’s ongoing needs. “I look forward to working with Lee and the governing board to establish the infrastructure and support needed to ensure the health and sustainability of the vibrant GraphQL community.”

GraphQL is being used in production by a variety of high scale companies such as Airbnb, Atlassian, Audi, CNBC, GitHub, Major League Soccer, Netflix, Shopify, The New York Times, Twitter, Pinterest and Yelp. GraphQL also powers hundreds of billions of API calls a day at Facebook.

Member Quotes

”Open source specifications rely on strong collaboration and proper stewardship. 8base loves GraphQL and we joined the GraphQL Foundation to be involved in the specification’s future with other leading-edge technology companies. Our hope is that, with our involvement, the surrounding ecosystem continues to flourish at an accelerated pace.” - Albert Santalo, CEO & Founder, 8base

”It’s truly surreal to see GraphQL grow from its conception to spread throughout the entire technology industry. The Foundation provides the infrastructure to make this a true industry standard, backed by stable, trusted, company-neutral governance.” - Nick Schrock, Founder, Elementl

”At Expedia Group, GraphQL is helping us build better experiences for our travelers. As a rapidly adopted technology in software development, we believe an open and community supported GraphQL specification and ecosystem is critical to its continued success.” - Trevor Livingston, Principal Architect, Expedia Group (VRBO)

“At Fauna, we have seen first-hand the productivity and architectural benefits GraphQL offers developers. We believe that an open ecosystem and shared specification are a benefit to all. We’re excited to contribute to the GraphQL community and collaborate on its continued innovation.” - Matt Freels, CTO, Fauna, Inc.

”We are thrilled to be a part of the GraphQL Foundation. We see GraphQL as one of the most important emerging API technologies and strongly believe in its bright future! We’re excited to continue investing in the GraphQL ecosystem and community with tools, events and educational content.” - Johannes Schickling, CEO, Prisma

”We’re deliberate about the technology we build and adopt. That’s why we’re excited to double-down on our investment in GraphQL as a foundational technology at Shopify. We believe GraphQL provides great tools for our internal teams and app developers to extend our platform and create faster merchant experiences.” - Jean-Michel Lemieux, CTO, Shopify

”GraphQL plays a key part in helping us serve the public conversation on Twitter by enabling faster product iteration across our teams. As GraphQL is gaining tremendous adoption as one of the best protocols for remote retrieval of large object graphs, we are very excited to support the GraphQL Foundation.” - Anna Sulkina Engineering Director, Core Services Group, Twitter

About the GraphQL Foundation

The GraphQL Foundation is an open, neutral organization that provides oversight of funding, operations, and marketing resources for the GraphQL community to enable widespread adoption and help accelerate development of the broader ecosystem. The GraphQL specification, GraphQL.js reference implementation, DataLoader library, and GraphiQL developer tool are technical projects supported by the GraphQL Foundation. More details can be found at https://foundation.graphql.org.

About The Linux Foundation

The Linux Foundation is the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and industry adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found at www.linuxfoundation.org.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

GraphQL Foundation encourages contributions, stewardship, and a shared investment from a broad group in vendor-neutral events, documentation, tools, and support for the data query language. The following companies Apollo, AWS, Butterfly Network, Dgraph Labs, Facebook, Gatsby, GraphZen, Hasura, IBM, Intuit, Neo4j, Novvum, Pipefy, Salsify, Solo.io and Thicit are joining as members to advance GraphQL as an industry specification for designing more effective APIs.

GraphQL powers hundreds of billions of API calls a day at Facebook, which developed the technology in 2012 and played an integral role in helping GraphQL join the Linux Foundation last year. Today, virtually every major programming language offers GraphQL support through a variety of open source software libraries.

GraphQL is the first Linux Foundation project to benefit from the JDF and Linux Foundation collaboration, which provides open source projects with a swift path to standardization for open specifications. Developers will have an open GraphQL specification and open source software implementations available for designing conformant APIs.

“We are excited to formally welcome new members and to work closely with them to build out and support a global GraphQL ecosystem. We’re pleased that the GraphQL specification will continue to evolve through the JDF and Linux Foundation partnership. With an easier and faster way to create and advance standards, developers can concentrate on creating applications that make a bigger impact on communities around the world,” said Lee Byron, co-creator of GraphQL.

GraphQL is important for API development as it allows nested objects in a single API request that traditionally would require multiple API requests. The GraphQL specification, GraphQL.js reference implementation, DataLoader library, and GraphiQL developer tool are technical projects supported by the GraphQL Foundation. As application development shifts toward microservices architectures with an emphasis on flexibility and speed to market, tools like GraphQL are redefining API design and client-server interaction to improve the developer experience, increasing developer productivity and minimizing amounts of data transferred. GraphQL makes cross-platform and mobile development simpler with availability in multiple programming languages that are consistent and feature parity across multiple platforms such as web, iOS, Android, and embedded and IoT applications.

The Linux Foundation and the Facebook Open Source team leveraged the JDF’s proven framework to create a lightweight governance structure for specifications — allowing communities to quickly spin-up neutral collaborations.

“We’re thrilled to see GraphQL and the Joint Development Foundation join forces and get to work so quickly to advance open standards,” said Jim Zemlin, executive director of the Linux Foundation. “Working with the JDF, the GraphQL community is able to leverage turnkey infrastructure to create and manage open standards more quickly and nimbly than ever before. This allows developers to continue to break barriers and modernize application development.”

“We are very pleased to have worked closely with the Linux Foundation in creating this novel approach to specification-based collaborations,” said Michael Cheng from the Facebook Open Source team. “By offering open source communities a streamlined path to standardization and nurturing open source implementations, this strategic alignment benefits GraphQL developers, corporate contributors and end users who need both outcomes to succeed.”

“We look forward to working closely with the GraphQL Foundation and we expect many other Linux Foundation projects to work with us this year to accelerate specifications and standards development to advance their mission and drive the creation of innovative technology, ” said David Rudin, president of the Joint Development Foundation.

“Given GraphQL’s centrality in the modern app development stack, the foundation we’re launching today is not just necessary, but overdue. As the creators of Apollo, the most widely used implementation of GraphQL, we’re looking forward to working together with the Linux Foundation to define appropriate governance processes and accelerate the adoption of this critical Internet standard.” — Geoff Schmidt, CEO and Co-Founder, Apollo

“GraphQL is a foundational technology for building APIs that empower frontend developers to deliver the best user experience for their customers. With AWS AppSync and the Amplify Framework, AWS is enabling developers to build and run critical GraphQL workloads at scale, and we are excited to join the Foundation to support and grow the GraphQL community.” — Adrian Cockcroft, Vice President of Cloud Architecture Strategy, AWS

“GraphQL has been invaluable to Butterfly Network in advancing our mission of democratizing medical imaging. It’s enabled us to build data-efficient APIs to serve healthcare providers in areas with limited broadband internet access, while preserving our ability to quickly develop new API functionality. GraphQL has played a key role in allowing our back end and front end teams to work together with a minimum of friction. We’re excited to support the GraphQL Foundation in its work to further shepherd the standard.” — Jimmy Jia, Principal Scientist, Butterfly Network

“Dgraph started just a few months after a draft GraphQL spec was released in mid-2015. Unsatisfied with existing graph languages, we decided to bet the future of our distributed graph database on GraphQL. Dgraph is now the only database to natively support a language very close to GraphQL. Considering how easy and intuitive it is for our users, it has been the best decision we made. So, we stand proud with the GraphQL Foundation to help build the next generation of apps on graphs.” – Manish R. Jain, CEO, Dgraph Labs

“Our goal at Gastby is to provide the best platform for building fast, compelling websites. We use GraphQL to provide a flexible data layer that can be used with different sources. We welcome the establishment of the GraphQL Specification Project and are very excited to be part of it.” — Mikhail Novikov, Software Developer, Gatsby Inc.

“GraphZen strives to deliver a fantastic developer experience for C# developers building GraphQL APIs and to provide the support and training needed by enterprises to realize the benefits of GraphQL. GraphZen is excited to join the GraphQL Foundation and steward the GraphQL specification in a way that continues to drive innovation and adoption through open standards.” — Craig Smitham, Creator & Founder, GraphZen

“The GraphQL technology and community is spearheading a much required shift in the API experience for the modern web, especially as applications are becoming more ‘frontend’ heavy. At Hasura, we’re extremely excited about the potential of GraphQL to evolve the way teams organize their codebases, and communicate with each other; especially in relation to the ongoing serverless movement. There could not be a better home for GraphQL projects and events than the GraphQL Foundation, and we are proud to do our bit to help make the technology and community around GraphQL sustainable and open.” — Tanmai Gopal, CEO, Hasura

“IBM has continued to be an industry leader, helping clients keep pace with the rapidly evolving API technologies landscape. We are pleased to join the new GraphQL Foundation as a founding member to help drive greater open source innovation and adoption of this important data access language and runtime for APIs.” – Juan Carlos Soto, VP Hybrid Cloud Integration and API Economy, IBM

“Intuit began using GraphQL shortly after it arrived in open source. We have developed a complex schema with over 600 core objects, 1,600 types and thousands of connections between objects. We’ve made major contributions to the open source GraphQL Java library. We look forward to participating in the GraphQL Foundation to advance its capabilities and more directly participate in the thriving community.” — Jeff Brewer, Vice President, Chief Architect, Small Business and Self-Employed Group, Intuit

“Neo4j is pleased to support GraphQL, due to its unique ability to enable front-end developers, API developers and data architects to all work with the same graph-based data model. Our GraphQL integration and GRANDstack have already helped thousands of developers build graph applications with Neo4j, thanks to the huge developer productivity gain of GraphQL and the graph thinking mindset it brings for both developers and API consumers. The GraphQL Foundation is an important step to cement today’s most relevant standard for building APIs and we’re honored to join as founding members to help steward GraphQL as the ecosystem continues to evolve.” — Emil Eifrem, CEO and Co-Founder, Neo4j

“We are grateful that Novvum has grown alongside GraphQL and its community over the past four years. We couldn’t be more excited about the future of GraphQL, and look forward to working with the Linux Foundation and GraphQL Foundation to improve the quality and experience of API development for engineers.” — Raj Singh, CEO and Co-Founder, Novvum

“At Pipefy we are building the lean management platform. Since the beginning, GraphQL has enabled our developers to deliver new features and services more efficiently and with better communication from front-end and back-end teams. After we started using it internally, we decided to build our public API using GraphQL, a choice that enabled us to deliver a better developer experience to the developers who are building on top of our platform. We are excited to contribute to the GraphQL ecosystem and support the GraphQL Foundation.” — Raphael Costa, Head of Platform, Pipefy

“Salsify provides a data platform that enables the world’s largest brands to deliver compelling product experiences across the retail ecosystem. Our GraphQL powered APIs enable us to support a diverse set of use cases with great developer ergonomics and excellent performance. We look forward to working with the GraphQL Foundation to support the continued evolution of GraphQL.” — Joel Turkel, Chief Software Architect, Salsify

“Solo.io’s mission is to empower enterprise organizations rapidly adopt innovative technology and extend their existing investments. GraphQL is a powerful way to help “glue” monolith, microservices, and serverless applications with a unified API. Our open-source project, Sqoop, leverages GraphQL and other innovative projects like Envoy to streamline the developer experience, and simply glue together environments without writing a single line of code. We are excited to join the GraphQL Foundation and look forward to working within the GraphQL community” — Idit Levine, CEO & Founder, Solo.io

“GraphQL, and alongside its tooling, has grown to proof its worth and is here to stay. Time for a power-up supported by many hands and brains through the Joint Development Foundation and Linux Foundation. GraphQL is the glue that keeps your domain data in context, understandable, and always ready to empower the next ideas. Looking forward to new and improved power’s, to evolution.” — Tim Govers, CEO, Thicit

announcements

The GraphQL Foundation, a neutral home for the GraphQL community to accelerate development of the surrounding ecosystem, today announces it is collaborating with the Joint Development Foundation (JDF), which recently joined the Linux Foundation to drive adoption of open source and standards, to continue developing the GraphQL specification.

GraphQL Foundation encourages contributions, stewardship, and a shared investment from a broad group in vendor-neutral events, documentation, tools, and support for the data query language. The following companies Apollo, AWS, Butterfly Network, Dgraph Labs, Facebook, Gatsby, GraphZen, Hasura, IBM, Intuit, Neo4j, Novvum, Pipefy, Salsify, Solo.io and Thicit are joining as members to advance GraphQL as an industry specification for designing more effective APIs.

GraphQL powers hundreds of billions of API calls a day at Facebook, which developed the technology in 2012 and played an integral role in helping GraphQL join the Linux Foundation last year. Today, virtually every major programming language offers GraphQL support through a variety of open source software libraries.

GraphQL is the first Linux Foundation project to benefit from the JDF and Linux Foundation collaboration, which provides open source projects with a swift path to standardization for open specifications. Developers will have an open GraphQL specification and open source software implementations available for designing conformant APIs.

“We are excited to formally welcome new members and to work closely with them to build out and support a global GraphQL ecosystem. We’re pleased that the GraphQL specification will continue to evolve through the JDF and Linux Foundation partnership. With an easier and faster way to create and advance standards, developers can concentrate on creating applications that make a bigger impact on communities around the world,” said Lee Byron, co-creator of GraphQL.

GraphQL is important for API development as it allows nested objects in a single API request that traditionally would require multiple API requests. The GraphQL specification, GraphQL.js reference implementation, DataLoader library, and GraphiQL developer tool are technical projects supported by the GraphQL Foundation. As application development shifts toward microservices architectures with an emphasis on flexibility and speed to market, tools like GraphQL are redefining API design and client-server interaction to improve the developer experience, increasing developer productivity and minimizing amounts of data transferred. GraphQL makes cross-platform and mobile development simpler with availability in multiple programming languages that are consistent and feature parity across multiple platforms such as web, iOS, Android, and embedded and IoT applications.

The Linux Foundation and the Facebook Open Source team leveraged the JDF’s proven framework to create a lightweight governance structure for specifications — allowing communities to quickly spin-up neutral collaborations.

“We’re thrilled to see GraphQL and the Joint Development Foundation join forces and get to work so quickly to advance open standards,” said Jim Zemlin, executive director of the Linux Foundation. “Working with the JDF, the GraphQL community is able to leverage turnkey infrastructure to create and manage open standards more quickly and nimbly than ever before. This allows developers to continue to break barriers and modernize application development.”

“We are very pleased to have worked closely with the Linux Foundation in creating this novel approach to specification-based collaborations,” said Michael Cheng from the Facebook Open Source team. “By offering open source communities a streamlined path to standardization and nurturing open source implementations, this strategic alignment benefits GraphQL developers, corporate contributors and end users who need both outcomes to succeed.”

“We look forward to working closely with the GraphQL Foundation and we expect many other Linux Foundation projects to work with us this year to accelerate specifications and standards development to advance their mission and drive the creation of innovative technology, ” said David Rudin, president of the Joint Development Foundation.

“Given GraphQL’s centrality in the modern app development stack, the foundation we’re launching today is not just necessary, but overdue. As the creators of Apollo, the most widely used implementation of GraphQL, we’re looking forward to working together with the Linux Foundation to define appropriate governance processes and accelerate the adoption of this critical Internet standard.” — Geoff Schmidt, CEO and Co-Founder, Apollo

“GraphQL is a foundational technology for building APIs that empower frontend developers to deliver the best user experience for their customers. With AWS AppSync and the Amplify Framework, AWS is enabling developers to build and run critical GraphQL workloads at scale, and we are excited to join the Foundation to support and grow the GraphQL community.” — Adrian Cockcroft, Vice President of Cloud Architecture Strategy, AWS

“GraphQL has been invaluable to Butterfly Network in advancing our mission of democratizing medical imaging. It’s enabled us to build data-efficient APIs to serve healthcare providers in areas with limited broadband internet access, while preserving our ability to quickly develop new API functionality. GraphQL has played a key role in allowing our back end and front end teams to work together with a minimum of friction. We’re excited to support the GraphQL Foundation in its work to further shepherd the standard.” — Jimmy Jia, Principal Scientist, Butterfly Network

“Dgraph started just a few months after a draft GraphQL spec was released in mid-2015. Unsatisfied with existing graph languages, we decided to bet the future of our distributed graph database on GraphQL. Dgraph is now the only database to natively support a language very close to GraphQL. Considering how easy and intuitive it is for our users, it has been the best decision we made. So, we stand proud with the GraphQL Foundation to help build the next generation of apps on graphs.” – Manish R. Jain, CEO, Dgraph Labs

“Our goal at Gastby is to provide the best platform for building fast, compelling websites. We use GraphQL to provide a flexible data layer that can be used with different sources. We welcome the establishment of the GraphQL Specification Project and are very excited to be part of it.” — Mikhail Novikov, Software Developer, Gatsby Inc.

“GraphZen strives to deliver a fantastic developer experience for C# developers building GraphQL APIs and to provide the support and training needed by enterprises to realize the benefits of GraphQL. GraphZen is excited to join the GraphQL Foundation and steward the GraphQL specification in a way that continues to drive innovation and adoption through open standards.” — Craig Smitham, Creator & Founder, GraphZen

“The GraphQL technology and community is spearheading a much required shift in the API experience for the modern web, especially as applications are becoming more ‘frontend’ heavy. At Hasura, we’re extremely excited about the potential of GraphQL to evolve the way teams organize their codebases, and communicate with each other; especially in relation to the ongoing serverless movement. There could not be a better home for GraphQL projects and events than the GraphQL Foundation, and we are proud to do our bit to help make the technology and community around GraphQL sustainable and open.” — Tanmai Gopal, CEO, Hasura

“IBM has continued to be an industry leader, helping clients keep pace with the rapidly evolving API technologies landscape. We are pleased to join the new GraphQL Foundation as a founding member to help drive greater open source innovation and adoption of this important data access language and runtime for APIs.” – Juan Carlos Soto, VP Hybrid Cloud Integration and API Economy, IBM

“Intuit began using GraphQL shortly after it arrived in open source. We have developed a complex schema with over 600 core objects, 1,600 types and thousands of connections between objects. We’ve made major contributions to the open source GraphQL Java library. We look forward to participating in the GraphQL Foundation to advance its capabilities and more directly participate in the thriving community.” — Jeff Brewer, Vice President, Chief Architect, Small Business and Self-Employed Group, Intuit

“Neo4j is pleased to support GraphQL, due to its unique ability to enable front-end developers, API developers and data architects to all work with the same graph-based data model. Our GraphQL integration and GRANDstack have already helped thousands of developers build graph applications with Neo4j, thanks to the huge developer productivity gain of GraphQL and the graph thinking mindset it brings for both developers and API consumers. The GraphQL Foundation is an important step to cement today’s most relevant standard for building APIs and we’re honored to join as founding members to help steward GraphQL as the ecosystem continues to evolve.” — Emil Eifrem, CEO and Co-Founder, Neo4j

“We are grateful that Novvum has grown alongside GraphQL and its community over the past four years. We couldn’t be more excited about the future of GraphQL, and look forward to working with the Linux Foundation and GraphQL Foundation to improve the quality and experience of API development for engineers.” — Raj Singh, CEO and Co-Founder, Novvum

“At Pipefy we are building the lean management platform. Since the beginning, GraphQL has enabled our developers to deliver new features and services more efficiently and with better communication from front-end and back-end teams. After we started using it internally, we decided to build our public API using GraphQL, a choice that enabled us to deliver a better developer experience to the developers who are building on top of our platform. We are excited to contribute to the GraphQL ecosystem and support the GraphQL Foundation.” — Raphael Costa, Head of Platform, Pipefy

“Salsify provides a data platform that enables the world’s largest brands to deliver compelling product experiences across the retail ecosystem. Our GraphQL powered APIs enable us to support a diverse set of use cases with great developer ergonomics and excellent performance. We look forward to working with the GraphQL Foundation to support the continued evolution of GraphQL.” — Joel Turkel, Chief Software Architect, Salsify

“Solo.io’s mission is to empower enterprise organizations rapidly adopt innovative technology and extend their existing investments. GraphQL is a powerful way to help “glue” monolith, microservices, and serverless applications with a unified API. Our open-source project, Sqoop, leverages GraphQL and other innovative projects like Envoy to streamline the developer experience, and simply glue together environments without writing a single line of code. We are excited to join the GraphQL Foundation and look forward to working within the GraphQL community” — Idit Levine, CEO & Founder, Solo.io

“GraphQL, and alongside its tooling, has grown to proof its worth and is here to stay. Time for a power-up supported by many hands and brains through the Joint Development Foundation and Linux Foundation. GraphQL is the glue that keeps your domain data in context, understandable, and always ready to empower the next ideas. Looking forward to new and improved power’s, to evolution.” — Tim Govers, CEO, Thicit

November 12, 2018 by Channel Futures

in the news

The growing popularity and use of the open-source GraphQL API language by software developers has inspired the creation of a GraphQL Foundation to promote the technology and help it accelerate its development and footprint in future code.

The new organization, hosted by the non-profit Linux Foundation, is made up of a wide range of companies and users that are interested in growing and nurturing the GraphQL API project, which Facebook originally developed internally. After several years of development, Facebook released the code for GraphQL as an opn-source project.

Read more

November 7, 2018 by SD Times

in the news

In an effort to grow and sustain the GraphQL ecosystem, The Linux Foundation has announced plans to launch a new open-source foundation for it. GraphQL is an API technology that was initially developed by Facebook.

The GraphQL Foundation will be a collaborative effort between industry leaders and users.

Read more

November 7, 2018 by Datanami

in the news

Don’t look now but a new language called GraphQL is emerging that could radically simplify how developers use APIs to get data into applications, and potentially provide a graph-like alternative to procedural REST. The company behind the open source software, Apollo, today announced the GraphQL Platform to standardize access to the new technology.

Read more

November 7, 2018 by The Register

in the news

GraphQL, a query language for APIs that was on the verge of being shunned last year over software license concerns, has bounced back and landed in the arms of the Linux Foundation.

Read more

in-the-news

Blog

in the news

InfoWorldNovember 6, 2018

The Linux Foundation plans to host a foundation to support the GraphQL API project, with the intent of growing a neutral ecosystem for the technology.

GraphQL is a specification for building APIs. It is intended to make cross-platform and mobile development simpler. Providing an alternative to REST, GraphQL lets developers use a strongly typed query language to define requests and responses, letting an application specify what it needs from an API. GraphQL enables access to multiple data sources through a single request.

Read more

GraphiQL 5 Released; Press F1!Seeking GraphQL Subject Matter Experts

announcements

GraphQL FoundationNovember 6, 2018

The Linux Foundation, the nonprofit organization enabling mass innovation through open source, announces a broad coalition of industry leaders and users have joined forces to create a new open source foundation for the GraphQL project, which will be dedicated to growing and sustaining a neutral GraphQL ecosystem. Hosted under the Linux Foundation, the GraphQL Foundation’s mission will be to enable widespread adoption and help accelerate development of GraphQL and the surrounding ecosystem.

“As one of GraphQL’s co-creators, I’ve been amazed and proud to see it grow in adoption since its open sourcing. Through the formation of the GraphQL Foundation, I hope to see GraphQL become industry standard by encouraging contributions from a broader group and creating a shared investment in vendor-neutral events, documentation, tools, and support,” said Lee Byron, co-creator of GraphQL.

GraphQL is a next­-generation API technology developed internally by Facebook in 2012 before being publicly open sourced in 2015. As application development shifts towards microservices architectures with an emphasis on flexibility and speed to market, tools like GraphQL are redefining API design and client-server interaction to improve the developer experience, increasing developer productivity and minimizing amounts of data transferred. GraphQL makes cross-platform and mobile development simpler with availability in multiple programming languages, allowing developers to create seamless user experiences for their customers.

GraphQL is being used in production by a variety of high scale companies such as Airbnb, Atlassian, Audi, CNBC, GitHub, Major League Soccer, Netflix, Shopify, The New York Times, Twitter, Pinterest and Yelp. GraphQL also powers hundreds of billions of API calls a day at Facebook.

“We are thrilled to welcome the GraphQL Foundation into the Linux Foundation. This advancement is important because it allows for long-term support and accelerated growth of this essential and groundbreaking technology that is changing the approach to API design for cloud-connected applications in any language,” said Jim Zemlin, Executive Director, the Linux Foundation.

Unlike REST-­based APIs, which take advantage of HTTP and existing protocols, GraphQL APIs provide developers with the flexibility to query the exact data they need from a diverse set of cloud data sources, with less code, greater performance and security, and a faster development cycle. Not only does this enable developers to rapidly build top­ quality apps, it also helps them achieve consistency and feature parity across multiple platforms such as web, iOS, Android, and embedded and IoT applications.

The GraphQL Foundation will have an open governance model that encourages participation and technical contribution and will provide a framework for long-term stewardship by an ecosystem invested in GraphQL’s success.

“At Facebook, our mission is to give people the power to build community and bring the world closer together. We believe open source projects and the communities built around them help accelerate the pace of innovation and bring many minds to bear to solve large-scale challenges. GraphQL is one such project and community and the GraphQL Foundation will help ensure GraphQL continues to solve the real data fetching challenges that developers will face in building the products of tomorrow,” said Killian Murphy, Director, Facebook Open Source.

“GraphQL has redefined how developers work with APIs and client-server interactions. We look forward to working with the diverse GraphQL community from end users like Facebook to a diverse ecosystem of vendors to become an independent foundation, draft their governance and continue to foster the growth and adoption of GraphQL,” said Chris Aniszczyk, Vice President of Developer Relations, the Linux Foundation.

“Airbnb is making a massive investment in GraphQL, putting it at the center of our API strategy across both our product and internal tools. We are excited to see the Foundation play a key role in cultivating the community around GraphQL and continue to evolve GraphQL as a technology, paving the way for continued innovation of Airbnb’s API.” — Adam Neary, Tech Lead, Airbnb

“Given GraphQL’s centrality in the modern app development stack, the foundation we’re announcing today is not just necessary, but overdue. As the creators of Apollo, the most widely used implementation of GraphQL, we’re looking forward to working together with the Linux Foundation to define appropriate governance processes for this critical Internet standard.” – Geoff Schmidt, co­-founder and CEO of Apollo GraphQL

“GraphQL, and the strong ecosystem behind it, is leading to a fundamental change in how we build products, and it helps bring together teams and organizations of every size. At Coursera, GraphQL assists us in understanding the massive breadth of our APIs and helps us create transformative educational experiences for everyone, everywhere. We’re excited to see the impact of the GraphQL Foundation in making both the technology and the community stronger.” – Jon Wong, Staff Software Engineer, Coursera

“GraphQL has come a long way since its creation in 2012. It’s been an honor seeing the technology grow from a prototype, to powering Facebook’s core applications, to an open source technology on the way to becoming a ubiquitous standard across the entire industry. The GraphQL Foundation is an exciting step forward. This new governance model is a major milestone in that maturation process that will ensure a neutral venue and structure for the entire community to drive the technology forward.” – Nick Schrock, Founder, Elementl, GraphQL Co-Creator

“We created GraphQL at Facebook six years ago to help us build high-performance mobile experiences, so to see it grow and gain broad industry adoption has been amazing. Since Facebook open-sourced GraphQL in 2015, the community has grown to include developers around the world, newly-founded startups, and well-established companies. The creation of the GraphQL Foundation is a new chapter that will create a governance structure we believe will empower the community and provide GraphQL long-term technical success. I’m excited to see its continued growth under the Foundation’s guidance.” – Dan Schafer, Facebook Software Engineer, GraphQL Co-Creator

“GraphQL has proven to be a valuable, extensible tool for GitHub, our customers, and our integrators over the past two years. The GraphQL Foundation embodies openness, transparency, and community — all of which we believe in at GitHub.” – Kyle Daigle, Director, Ecosystem Engineering, GitHub

“This is a very welcome announcement, and we believe that this is a necessary step. The GraphQL community has grown rapidly over the last few years, and has reached the point where transparent, neutral governance policies are necessary for future growth. At Hasura, we look forward to helping the Foundation in its work.” – Tanmai Gopal, CEO, Hasura

“GraphQL has become one of the most important technologies in the modern application development stack and sees rapid adoption by developers and companies across all industries. At Prisma, we’re very excited to support the GraphQL Foundation to enable a healthy community and sustain the continuous development of GraphQL.” – Johannes Schickling, Founder and CEO, Prisma

“At Shopify, GraphQL powers our core APIs and all our mobile and web clients. We strongly believe in open development and look to the Foundation to help expand the community and nurture its evolution.” – Jean-Michel Lemieux, SVP Engineering, Shopify

“GraphQL is gaining tremendous adoption as one of the best protocols for remote retrieval of large object graphs. At Twitter, we are looking forward to what’s to come in the GraphQL ecosystem and are very excited to support the GraphQL Foundation.” – Anna Sulkina Sr. Engineering Manager, Core Services Group, Twitter

GraphiQL 5 Released; Press F1!Seeking GraphQL Subject Matter Experts

Blog

in the news

eweekNovember 6, 2018

The Linux Foundation announced on Nov. 6 that it is forming a new foundation to support the open source GraphQL specification, which enables a new generation of APIs. For nearly two decades, REST (Representational State Transfer) has been one of the primary approaches for enabling APIs that help to connect and extend applications and web services. REST however has multiple limitations, which is where GraphQL steps into the picture, finding wide adoption by large web properties. GraphQL was created in 2012 by Facebook and became open source in 2015. The move to create a new vendor-neutral independent foundation under the Linux Foundation will serve to help further advance the development of GraphQL.

Read more

GraphiQL 5 Released; Press F1!Seeking GraphQL Subject Matter Experts

Blog

in the news

ProgrammableWebNovember 8, 2017

GraphQL will now have its own foundation: the GraphQL Foundation. Although GraphQL was initially incubated by Facebook, GraphQL is now utilized heavily by a diverse set of companies including major tech giants (e.g. Twitter, Airbnb, Shopify, etc.). Accordingly, it makes sense that the data query language move to a neutral, open source home. Like many open source projects, the GraphQL Foundation will be hosted by the Linux Foundation. Linux will implement an open governance model similar to many collaborations overseen by Linux. The exact details of the model, and future plans continue to be a work in progress. The current founding members include Airbnb, Apollo, Coursera, Elementl, Facebook, GitHub, Hasura, Prisma, Shopify and Twitter.

Read More

GraphiQL 5 Released; Press F1!Seeking GraphQL Subject Matter Experts

blog

Lee ByronSeptember 14, 2016

After over a year of being open sourced we’re bringing GraphQL out of “technical preview” and relaunching graphql.org.

For us at Facebook, GraphQL isn’t a new technology. GraphQL has been delivering data to mobile News Feed since 2012. Since then it’s expanded to support the majority of the Facebook mobile product and evolved in the process.

Early last year when we first spoke publicly about GraphQL we received overwhelming demand to share more about this technology. That sparked an internal project to revisit GraphQL, make improvements, draft a specification, produce a reference implementation you could use to try it out, and build new versions of some of our favorite tools, like GraphiQL. We moved quickly, and released parts that were ready along the way.

Part of Facebook’s open source philosophy is that we want to only open source what is ready for production. While it’s true that we had been using GraphQL in production at Facebook for years, we knew that these newly released pieces had yet to be proven. We expected feedback. So we carefully released GraphQL as a “technical preview.”

Exactly one year ago, we published graphql.org, with a formal announcement that GraphQL was open source and ready to be “technically previewed”. Since then, we’ve seen GraphQL implemented in many languages, and successfully adopted by other companies. That includes today’s exciting announcement of the GitHub GraphQL API, the first major public API to use GraphQL.

In recognition of the fact that GraphQL is now being used in production by many companies, we’re excited to remove the “technical preview” moniker. GraphQL is production ready.

We’ve also revamped this website, graphql.org, with clearer and more relevant content in response to some the most common questions we’ve received over the last year.

We think GraphQL can greatly simplify data needs for both client product developers and server-side engineers, regardless of what languages you’re using in either environment, and we’re excited to continue to improve GraphQL, support the already growing community, and see what we can build together.

GraphiQL 5 Released; Press F1!Seeking GraphQL Subject Matter Experts

blog

Steven LuscherMay 5, 2016

Time and time again I hear the same aspiration from front-end web and mobile developers: they’re eager to reap the developer efficiency gains offered by new technologies like Relay and GraphQL, but they have years of momentum behind their existing REST API. Without data that clearly demonstrates the benefits of switching, they find it hard to justify an additional investment in GraphQL infrastructure.

In this post I will outline a rapid, low-investment method that you can use to stand up a GraphQL endpoint atop an existing REST API, using JavaScript alone. No backend developers will be harmed during the making of this blog post.

A client-side REST wrapper

We’re going to create a GraphQL schema – a type system that describes your universe of data – that wraps calls to your existing REST API. This schema will receive and resolve GraphQL queries all on the client side. This architecture features some inherent performance flaws, but is fast to implement and requires no server changes.

Imagine a REST API that exposes a endpoint through which you can browse models and their associated friends.

We will build a GraphQL schema that models people and their attributes (like and ) as well as their association to other people through friendships.

Installation

First we’ll need a set of schema building tools.

Building the GraphQL Schema

Ultimately we will want to export a that we can use to resolve queries.

At the root of all GraphQL schemas is a type called whose definition we provide, and have specified here as . Let’s build now – a type on which we will define all the possible things one might want to fetch.

To replicate all of the functionality of our REST API, let’s expose two fields on :

• an field – analogous to
• a field – analogous to

Each field will consist of a return type, optional argument definitions, and a JavaScript method that resolves the data being queried for.

Let’s leave the resolvers as a sketch for now, and move on to defining .

Note two things about the definition of . Firstly, we have not supplied a resolver for , , or . The default resolver simply accesses the property of the object that has the same name as the field. This works everywhere except where the property names do not match the field name (eg. the field does not match the property of the response object from the REST API) or where accessing the property would not yield the object that we want (eg. we want a list of person objects for the field, not a list of URLs).

Now, let’s write resolvers that fetch people from the REST API. Because we need to load from the network, we won’t be able to return a value right away. Luckily for us, can return either a value or a for a value. We’re going to take advantage of this to fire off an HTTP request to the REST API that eventually resolves to a JavaScript object that conforms to .

And here we have it – a complete first-pass at the schema:

Using a client-side schema with Relay

Normally, Relay will send its GraphQL queries to a server over HTTP. We can inject @taion’s custom network layer to resolve queries using the schema we just built. Put this code wherever it’s guaranteed to be executed before you mount your Relay app.

And that’s that. Relay will send all of its queries to your custom client-resident schema, which will in turn resolve them by making calls to your existing REST API.

A server-side REST wrapper

The client-side REST API wrapper demonstrated above should help you get up and running quickly so that you can try out a Relay version of your app (or part of your app).

However, as we mentioned before, this architecture features some inherent performance flaws because of how GraphQL is still calling your underlying REST API which can be very network intensive. A good next step is to move the schema from the client side to the server side to minimize latency on the network and to give you more power to cache responses.

Take the next 10 minutes to watch me build a server side version of the GraphQL wrapper above using Node and Express.

Bonus round: A truly Relay compliant schema

The schema we developed above will work for Relay up until a certain point – the point at which you ask Relay to refetch data for records you’ve already downloaded. Relay’s refetching subsystem relies on your GraphQL schema exposing a special field that can fetch any entity in your data universe by GUID. We call this the node interface.

To expose a node interface requires that you do two things: offer a field at the root of the query, and switch all of your ids over to GUIDs (globally-unique ids).

The package contains some helper functions to make this easy to do.

Global ids

First, let’s change the field of into a GUID. To do this, we’ll use the helper from .

Behind the scenes returns a field definition that resolves to a by hashing together the typename and the id returned by the REST API. We can later use to convert the result of this field back into and the REST API’s id.

The node field

Another set of helpers from will give us a hand developing the node field. Your job is to supply the helper two functions:

• One function that can resolve an object given a GUID.
• One function that can resolve a typename given an object.

The object-to-typename resolver above is no marvel of engineering, but you get the idea.

Next, we simply need to add the and the to our schema. A complete example follows:

Taming pathological queries

Consider the following friends-of-friends-of-friends query:

The schema we created above will generate multiple round trips to the REST API for the same data.

This is obviously something we would like to avoid! At the very least, we need a way to cache the result of these requests.

We created a library called DataLoader to help tame these sorts of queries.

As a special note, make sure that your runtime offers native or polyfilled versions of and . Read more at the DataLoader site.

Creating a data loader

To create a you supply a method that can resolve a list of objects given a list of keys. In our example, the keys are URLs at which we access our REST API.

If this data loader sees a key more than once in its lifetime, it will return a memoized (cached) version of the response.

Loading data

We can make use of the and methods on to load URLs without fear of hitting the REST API more than once per URL. A complete example follows:

Now, our pathological query produces the following nicely de-duped set of requests to the REST API:

Query planning and beyond

Consider that your REST API might already offer configuration offers that let you eagerly load associations. Maybe to load a person and all of their direct friends you might hit the URL . To take advantage of this in your GraphQL schema you will need the ability to develop a resolution plan based on the structure of the query itself (eg. whether the field is part of the query or not).

For those interested in the current thinking around advanced resolution strategies, keep an eye on pull request #304.

Thanks for reading

I hope that this demonstration has torn down some of the barriers between you and a functional GraphQL endpoint, and has inspired you to experiment with GraphQL and Relay on an existing project.

GraphiQL 5 Released; Press F1!Seeking GraphQL Subject Matter Experts

blogfrontend

Jonas HelferApril 19, 2016

Do you think mocking your backend is always a tedious task? If you do, reading this post might change your mind…

Mocking is the practice of creating a fake version of a component, so that you can develop and test other parts of your application independently. Mocking your backend is a great way to quickly build a prototype of your frontend, and it lets you test your frontend without starting up any servers. API mocking is so useful that a quick Google search will turn up dozens of expensive products and services that promise to help you.

Sadly, I think none of the solutions out there make it as easy as it should be. As it turns out, that’s because they’ve been trying to do it with the wrong technology!

Editor’s note : The concepts in this post are accurate, but some the code samples don’t demonstrate new usage patterns. After reading, consult the graphql-tools docs to see how to use mocking today.

Why mock?

Mocking the data a backend would return is very useful for two main reasons:

1. It lets you start developing a frontend feature when you don’t have a working backend for it yet. This is critical for projects where the frontend and backend components are often developed in parallel.
2. It lets you run tests locally without connecting to a real backend, which is much faster and safer. As your codebase grows and your app becomes more complex, starting up all of the server infrastructure just to run some tests isn’t feasible.

If mocking your backend API has such clear benefits, why doesn’t everyone do it? I think it’s because mocking often seems like too much trouble to be worth it.

Why is mocking backends hard?

Let’s say your backend is some REST API that is called over HTTP from the browser. You have someone working on the backend, and someone else working on the frontend. The backend code actually determines the shape of the data returned for each REST endpoint, but mocking has to be done in the frontend code. That means the mocking code will break every time the backend changes, unless both are changed at the same time. What’s worse, if you’re doing your frontend testing against a mock backend that is not up to date with your backend, your tests may pass, but your actual frontend won’t work.

Rather than having to keep more dependencies up to date, the easy option is to just not mock the REST API, or have the backend be in charge of mocking itself, just so it’s all in one place. That may be easier, but it will also slow you down.

The other reason I often hear for why people don’t mock the backend in their project is because it takes time to set up: first you have to include extra logic in your data fetching layer that lets you turn mocking on and off, and second you have to actually describe what that mock data should look like. For any non-trivial API that requires a lot of tedious work.

Both of these reasons for why mocking backends is hard are actually due to the same underlying reason: there is no standard REST API description in machine-consumable format and contains all the information necessary for mocking and can be used by both the backend and the frontend. There are some API description standards, like Swagger, but they don’t contain all of the information you need, and can be cumbersome to write and maintain. Unless you want to pay for a service or a product — and maybe even then — mocking is a lot of work.

Actually, I should say mocking used to be a lot of work, because a new technology is changing the way we think of APIs: GraphQL.

Mocking is easy with a type system!

GraphQL makes mocking easy, because every GraphQL backend comes with a static type system. The types can be shared between your backend and your frontend, and they contain all of the information necessary to make mocking incredibly fast and convenient. With GraphQL, there is no excuse to not mock your backend for development or testing.

Here’s how easy it is to create a mocked backend that will accept any valid GraphQL query with the GraphQL mocking tool we are building as part of our new GraphQL server toolkit:

Every GraphQL server needs a schema, so it’s not extra code you need to write just for mocking. And the query is the one your component already uses for fetching data, so that’s also not code you write just for mocking. Not counting the import statement, it only took us one line of code to mock the entire backend!

Put that in contrast to most REST APIs out there, where mocking means parsing a URL and returning data in a custom shape for each endpoint. It takes dozens of lines to mock a single endpoint that returns some realistic-looking data. With GraphQL, the shape is encoded in the query, and together with the schema we have enough information to mock the server with a single line of code.

Did I mention that this one line is all you need to return mock data for any valid GraphQL query you could send? Not just some valid query, any valid query! Pretty cool, right?

Customizing mock data

In the example above, the mock server will return completely random IDs and strings every time you query it. When you’ve just started building your app and only want to see what your UI code looks like in different states, that’s probably good enough, but as you start to fine-tune your layout, or want to use the mock server to test your component’s logic, you’ll probably need more realistic data.

Luckily, this takes only a little more effort: customization of mock data is really where the Apollo mocking tool shines, because it lets you customize virtually everything about the mock data that it returns.

It lets you do all of the following and more:

For each type and each field you can provide a function that will be called on to generate mock data. Mock functions on fields have precedence over mock functions on types, but they work together really nicely: The field mock functions only need to describe the properties of the objects that matter to them, type mock functions will fill in the rest.

The mock functions are actually just GraphQL resolve functions in disguise. What that means is that your mocking can do anything that you could do inside a GraphQL resolve function. If you wanted, you could write your entire backend with it. I’m not saying you should, but you could.

I think the real power of this tool is that while it allows almost arbitrarily complex customization, you can get started really quickly and increase the sophistication of your mocks in tiny steps whenever you need it. Each step is so simple that it will feel like a breeze.

But enough talking, here’s a complete example:

Live demo + try it yourself

To see the example in action and see what output it generates, head over to the live demo try running some queries!

If you want to fiddle around with the example, just click the “Download” button in the Launchpad UI. If you’re curious about how it works or want to see what other tools we’re building for GraphQL, then head over to apollostack/graphql-tools.

Pretty cool, right? All of that becomes possible by using a type system. And that’s only just the beginning — we‘re working on bridging the gap between mocking and the real thing so that your mock server can gradually turn into your real server as you add more functionality to it.

This post was originally published on the Apollo Blog. We publish one or two posts every week, about the stuff we’re working on and thinking about.

GraphiQL 5 Released; Press F1!Seeking GraphQL Subject Matter Experts

blogspecfrontend

Dan Schafer and Laney KuenzelOctober 16, 2015

When we announced and open-sourced GraphQL and Relay this year, we described how they can be used to perform reads with queries, and to perform writes with mutations. However, oftentimes clients want to get pushed updates from the server when data they care about changes. To support that, we’ve introduced a third operation into the GraphQL specification: subscription.

The approach that we’ve taken to subscriptions parallels that of mutations; just as the list of mutations that the server supports describes all of the actions that a client can take, the list of subscriptions that the server supports describes all of the events that it can subscribe to. Just as a client can tell the server what data to refetch after it performs a mutation with a GraphQL selection, the client can tell the server what data it wants to be pushed with the subscription with a GraphQL selection.

For example, in the Facebook schema, we have a mutation field named , that clients can use to like a post. The client might want to refetch the like count, as well as the like sentence (“Dan and 3 others like this”. We do this translation on the server because of the complexity of that translation in various languages). To do so, they would issue the following mutation:

But when you’re looking at a post, you also want to get pushed an update whenever someone else likes the post! That’s where subscriptions come in; the Facebook schema has a subscription field named that allows the client to get pushed data anytime someone likes or unlikes that story! The client would create a subscription like this:

The client would then send this subscription to the server, along with the value for the variable, which would contain information like the story ID to which we are subscribing:

At Facebook, we send this query to the server at build time to generate a unique ID for it, then subscribe to a special MQTT topic with the subscription ID in it, but many different subscription mechanisms could be used here.

On the server, we then trigger this subscription every time someone likes a post. If all of our clients were using GraphQL, we could put this hook in the GraphQL mutation; since we have non-GraphQL clients as well, we put the hook in a layer below the GraphQL mutation to ensure it always fires.

Why not Live Queries?

Notably, this approach requires the client to subscribe to events that it cares about. Another approach is to have the client subscribe to a query, and ask for updates every time the result of that query changes. Why didn’t we take that approach?

Let’s look back at the data we wanted to refetch for the story:

What events could trigger that a change to the data fetched in that fragment?

• Someone likes the post.
• Someone unlikes the post.
• Someone who had liked the post deactivates their account (changes the like count down one, changes the like sentence to decrement the translated count).
• Someone who had liked the post reactivates their account (changes the like count up one, changes the like sentence to increment the translated count).
• Someone who had liked the post blocks you (cannot show them in the like sentence).
• Someone who had liked the post changes their name (need to update the text of the like sentence).
• Our internal ranking model for the ordering of names in the like sentence updates, and we should be listing a different person first (want to update the text of the like sentence).

And that’s just the tip of the iceberg in terms of events; each of those events also becomes tricky when there are thousands of people subscribed, and millions of people who liked the post. Implementing live queries for this set of data proved to be immensely complicated.

When building event-based subscriptions, the problem of determining what should trigger an event is easy, since the event defines that explicitly. It also proved fairly straight-forward to implement atop existing message queue systems. For live queries, though, this appeared much harder. The value of our fields is determined by the result of their resolve function, and figuring out all of the things that could alter the result of that function was difficult. We could in theory have polled on the server to implement this, but that had efficiency and timeliness issues. Based on this, we decided to invest in the event-based subscription approach.

What’s next?

We’re actively building out the event-based subscription approach described above. We’ve built out live liking and commenting features on our iOS and Android apps using that approach, and are continuing to flesh out its functionality and API. While its current implementation at Facebook is coupled to Facebook’s infrastructure, we’re certainly looking forward to open sourcing our progress here as soon as we can.

Because our backend and schema don’t offer easy support for live queries, we don’t have any plans to develop them at Facebook. At the same time, it’s clear that there are backends and schemas for which live queries are feasible, and that they offer a lot of value in those situations. The discussion in the community on this topic has been fantastic, and we’re excited to see what kind of live query proposals emerge from it!

Subscriptions create a ton of possibilities for creating truly dynamic applications. We’re excited to continue developing GraphQL and Relay with the help of the community to enable these possibilities.

GraphiQL 5 Released; Press F1!Seeking GraphQL Subject Matter Experts

blogspecfrontendbackend

Lee ByronSeptember 14, 2015

When we built Facebook’s mobile applications, we needed a data-fetching API powerful enough to describe all of Facebook, yet simple and easy to learn so product developers can focus on building things quickly. We developed GraphQL three years ago to fill this need. Today it powers hundreds of billions of API calls a day. This year we’ve begun the process of open-sourcing GraphQL by drafting a specification, releasing a reference implementation, and forming a community around it here at graphql.org.

Why GraphQL?

Back in 2012, we began an effort to rebuild Facebook’s native mobile applications.

At the time, our iOS and Android apps were thin wrappers around views of our mobile website. While this brought us close to a platonic ideal of the “write one, run anywhere” mobile application, in practice it pushed our mobile-webview apps beyond their limits. As Facebook’s mobile apps became more complex, they suffered poor performance and frequently crashed.

As we transitioned to natively implemented models and views, we found ourselves for the first time needing an API data version of News Feed — which up until that point had only been delivered as HTML. We evaluated our options for delivering News Feed data to our mobile apps, including RESTful server resources and FQL tables (Facebook’s SQL-like API). We were frustrated with the differences between the data we wanted to use in our apps and the server queries they required. We don’t think of data in terms of resource URLs, secondary keys, or join tables; we think about it in terms of a graph of objects and the models we ultimately use in our apps like NSObjects or JSON.

There was also a considerable amount of code to write on both the server to prepare the data and on the client to parse it. This frustration inspired a few of us to start the project that ultimately became GraphQL. GraphQL was our opportunity to rethink mobile app data-fetching from the perspective of product designers and developers. It moved the focus of development to the client apps, where designers and developers spend their time and attention.

What is GraphQL?

A GraphQL query is a string that is sent to a server to be interpreted and fulfilled, which then returns JSON back to the client.

Defines a data shape: The first thing you’ll notice is that GraphQL queries mirror their response. This makes it easy to predict the shape of the data returned from a query, as well as to write a query if you know the data your app needs. More important, this makes GraphQL really easy to learn and use. GraphQL is unapologetically driven by the data requirements of products and of the designers and developers who build them.

Hierarchical: Another important aspect of GraphQL is its hierarchical nature. GraphQL naturally follows relationships between objects, where a RESTful service may require multiple round-trips (resource-intensive on mobile networks) or a complex join statement in SQL. This data hierarchy pairs well with graph-structured data stores and ultimately with the hierarchical user interfaces it’s used within.

Strongly typed: Each level of a GraphQL query corresponds to a particular type, and each type describes a set of available fields. Similar to SQL, this allows GraphQL to provide descriptive error messages before executing a query. It also plays well with the strongly typed native environments of Obj-C and Java.

Protocol, not storage: Each GraphQL field on the server is backed by a function - code linking to your application layer. While we were building GraphQL to support News Feed, we already had a sophisticated feed ranking and storage model, along with existing databases and business logic. GraphQL had to leverage all this existing work to be useful, and so does not dictate or provide any backing storage. Instead, GraphQL takes advantage of your existing code by exposing your application layer, not your storage layer.

Introspective: A GraphQL server can be queried for the types it supports. This creates a powerful platform for tools and client software to build atop this information like code generation in statically typed languages, our application framework, Relay, or IDEs like GraphiQL (pictured below). GraphiQL helps developers learn and explore an API quickly without grepping the codebase or wrangling with cURL.

Version free: The shape of the returned data is determined entirely by the client’s query, so servers become simpler and easy to generalize. When you’re adding new product features, additional fields can be added to the server, leaving existing clients unaffected. When you’re sunsetting older features, the corresponding server fields can be deprecated but continue to function. This gradual, backward-compatible process removes the need for an incrementing version number. We still support three years of released Facebook applications on a single version of our GraphQL API.

With GraphQL, we were able to build full-featured native News Feed on iOS in 2012, and on Android shortly after. Since then, GraphQL has become the primary way we build our mobile apps and the servers that power them. More than three years later, GraphQL powers almost all data-fetching in our mobile applications, serving millions of requests per second from nearly 1,000 shipped application versions.

When we built GraphQL in 2012 we had no idea how important it would become to how we build things at Facebook and didn’t anticipate its value beyond Facebook. However, earlier this year we announced Relay, our application framework for the web and React Native built atop GraphQL. The community excitement for Relay inspired us to revisit GraphQL to evaluate every detail, make improvements, fix inconsistencies, and write a specification describing GraphQL and how it works.

Two months ago, we made our progress public and released a working draft of the GraphQL spec and a reference implementation: GraphQL.js. Since then, a community has started to form around GraphQL, and versions of the GraphQL runtime are being built in many languages, including Go, Ruby, Scala, Java, .Net, and Python. We’ve also begun to share some of the tools we use internally, like GraphiQL, an in-browser IDE, documentation browser, and query runner. GraphQL has also seen production usage outside Facebook, in a project for the Financial Times by consultancy Red Badger.

“GraphQL makes orchestrating data fetching so much simpler, and it pretty much functions as a perfect isolation point between the front end and the back end” — Viktor Charypar, software engineer at Red Badger

While GraphQL is an established part of building products at Facebook, its use beyond Facebook is just beginning. Try out GraphiQL and help provide feedback on our specification. We think GraphQL can greatly simplify data needs for both client product developers and server-side engineers, regardless of what languages you’re using in either environment, and we’re excited to continue to improve GraphQL, help a community grow around it, and see what we can build together.

GraphiQL 5 Released; Press F1!Seeking GraphQL Subject Matter Experts