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.
In order to facilitate networking and business relationships at the event, you may choose to visit a third party’s booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), and details about the sponsored content or resources you interacted with. If you choose to interact with a booth or access sponsored content, you are explicitly consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.
In 2015, we promised GraphQL would be "easy to learn and use". Ten years, and hundreds of billions of daily API calls later, we've learned that not all our hopes and promises turned out to be true.
This keynote is an honest retrospective from inside Meta. We'll share which assumptions didn't survive contact with thousands of engineers, the complexity traps we fell into, and what’s driving the new wave of GraphQL adoption and popularity at Meta.
Whether you're GraphQL-curious or GraphQL-exhausted, this is a rare look behind the curtain and a preview of what re-inventing GraphQL at scale actually looks like.
Software Engineering Manager at Meta, leading the Mobile GraphQL Platform. Focused on building scalable, intuitive GraphQL infrastructure and tooling that powers mobile experiences at global scale. Passionate about platform engineering, API design, and enabling product teams to move... Read More →
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 make one of the world's largest federated graphs accessible to token-constrained LLM minions?
With hundreds of teams contributing to or consuming GraphQL APIs at Netflix, good tools are critical. Today, our GraphQL platform supports engineers across the entire dev lifecycle. However, the nature of developer tooling is rapidly changing.
It’s no longer enough to have a pretty UI if LLMs can’t access it—”agent-friendly” is now table stakes.
In this talk, we'll discuss how our tools have adapted to expose agent-friendly interfaces, allowing agents to seamlessly interact with and utilize them for exploring the graph, building queries, designing schemas, and more.
Finally, how can we leverage the power of AI within the tools themselves? We’ll discuss techniques for superpowering GraphQL tooling via focussed agents with guardrails and feedback loops, increasing accuracy and trust.
Stephen is a member of the Edge API team at Netflix and a member of the GraphQL TSC. His team develops and operates the Netflix API platform. This is the nexus point where hundreds of microservices are aggregated into a single API that delivers the Netflix experience for the hundreds... Read More →
Kavitha Srinivasan is a member of the GraphQL platform team at Netflix that operates one of the largest federated graphs and provides developer tools. She has also been a core contributor and maintainer of the Domain Graph Services framework, an open source framework for building... Read More →
Tuesday May 19, 2026 11:05am - 11:30am PDT Boardroom
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)
How do you expose all the internal tools to the Agents is the question everyone is asking today. Turns out we already expose all the things people can do with our internal tools at Meta through GraphQL and LLM Agents are now able to write GraphQL queries, so... come to this talk to see how both work wonderfully together!
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.
Coding agents are reshaping how we build software. Implementing features, refactoring systems, and shipping changes at a pace unthinkable 6 months ago. But to be successful with agents you need the right feedback loop. One that guides your agent to success, not into the spiral of death.
Ask Claude to add a review system to your product API. Without knowing what's in use, it might reshape your types, move fields, and break your deployed clients because it is missing a crucial feedback loop of what's in use in your clients.
GraphQL changes this. Every client operation explicitly declares the exact fields and types it needs. That gives you something rare: field-level usage data across your entire consumer base. Not endpoint hits, but actual demand, broken down to the individual field.
When coding agents can access this data, they stop guessing. Evolve your schema grounded in reality, not assumptions.
This talk shows how GraphQL's inherent usage visibility and the rise of coding agents create a feedback loop that didn't exist before. And why it matters for anyone building APIs that need to evolve fast.
Michael is a member of the GraphQL Technical Steering Committee, a Microsoft MVP, and Co-Founder and CEO of ChilliCream. He is the creator of Hot Chocolate, a widely used GraphQL server and client platform for .NET, and one of the authors of the Composite Schema specification. Michael... Read More →
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.
After eleven years as an open source technology, GraphQL has never had a more favorable learning curve. Clearer mental models, better educational materials, and a deeper collective understanding of best practices have transformed the “wild west” of 2015 to a much more manageable landscape today.
You and your team are unique, so rather than a one-size-fits-all blueprint I thought I’d present a practical guide to teaching yourself GraphQL in 2026. We’ll examine how beginners typically build their first mental model of GraphQL, the most common misconceptions, and the key design questions they encounter early. Special attention will be paid to different modalities: schema-first vs. code-first, schema design principles, common pitfalls when considering enums, the proper use of fragments, and security and performance by default.
Attendees will leave with a conceptual roadmap for self-study, a recipe book for context engineering in their agent, and an understanding of the major decision points along the journey ahead.
Hi, I'm Jeff! I support the Apollo Client, Apollo iOS, Apollo Kotlin, and Apollo Server engineers at Apollo as a manager. Before going into software I was a trombonist and public school music teacher. In my free time I like to bake Chicago-style deep dish pizzas and French macaro... Read More →
Tuesday May 19, 2026 2:10pm - 2:35pm PDT Boardroom
GraphQL is a technology well-loved by frontend engineers, but often leaves backend engineers struggling with boilerplate code and N+1 performance issues. This talk introduces Joist, a "GraphQL-first" TypeScript ORM that uses codegen, resolver scaffolding, and deep dataloader integration to bring Rails-level productivity to Homebound's 500+ table GraphQL/Postgres majestic monolith.
With two decades of experience, Stephen is a seasoned software engineer known for delivering robust systems that drive business value, while also being a passionate builder at heart, crafting codebases that developers (hopefully!) enjoy working in.
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.
GraphQL offers a popular way for developers to access and interact with data. However, integrating GraphQL with enterprise databases often requires custom middleware, complex resolvers, and maintenance overhead. With Oracle AI Database 26ai, this changes: developers can now use GraphQL queries natively in the database, leveraging automated schema inference and built-in parsing with no loss of performance or scalability.
In this session, we will demonstrate Oracle’s first-class GraphQL integration, including the new table function that lets you run GraphQL queries as native SQL. We will showcase:
- How to map and query relational data with GraphQL, with built-in features for joins, predicates, ordering, & calculations. - How LLMs can generate valid GraphQL queries from natural language, making API access approachable, and why targeting GraphQL via LLMs often delivers safer, better experiences than translating NL to SQL.
Whether you’re an architect modernizing data APIs or a developer working with complex schemas, this session will help you take advantage of the best of both relational databases and the GraphQL ecosystem, with added automation from today’s AI advancements.
I am an engineering manager in the Database Transactions team at Oracle, working on the design and implementation of next-generation Oracle database products. I hold a PhD in Computer Science from Ohio State and an undergraduate degree in Computer Science from BITS-Pilani. My research... Read More →
Our journey implementing federated GraphQL subscriptions in Hive Router, a high-performance federation gateway written in Rust. Covering the architectural decisions and technical challenges we faced bringing real-time capabilities to a federated environment, the engineering work required to support the full spectrum of subscription transports (WebSockets, SSE, Multipart HTTP and HTTP callbacks), and how Rust’s performance characteristics enabled us to handle subscription workloads at scale.
I am a self-taught senior software architect, with a distinguishing trait of resiliently finding simple solutions to complex problems using communication through words and code.
Starting from my first Lego set, I've been in love with development throughout my whole life. As a creator, having the ability to turn thoughts into reality is a gift I find essential. Forever learning through practical applications, bad decisions and positive thoughts - I, ulti... Read More →
Deprecating fields and removing them in GraphQL is tricky itself, but tooling can help identifying such based on statically analysing operations or traffic. But, deprecating inputs is a whole different challenge! Once clients start sending arguments or input object fields, removing or changing them can break integrations in subtle ways, as you do not know which fields might be used in the future and which ones might not, especially if you are running GraphQL at scale. In this lightning talk we will explore possible options for making this whole process more safe in the present, and dip into how it could look in the future!
Laurin Quast is a developer that started exploring GraphQL, by leading API development at a start-up. Realizing that there are still many unsolved problems and challenges within the space, he started contributing to famous JavaScript libraries, such as GraphQL Code Generator. Diving... Read More →
Tuesday May 19, 2026 3:00pm - 3:10pm PDT Boardroom
Every developer has the same instinct when working with AI: take over. Copy the output, fix it by hand, wonder why AI ""doesn't really work."" That instinct is the problem.
When AI-generated code is wrong, the fix isn't editing the code — it's improving the instructions that produced it. This talk teaches that discipline using Agent Skills — open-format markdown workflows — and the GraphQL SDLC as working context. We'll build skills for schema design, resolvers, testing, and docs, developing intuition for when to refine instructions versus when you've hit a model limitation.
You'll leave with transferable techniques, open-source GraphQL skills, and the beginnings of your own agentic intuition.
The steps we took at implementing a GraphQL gateway first in JavaScript, and following those steps in Rust again. Advantages of JavaScript and disadvantage of lack of diversity in the GraphQL Rust ecosystem. Is Rust worth? Is it just performance? How hard was it to rethink everything done in the JavaScript version?
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 →
As teams adopt the Model Context Protocol (MCP), they often run into a new problem: tool sprawl. Every backend API turns into its own MCP server, each with separate schemas, auth, versioning, and deployment concerns. What starts as a clean integration quickly becomes hard to manage. In this talk, I'll show how GraphQL can act as a unifying layer for MCP using GraphQL capabilities like schema introspection and persisted documents. By exposing multiple backend services through a single GraphQL API and connecting it via one MCP server, LLMs gain access to a rich, strongly typed interface without an explosion of tools. We’ll walk through a practical architecture and share patterns for keeping MCP systems scalable, discoverable, and governable beyond early experiments.
Roy Derks is a lifelong software developer, author and public speaker from the Netherlands. Currently chasing his dreams in Silicon Valley, California. Roy's mission is to make the world a better place through technology by inspiring developers all over the world, more specifically... 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.
What we will cover: The "All-or-Nothing" Barrier: We'll analyze the limitations of traditional Document Caching in GraphQL. We will explain why a single personalized field or a volatile "live" value can invalidate an entire response, leading to low cache hit rates and overloaded origin servers.
Partial Query Caching (PQC) Architecture: We will introduce a granular approach to caching. You'll learn how to decompose complex queries into atomic components, separating static fragments from dynamic ones within the same request to dramatically boost cache efficiency.
The Power of the Edge: We'll discuss the benefits of moving the "split-and-merge" logic to the Edge. We will explain how an intelligent Gateway can manage this complexity close to the user, saving expensive compute resources at the origin and reducing latency.
The Next Frontier: PQC meets @defer: To wrap up, we'll demonstrate how combining caching with the GraphQL @defer directive allows us to return cached fragments in milliseconds while streaming the remaining dynamic parts as they resolve.
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.
This presentation explores production-scale GraphQL architecture on AWS, demonstrating how to handle millions of requests and complex data operations at enterprise scale. Drawing from real-world pricing systems that serve thousands of internal clients, we'll examine the architectural decisions behind building resilient, high-performance GraphQL services using AWS AppSync, Lambda, and DynamoDB. The session covers critical production considerations including query optimization strategies, caching layers, connection pooling, and event-driven architectures that power real-time notifications at scale. Attendees will learn how GraphQL simplifies data access across massive datasets while maintaining performance and reliability. We'll discuss scaling patterns, monitoring strategies, and lessons learned from operating GraphQL services that handle billions of daily operations across global marketplaces. This technical deep-dive is designed for engineers interested in understanding how to architect and operate GraphQL systems at huge scale, with practical insights from Amazon's production environments.
Aishwarya is a Software Engineer on Amazon's Retail Pricing Platform team, where she builds the GraphQL based infrastructure that powers pricing data access across Amazon's global marketplace. She's passionate about leveraging GraphQL to simplify complex data access patterns and building... Read More →
Tuesday May 19, 2026 4:40pm - 5:05pm PDT Boardroom
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.
Incrementally adopting GraphQL is hard. The shape of the data differs between REST and GraphQL. Components that were designed for one don't automatically work with the other. And migrating by making multiple network requests can worsen performance unacceptably. And big bang refactors? Well, if you believe those will be successful, I have some oceanfront real estate in Nebraska to sell you.
Is there a better way? Well, what if instead of contorting our frontends for multiple backends, we gave our non-GraphQL backend one crucial property: generated queries that fetch exactly the right data. Then, migrating from one backend to another is as simple (and stress-free) as running an experiment and ramping up a decider!
And Isograph makes that easy! Isograph is an opinionated, compiler-driven framework that makes it easy to build stable, performant data-driven apps, and it generates queries for just the data needed by a given screen. And crucially, it can generate multiple different versions of the same query: GraphQL, SQL, whatever your heart desires.
Finally, adopting GraphQL can be simple, stress-free, and incremental!
Robert Balicki works as a software engineer at Pinterest. He used to have hair down to his shoulders and play in a rock band. He works on Isograph, which you should check out!
