GraphQLConf 2026

React Server Components (RSC) and GraphQL have considerable overlap in the problems they seek to solve. This makes them competitors in some scenarios.

In this talk we’ll recount the origins of RSCs at Meta as a prototype within the Relay GraphQL client, discuss how to choose between the two technologies, and end with an exploration of architectures in which they both might reasonably coexist moving forward.

Using GraphQL for service-to-service communication has historically been....frowned upon. Certainly, in isolation, there are compelling alternatives (gRPC, thrift, good ol' REST).

But in the age of LLMs and SDUI (Server Driven UI), there's lot of data whizzing around microservices. Does GraphQL fit this use case? I'll argue...yes!

You could define your data models with a combination of REST, gRPC, GraphQL; each layer gets a different transport protocol. Or we could consolidate on GraphQL.

This talk lays out why and when this makes sense, and what patterns are helpful to achieve this.

(ATTN: CFP reviewers -- fwiw the title is referencing https://productionreadygraphql.com/blog/2020-05-14-sweetspot)

A new approach to GraphQL execution, enabling engineers to build next-level efficiency into new or existing GraphQL APIs. This declarative approach to execution eliminates the many pitfalls of traditional resolvers and optimizes communications with your business logic. This is achieved through understanding the request's full data requirements and planning the best batched execution strategy before requesting anything from the business logic. This decoupling of data fetching from the GraphQL request shape results in fewer and more efficient operations against your backend services and data sources, eliminating both over- and under-fetching on the backend along with deduplication of redundant work, leading to reduced operational costs and delightful user experiences! A passion project of a founding GraphQL TSC member, this MIT-licensed open source technology has already been in production at a number of companies for over a year!

At Airbnb, our GraphQL gateway is a multi-tenant serverless platform hosting 500+ tenants and 1.5M+ lines of application code. Like many large GraphQL systems, it operated as a "shared fate" architecture. To mitigate this risk, we embarked on a multi-year journey to implement traffic sharding at different levels of sophistication. We started with shuffle sharding to reduce the blast radius of any single bad operation. We then added targeted sharding to separate online from asynchronous traffic, to rapidly quarantine misbehaving operations, and to improve the signal-to-noise ratio for our automated canary analysis. Most recently, to mitigate the risk posed by tenants that are used by lots of operations (and thus could bring down lots of shards), we have been working on tenant-aware sharding that minimizes the blast radius of such tenants.

We will cover how we architected our sharding solution and how it improved our operational abilities. You will gain a clear understanding of how our implementation tradeoffs have fared over time, key production insights gathered since rollout, and strategies to evolve a GraphQL gateway towards greater isolation without fragmenting the API surface.

What if a city could run as a GraphQL server?

In this talk, we model San Francisco as a modular GraphQL runtime powered by Viaduct. Instead of stitching together microservices or configuring external gateways, we organize zoning, building permits, transit, and census data as domain modules inside a single distributed graph engine.

Using real public datasets from the City of San Francisco and the U.S. Census, we demonstrate how tenant modules compose into a unified schema, how execution is coordinated across domain boundaries, and how teams can evolve parts of the graph without central bottlenecks.

We introduce a lightweight Skills SDK that abstracts runtime configuration and enforces clear ownership rules, making modular graph design approachable.

Finally, we connect an AI client to the server to demonstrate structured, explainable reasoning over live city data.

All demo code and schema modules will be open sourced for attendees to explore and extend.