GraphQLConf 2026

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.