The Sched app allows you to build your schedule but you must also be registered for GraphQLConf 2026 to participate in the sessions.
Please note: This schedule is automatically displayed in Pacific Daylight Time (UTC-7). To see the schedule in your preferred timezone, please select from the drop-down located at the bottom of the menu to the right.
IMPORTANT NOTE: Timing of sessions and room locations are subject to change.
Sign up or log in to add sessions to your schedule and sync them to your phone or calendar.
GraphQL's precise specification gives us incredible interoperability and a rich ecosystem of tooling to be used with any compliant GraphQL service... And yet, that hasn't led to every adopter of GraphQL having a great experience. Some leave disillusioned with performance pitfalls, security concerns, and unforeseen complexity. This can be frustrating for successful GraphQL practitioners since in many cases the solutions to these problems have existed for most of the last decade.
The Golden Path Initiative aims to make it so avoiding common pitfalls becomes the path of least resistance. By encouraging off-the-shelf GraphQL-related software to implement the recommended default behaviours, we hope that GraphQL adopters will have the greatest chance of being successful even without ingesting the vast amount of information in the ecosystem. The Golden Path is not centred on building the most optimal experience, instead it is focused on minimizing downsides: making it so users are exploring around the "pit of success", and taking them far from the "pit of despair".
But to do this will take a huge, coordinated community effort! We need successful GraphQL practitioners; maintainers of key GraphQL libraries, frameworks and tooling; and documentation writers to join us over the next 6 months as we lay out the Golden Path, its recommendations and requirements; and then next year: time to start implementing it across the ecosystem!
A self-described "community-funded open source maintainer," Benjie dedicates much of his time to open source, made possible by the support of appreciative and forward-thinking individuals and organizations. He can often be found helping contributors advance their proposals, and has... Read More →
A year ago, we forecast an important role for GraphQL in an AI future. That prediction has come true, with GraphQL now serving as the foundation of critical AI initiatives at household brands in retail, hospitality, health care and many more. Just as importantly, GraphQL's declarative entity-based architecture has proven to be an ideal match for modern agentic development.
In this talk, we'll share a view of where GraphQL now sits in the modern enterprise stack, recount lessons we've learned putting MCP workloads and agentic software in production with the graph, our roadmap for an AI-first world, and a vision of where GraphQL can and must go next.
In the rush to "break the monolith" through GraphQL Federation, organizations can go too far and end up with an explosion of subgraphs. At scale, this can lead to a different kind of pain: high operational overhead, reliability issues, and ultimately, a degraded graph quality. This session explores how to pivot from "splitting" to "merging" without impacting the customer. The presentation will dive into the workflow developed by Brex to consolidate federated subgraphs safely and reliably, covering: • The Why: Identifying the tipping point where service fragmentation hurts more than it helps. • The Strategy: A zero-downtime workflow for merging services covering code migration, schema composition and traffic shifting • Reliability: How to ensure schema integrity and 0 customer impact during the transition. • Outcomes: How the consolidation improved our graph design and simplified our overall architecture.
Attendees will leave with a framework for evaluating when federation boundaries are hurting more than helping and a roadmap for executing a "subgraph smash" in their own federated infrastructure.
Clarice Abreu leads the roadmap and strategy for the Brex's GraphQL platform. She drives initiatives to improve schema quality, schema validation and observability, helping teams build and evolve a large-scale federated GraphQL architecture.
Rodrigo Jesus is a Senior Software Engineer at Brex's Application Infrastructure team focused on taming complexity in large distributed systems. He currently leads service smashing and domain consolidation efforts that reduce fragmentation, lower operational overhead, and improve... Read More →
GraphQL Federation traditionally takes a bottom-up approach: individual service schemas are defined first, and the final federated API emerges from the federation algorithm. However, GraphQL's strength is enabling APIs that are designed around what consumers actually need. A bottom-up model can make it harder to intentionally design the federated API surface. In this talk we introduce Fission, a new federation algorithm that enables a consumer-first, design-driven approach to federated GraphQL APIs. We'll show how Fission lets teams start with API design and derive the services therefrom—flipping the traditional federation paradigm on its head. And best yet: we'll explain using cake.
David is one of the four founding engineers at WunderGraph who collectively built the software foundations of the company. David's career began in the finance sector of software engineering before moving exclusively to API management in 2022. From that point, David started his deep-dive... Read More →
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.
Jordan has spent the last nine years working at Meta. He currently works on Relay, a sophisticated GraphQL client for JavaScript that powers most of Meta's JavaScript applications.
Parsing a GraphQL query generally has negligible cost. But what happens your front page query has millions of QPS, 10s of thousands of fields, and there are hundreds of versions of the query? At Meta, we've found that parsing becomes a significant bottle neck under these constraints.
In this talk, we dive into server-side optimizations we built to handle persisted documents beyond simple LRU caches. We will cover: - Lazy fragment parsing. We delay parsing a fragment until the executor encounters a spread that matches the fragment's type, using offset maps to jump through the document text. - Traffic based caching. We cache pre-parsed structures taking into consideration CPU savings and memory cost. - Fragment inlining to reduce overhead in the CollectFields step.
Attendees leave with deep understanding of performance considerations of GraphQL execution engines. I hope other GraphQL server implementations can consider adopting similar strategies to better serve a larger variety of traffic patterns.
Gary is a Software Engineer working on Meta's GraphQL engine powering one of the worlds largest schemas. He focuses the balance between language design and system reliability. In the physical world, Gary has hosted over 1000 hours of Dungeons and Dragons.
How do you teach AI to navigate GraphQL schemas with thousands of fields? At Meta, we built an AI system that dynamically discovers and loads subschemas on-demand, enabling natural language interactions with complex enterprise APIs.
This talk shares hard-won lessons from building production AI that performs real-time schema exploration, manages dynamic subschema composition, and generates sophisticated GraphQL operations at Meta's scale.
Key Topics: - Dynamic schema discovery from user intent - On-demand subschema loading architecture (@require_graphql_subschemas directive) - Teaching LLMs GraphQL type relationships and dependencies - Performance optimizations for real-time schema introspection - What failed and why certain approaches don't scale
Lessons from Production: - Schema design principles that work better with AI Security considerations for AI-driven schema access - Operational challenges and monitoring strategies - Attendees leave with battle-tested patterns for conversational GraphQL systems, specific techniques for dynamic schema loading, and honest insights about what didn't work along the way.
Hugh Nguyen is a Software Engineer working on Metamate team at Meta, which builds AI powered products and platforms. Hugh is working on enabling AI agents to access all internal knowledge through GraphQL, a novel approach to rapidly expand AI agent's capabilities.
AI coding agents are now a daily reality for GraphQL developers, yet there's a persistent gap between what agents can do and what they actually know. Without guidance, they generate anonymous queries, skip variables, rely on deprecated patterns, and miss conventions experienced teams consider obvious. Every conversation starts from zero. Agent Skills are an emerging answer: a lightweight, open format for encoding expertise that agents can automatically apply. In a short time, the community has begun building Skills that teach everything from schema usage to client caching, and the ecosystem is evolving fast. This talk surveys the current state of GraphQL Agent Skills: what they are, how they're authored, how they plug into AI tools and workflows, and how they complement MCP. As the creator and maintainer of Apollo Skills, I'll share what we've learned building and shipping them. Through real-world examples, we'll see how Skills help agents design a schema safely, write the right operations, and recover from mistakes. We'll examine design trade-offs, emerging patterns, and open challenges still ahead. You'll leave knowing how to make your graph work better with AI agents.
Pretty much every major GraphQL execution implementation follows the same pattern: depth-first traversal. But the spec doesn’t require this. At Shopify, we challenged that status quo and rewrote GraphQL execution to run breadth-first.
Here’s how it works: instead of running a field resolver repeatedly across each object in a list during its depth pass, we execute each field resolver only once per selection with a complete breadth of objects spanning the response. The napkin math is compelling—5 fields resolved across a list of 100 objects running depth-first will produce 500 resolver calls + lazy promises, while running breadth-first will only produce 5. We’ve seen dramatic results with some large list queries shaving many seconds off their end-to-end response times.
This talk will cover:
* Why depth-first has hidden costs that scale linearly. * How breadth-first inverts the cost model. * Why dataloaders are a hack. * The trade-offs we accepted. * How we're incrementally migrating to breadth execution.
If you've ever been concerned that CPU-bound GraphQL performance doesn't scale well, this talk offers a new perspective—and proof that challenging conventions can pay off.
Greg is an API Foundations engineer at Shopify focused on GraphQL scalability and performance. He’s an open-source contributor on several GraphQL projects, and author of The Schema Stitching Handbook. Coder. Dad. Likes dogs, juggles fire.
Optimizing wire size is in WhatsApp's DNA. In the early days, we transformed verbose XML into a compact binary protocol (WAP) that helped us serve users worldwide on constrained networks. Now, as we migrate to GraphQL, we faced a new challenge: JSON responses were 30% larger than WAP-encoded equivalents. This talk tells the story of how we solved that problem—by leveraging GraphQL's type system to outperform not just JSON, but WAP and protobufs too. We'll share the technical approach (implementing Argo), the results (27-50% smaller responses), and why this represents the next evolution in efficient data transfer for Meta's apps.
GraphQL is often framed around multiple clients, external consumers, and solving over/under-fetching. But what if you have one client, fragmented internal APIs, and colleagues as your consumers? This talk explores that different axis—and why GraphQL still matters.
At trivago, we built a second GraphQL Gateway to unify internal services. What started as admin tooling became something more: a lens that surfaced hidden system relationships, a catalyst for cross-team collaboration, and now a foundation for AI-assisted tooling enriched with human-written business context.
This session shares honest lessons from six years of running an internal-facing gateway. You'll hear how we unified services without imposing upstream requirements, fostered collaboration across previously siloed teams, and designed audit logging around user intent—not just technical calls. Whether or not this specific approach fits your context, you'll leave with a broader perspective: there's more to GraphQL than its typical framing suggests.
Angel Svirkov is a Software Engineer at trivago, Germany. Over 10 years, he has bridged product needs and engineering realities—owning problems end-to-end from discovery through architecture, implementation, rollout, and operations. For the past six years, this work has centered... Read More →
Learn how to lower latency in your applications by streaming your GraphQL responses using the @defer and @stream directives. Learn the trade-offs of when to use these new directives and how they differ from GraphQL Subscriptions.
@defer and @stream have been in development for some time now and have gone through many iterations. Learn about the motivation behind these changes and how they will lead to scalable GraphQL servers and efficient clients.
Rob is a front-end engineer at 1stDibs, an online marketplace for extraordinary design. He is also a member of the GraphQL Technical Steering committee, where he has been championing the @defer & @stream spec proposal.
In GraphQL, a resolver is defined as “the internal function for determining the resolved value of a field.” Traditionally, resolvers live exclusively on the server—but should they? Many teams find themselves either duplicating business logic on the client or pushing client-specific concerns into backend code when trying to treat server models as view models.
This talk explores an alternative: client-side resolvers. With Relay Resolvers, clients can define fields that combine and transform data locally. We'll walk through how they work and guidance for deciding when logic belongs on the server versus the client.
In high-stakes industries, a GraphQL schema is more than a technical contract—it is a live map of your enterprise’s risk surface. For security teams, schema modifications are often "black box" events that threaten data integrity. To scale safely, we must move beyond manual gatekeeping to a Zero-Trust Supergraph where security is an invisible, automated fortress.
We will present a framework for Embedded Governance to bridge engineering and enterprise risk. Learn how to transform your graph's technical "menu" into a transparent Data Marketplace with radical observability, ensuring built-in security and compliance.
Attendees will learn to: - Navigate the Risk Primer: Translate GraphQL features (types, fields, directives) into risk language to build organizational trust. - Shift Security Left: Automate security with secure frameworks & replacing manual reviews. - Architect for Data Isolation: Use of fine grained access to manage entitlements and prevent unauthorized data exposure. - Harden the Control Plane: Reduce attack surface using technical strategies like disabling introspection and enforcing persisted query ownership.
Gaurav Singh serves as a Distinguished Engineer and Cybersecurity Architect at Capital One. His contributions were pivotal in the enablement of GraphQL Federation throughout the enterprise, which involved the introduction of open-source GraphQL federation products , a dedicated GraphQL... Read More →
Sulbigar Shanawaz is a Distinguished Engineer at Capital One, where he leads architectural strategy for the Enterprise Entitlements platform. He specializes in centralizing customer data security by engineering robust validation frameworks for regulatory, compliance, and audit requirements across hig... Read More →
The GraphQL Schema Documentation (https://graphql.org/learn/schema/) defines the __typename field as “a special meta-field that automatically exists on every Object type and resolves to the name of that type, providing a way to differentiate between data types on the client.” At Meta, we’ve learned that relying on __typename to delineate type on the client can actually be a foot-gun. Querying __typename for every object is clunky, increases payload size, creates backward compatibility issues for older, unupgradable clients, and isn’t sufficient for handling complex schema cases like nested abstract types.
In this talk, I’ll walk through specific scenarios where __typename falls short, and demonstrate how using a new metadata field, `is_fulfilled`, is better-suited to writing more robust GraphQL clients.
Instagram is moving from a Python monolith to a PHP monolith. Come find out how we leverage GraphQL to define a single API across both monoliths to power major product migrations (e.g. Stories, Reels, Threads) and facilitate incremental development shifts.
Meta’s architectural philosophy favors federation to support a monolithic architecture over traditional microservices.
Left to its own devices, software companies ship its own team structure (Conway’s Law). Scale leads to data silos, unclear ownership, and an incoherent GraphQL schema. Zillow pushes back against this natural entropy. Organizing data post hoc is untenable — trying to keep up with the legions of changing SaaS systems is a losing battle. The schema must be organized at the data producer end. This is the story of Zillow’s journey to bring order to a chaotic GraphQL schema. Starting with its most critical data domains, listings and customers, Zillow has built a canonical data schema in its federated graph, that aligns its multiple business units and streamlines data sharing.
Senior Principal SDE at Zillow Group by day, avid user by night. Sam Deng is catalyst for foundational platforms that power the Zillow Super App. He is a purveyor of dad jokes, software architect, former runner, and occasional AI-empowered code slinger.
Have you ever wished you could better understand how the entities in your graph behave over time? Are they cacheable? How often are they updated? How often are they accessed? What is the distribution of keys?
The primitives of GraphQL federation are simple: Entities with keys to uniquely identify them, distributed across multiple services.
The story they tell? It's a fascinating one, but nobody talks about it. Until now. And it's not even that complicated, just a couple of hashes and we're able to learn more about your data than you ever thought possible.
Jens is a father to 3 kids, tries to be a good husband, is the author and a maintainer of graphql-go-tools for more than 6 years, and the CEO and Co-Founder of WunderGraph, a company that offers Cosmo, an open source GraphQL Federation platform.
