GraphQLConf 2026

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!

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.

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!

GraphQL simplifies client development through flexible, expressive data queries. However, in serverless production environments, that flexibility can quietly increase latency and infrastructure cost.

In AWS-based architectures using Lambda, DynamoDB, Aurora Serverless, and distributed services, resolver design and query structure directly impact execution time, cold starts, and overall spend. Unlike REST, GraphQL shifts cost dynamics to query complexity and resolver fan-out, and often in ways teams don’t anticipate until production traffic scales.

This session examines common performance and cost anti-patterns in serverless GraphQL systems, including N+1 resolver cascades, unbounded query depth, over-fetching, and inefficient resolver fan-out. We’ll explore how these patterns affect Lambda duration, concurrency, and downstream data stores.

Attendees will learn practical mitigation strategies such as batching with DataLoader, caching and persisted queries, query complexity limits, schema guardrails, and observability techniques to detect bottlenecks early.

GraphQL Codegen has been the go-to tool for generating types for GraphQL clients for over a decade. But as use cases grew, so did the friction: excessive generated code, complex setups, and growing confusion among users on how to use the output.

In this talk, we'll explore a new client-focused Codegen setup that rethinks those trade-offs. You'll see how we drastically reduce generated output, ensure correct and predictable types, and provide a smooth migration path from existing tools without sacrificing flexibility or safety.

We'll also dive into the story behind the change: a collaboration between Eddy (The Guild) and Igor (Yelp), sparked by a single question and shaped by open discussion across time zones. It’s a look at how community feedback, real-world constraints, and trust can drive the biggest evolution in Codegen’s history.

We built a real-time system for Postgres→React sync using a `LISTEN/NOTIFY` Postgres trigger, GraphQL `@live` queries, a React hook and a custom ORM-inspired GraphQL query builder. Starting from ESP32 microcontroller devices sending MQTT messages and a Node/Postgres backend, we moved from polling to a stand-alone PoC with Yoga, Prisma triggers, and a custom `useLiveQuery` hook. After proving that the PoC was working we integrated with all our existing full-stack apps. So now we have low-latency UI updates, reusable cross-app logic, and easier extension for new sensor values. Great UX and excellent DX.

TOC

- Title & minimal intro
- Goals (What We Needed)
- Existing System (What We Had)
- Attempts & Why They Failed
- Solution Overview
- Postgres `LISTEN/NOTIFY`
- `useLiveQuery` React hook
- Yoga and Apollo `@live` integration
- GraphQL query builder
- GraphQL SDL generator
- GraphQL resolver generator
- Demo / Results
- Tradeoffs, Lessons & Next Steps
- Q&A

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.