GraphQLConf 2026

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.

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

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.

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

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.

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.

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.

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

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!