diff --git a/scripts/sync-sched/schedule-2026.json b/scripts/sync-sched/schedule-2026.json index a429ec8caa..cf9a456766 100644 --- a/scripts/sync-sched/schedule-2026.json +++ b/scripts/sync-sched/schedule-2026.json @@ -8,7 +8,7 @@ "event_end": "2026-05-06 17:45", "event_type": "Registration + Badge Pick-up", "description": "", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "TBA", @@ -44,7 +44,7 @@ "event_end": "2026-05-06 09:25", "event_type": "Keynote Sessions", "description": "", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -80,7 +80,7 @@ "event_end": "2026-05-06 09:45", "event_type": "Keynote Sessions", "description": "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. \n \nThis 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.\n \nWhether 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.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -133,7 +133,7 @@ "event_end": "2026-05-06 09:55", "event_type": "Keynote Sessions", "description": "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.\n \nThe 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\".\n \nBut 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!", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -179,7 +179,7 @@ "event_end": "2026-05-06 10:15", "event_type": "Keynote Sessions", "description": "", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -215,7 +215,7 @@ "event_end": "2026-05-06 10:35", "event_type": "Breaks + Networking + Special Events", "description": "", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "TBA", @@ -287,7 +287,7 @@ "event_end": "2026-05-06 11:00", "event_type": "AI and LLMs", "description": "How do you make one of the world's largest federated graphs accessible to token-constrained LLM minions?\n \nWith 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.\n \nIt’s no longer enough to have a pretty UI if LLMs can’t access it—”agent-friendly” is now table stakes. \n \nIn 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. \n \nFinally, 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.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -393,7 +393,7 @@ "event_end": "2026-05-06 11:35", "event_type": "Servers", "description": "React Server Components (RSC) and GraphQL have considerable overlap in the problems they seek to solve. This makes them competitors in some scenarios.\n \nIn 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.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -439,7 +439,7 @@ "event_end": "2026-05-06 11:35", "event_type": "Trends", "description": "Using GraphQL for service-to-service communication has historically been....frowned upon. Certainly, in isolation, there are compelling alternatives (gRPC, thrift, good ol' REST).\n \nBut 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!\n \nYou 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.\n \nThis talk lays out why and when this makes sense, and what patterns are helpful to achieve this.\n \n(ATTN: CFP reviewers -- fwiw the title is referencing https://productionreadygraphql.com/blog/2020-05-14-sweetspot)", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -485,7 +485,7 @@ "event_end": "2026-05-06 12:10", "event_type": "Performance", "description": "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.\n \nHere’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.\n \nThis talk will cover:\n \n* Why depth-first has hidden costs that scale linearly.\n* How breadth-first inverts the cost model.\n* Why dataloaders are a hack.\n* The trade-offs we accepted.\n* How we're incrementally migrating to breadth execution.\n \nIf 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.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -623,7 +623,7 @@ "event_end": "2026-05-06 12:10", "event_type": "AI and LLMs", "description": "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!", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -669,7 +669,7 @@ "event_end": "2026-05-06 13:25", "event_type": "Breaks + Networking + Special Events", "description": "", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Cafeteria", @@ -705,7 +705,7 @@ "event_end": "2026-05-06 13:50", "event_type": "AI and LLMs", "description": "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.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Cortes Bank", @@ -842,7 +842,7 @@ "event_end": "2026-05-06 14:25", "event_type": "Tooling + DX + Testing + Documentation", "description": "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.\n \nYou 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.\n \nAttendees 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.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -934,7 +934,7 @@ "event_end": "2026-05-06 15:00", "event_type": "Federation + Distributed Systems", "description": "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.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -1026,7 +1026,7 @@ "event_end": "2026-05-06 15:00", "event_type": "Schema Design + Evolution + Governance", "description": "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!", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -1118,7 +1118,7 @@ "event_end": "2026-05-06 15:35", "event_type": "Security", "description": "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.\n \nWe 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.\n \nAttendees will learn to:\n- Navigate the Risk Primer: Translate GraphQL features (types, fields, directives) into risk language to build organizational trust.\n- Shift Security Left: Automate security with secure frameworks & replacing manual reviews.\n- Architect for Data Isolation: Use of fine grained access to manage entitlements and prevent unauthorized data exposure.\n- Harden the Control Plane: Reduce attack surface using technical strategies like disabling introspection and enforcing persisted query ownership.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Cortes Bank", @@ -1164,7 +1164,7 @@ "event_end": "2026-05-06 15:55", "event_type": "Breaks + Networking + Special Events", "description": "", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "TBA", @@ -1246,7 +1246,7 @@ "event_end": "2026-05-06 16:20", "event_type": "Clients", "description": "Trusted documents (persisted queries) are one of the most powerful tools in the GraphQL security and performance toolkit. By restricting your API to only pre-approved operations, you eliminate entire classes of attacks, reduce payload sizes, and gain full visibility into client behavior. Yet most struggle to adopt them – the tooling is fragmented, the workflow is manual, and the deployment story is an afterthought.\n \nWhat if your entire platform natively supported trusted documents from end to end? In this talk, I’ll show what becomes possible when persisted queries are first-class citizens of your GraphQL platform – from registration and version through CI/CD validation to production deployment and rollback. But trusted documents aren’t just for GraphQL clients. I’ll explore how they unlock new capabilities: exposing GraphQL operations as simple REST endpoints, and even powering MCP tools for AI agents – all built on the same foundation of pre-approved, governed operations.\n \nYou’ll leave with a clear picture of what a complete trusted documents platform looks like and practical steps to get there.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -1338,7 +1338,7 @@ "event_end": "2026-05-06 16:55", "event_type": "Federation + Distributed Systems", "description": "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. \n \nMeta’s architectural philosophy favors federation to support a monolithic architecture over traditional microservices.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -1451,7 +1451,7 @@ "event_end": "2026-05-06 17:30", "event_type": "Observability + Telemetry + Tracing", "description": "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?\n \nThe primitives of GraphQL federation are simple: Entities with keys to uniquely identify them, distributed across multiple services.\n \nThe story they tell? It's a fascinating one, but nobody talks about it. Until now.\nAnd 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.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -1497,7 +1497,7 @@ "event_end": "2026-05-06 17:30", "event_type": "Other", "description": "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. \n \nIs 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!\n \nAnd 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.\n \nFinally, adopting GraphQL can be simple, stress-free, and incremental!", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -1625,7 +1625,7 @@ "event_end": "2026-05-07 10:00", "event_type": "All Hands Meeting", "description": "", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -1661,7 +1661,7 @@ "event_end": "2026-05-07 10:15", "event_type": "Breaks + Networking + Special Events", "description": "", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "TBA", @@ -1779,7 +1779,7 @@ "event_end": "2026-05-07 10:40", "event_type": "Schema Design + Evolution + Governance", "description": "How do you power a product where every page layout, module, and slice of content can change daily—across hundreds of millions of devices—without shipping a new client every time? In this talk, we’ll dive into how Netflix evolved its GraphQL APIs from traditional “data fetching” into a server‑driven UI platform, enabling rapid product innovation and page updates without requiring app releases across a massive device ecosystem. We’ll walk through the architecture that lets servers describe dynamic page structure and behavior, how those contracts scale across many product surfaces and experiments, and the performance and reliability lessons we learned operating this at Netflix scale. When we built this system, we found almost no public examples of similar patterns, so this session is intentionally practical: we’ll share concrete schema patterns, client rendering strategies, and tips you can apply to your own feeds, homepages, and highly dynamic experiences—whether you’re working at Netflix scale or just starting to stretch GraphQL beyond CRUD.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -1816,6 +1816,51 @@ "end_time": "10:40:00", "event_subtype": "" }, + { + "event_key": "1147393", + "active": "Y", + "pinned": "N", + "name": "GraphQLShield: CWE-Aware Defense in Depth for GraphQL APIs in Go - Ravi Sastry Kadali, Samsung", + "event_start": "2026-05-07 10:15", + "event_end": "2026-05-07 10:25", + "event_type": "Security", + "description": "GraphQL APIs face a unique threat landscape: deeply nested queries cause resource exhaustion, introspection exposes entire schemas, and mutation variables carry injection payloads past traditional WAFs. Yet most Go-based GraphQL servers ship with zero security middleware between HTTP and resolver execution.\n\nI introduce GraphQLShield, an open-source Go middleware bringing defense-in-depth to GraphQL APIs through three layers: (1) Static schema analysis detecting cyclic types, missing depth limits, and sensitive field exposure before deployment; (2) Runtime CWE-aware input sanitization catching SQL injection, XSS, command injection, path traversal, and NoSQL injection in GraphQL variables — bridging go-safeinput’s MITRE CWE Top 25 coverage to GraphQL; and (3) Resolver code auditing inspired by gosec and cryptoguard-go flagging insecure crypto, hardcoded secrets, and missing auth checks.\n\nA quick demo shows GraphQLShield intercepting 7 attack vectors against a gqlgen API, from SQL injection in mutation variables to depth-based DoS, while legitimate requests pass cleanly. Attendees leave with a zero-dependency Go library covering 14 CWE vulnerability classes across static and runtime analysis.", + "goers": "0", + "seats": "0", + "invite_only": "N", + "venue": "Transbay Tube", + "audience": "Intermediate", + "id": "730a36f1934e8c81b852400070bf08d3", + "venue_id": "2288547", + "speakers": [ + { + "username": "ravisastryk", + "id": "10492261", + "name": "Ravi Sastry Kadali", + "custom_order": 0 + } + ], + "event_start_year": "2026", + "event_start_month": "May", + "event_start_month_short": "May", + "event_start_day": "7", + "event_start_weekday": "Thursday", + "event_start_weekday_short": "Thu", + "event_start_time": "10:15am", + "event_end_year": "2026", + "event_end_month": "May", + "event_end_month_short": "May", + "event_end_day": "7", + "event_end_weekday": "Thursday", + "event_end_weekday_short": "Thu", + "event_end_time": "10:25am", + "start_date": "2026-05-07", + "start_time": "10:15:00", + "start_time_ts": 1778174100, + "end_date": "2026-05-07", + "end_time": "10:25:00", + "event_subtype": "" + }, { "event_key": "1139871", "active": "Y", @@ -1825,7 +1870,7 @@ "event_end": "2026-05-07 10:40", "event_type": "Clients", "description": "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.\n \nThis 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.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -1917,7 +1962,7 @@ "event_end": "2026-05-07 11:15", "event_type": "Clients", "description": "Use Apollo Client v4 in React with Tanstack Router. \n \nWe’ll be using GraphQL code generation from your schema, preloading data at the router level, optmistic updates, and using Apollo’s cache to eliminate unnecessary refetching and rerenders. You’ll see how smart cache usage and colocating queries lets components read data directly where they need it which will reduce prop drilling. The goal is to show how “modern” Apollo Client patterns fit naturally into today’s React architecture to create apps that feel both simpler to reason about and noticeably more performant.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Cortes Bank", @@ -1963,7 +2008,7 @@ "event_end": "2026-05-07 11:15", "event_type": "Performance", "description": "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.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -2055,7 +2100,7 @@ "event_end": "2026-05-07 11:50", "event_type": "Clients", "description": "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.\n \nIn 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.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -2193,7 +2238,7 @@ "event_end": "2026-05-07 12:25", "event_type": "Schema Design + Evolution + Governance", "description": "Abstract: Schema governance shouldn’t grind development to a halt or burn out graph stewardship teams. As Intuit’s Supergraph ecosystem grew, our reliance on manual schema reviews created bottlenecks that slowed onboarding and frustrated developers. We knew we needed a better approach — so we built a hybrid governance model that puts Schema Co-Pilot directly into the developer workflow and transformed our \"API Jedis\" from gatekeepers into enablers.\n \nIn this talk, you’ll learn how we built real-time IDE linting, AI-powered schema analysis, and semantic “collision” detection to surface issues before code is even committed. With these tools in place, onboarding timelines shrank from weeks to days, and contributors now ship to the graph with speed and confidence.\n \nWho should attend: Platform engineers, API architects, and engineering leaders responsible for GraphQL governance and developer experience.\n \nKey takeaway: Governance isn’t about gatekeeping — it’s about building smart tools that help your teams move faster with confidence.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Cortes Bank", @@ -2239,7 +2284,7 @@ "event_end": "2026-05-07 12:25", "event_type": "Tooling + DX + Testing + Documentation", "description": "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.\n \nIn 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.\n \nWe'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.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -2292,7 +2337,7 @@ "event_end": "2026-05-07 13:40", "event_type": "Breaks + Networking + Special Events", "description": "", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Cafeteria", @@ -2374,7 +2419,7 @@ "event_end": "2026-05-07 14:05", "event_type": "Servers", "description": "A new approach to GraphQL execution, enabling engineers to build next-level efficiency into new or existing GraphQL APIs. This declarative approach to execution eliminates the many pitfalls of traditional resolvers and optimizes communications with your business logic. This is achieved through understanding the request's full data requirements and planning the best batched execution strategy before requesting anything from the business logic. This decoupling of data fetching from the GraphQL request shape results in fewer and more efficient operations against your backend services and data sources, eliminating both over- and under-fetching on the backend along with deduplication of redundant work, leading to reduced operational costs and delightful user experiences! A passion project of a founding GraphQL TSC member, this MIT-licensed open source technology has already been in production at a number of companies for over a year!", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -2429,7 +2474,7 @@ "venue_id": "2294963", "speakers": [ { - "username": "james1756", + "username": "jbellenger", "id": "24421556", "name": "James Bellenger", "company": "Airbnb", @@ -2512,7 +2557,7 @@ "event_end": "2026-05-07 14:40", "event_type": "Federation + Distributed Systems", "description": "The GraphQL community has come together to standardize how distributed systems can be built with GraphQL as an orchestrator.\n \nIn this talk, I will outline our vision for GraphQL as an orchestration layer and explain how the emerging Composite Schema specification addresses the challenges of composing distributed graphs. We’ll review the progress made since the last GraphQLConf within the Composite Schema Working Group and take a look at early RFCs and experimental prototypes.\n \nThe specification builds on the strongest ideas from existing federation approaches in the ecosystem, distilling them into a vendor-neutral standard. Its goal is to enable interoperability — allowing vendors, platform teams, and open-source projects to implement the specification, or parts of it, in a way that integrates seamlessly across tools and ecosystems.\n \nThis session is a community update on the work happening under the GraphQL Foundation to standardize Federation: the problems we are solving, the principles guiding the design, and what comes next.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -2604,7 +2649,7 @@ "event_end": "2026-05-07 14:40", "event_type": "Tooling + DX + Testing + Documentation", "description": "Modern GraphQL clients are expected to do far more than execute queries. From supporting pagination to incrementally re-analyzing documents as they change, the demand for fast, scalable static analysis has never been higher.\n \nBut what does it take to build tooling that meets these demands? How do you support a wide and ever-growing set of features without sacrificing performance or maintainability?\n \nIn this talk, Alec explores the design of Houdini’s new compiler, sharing a somewhat unconventional architecture and the lessons learned along the way.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -2650,7 +2695,7 @@ "event_end": "2026-05-07 15:15", "event_type": "AI and LLMs", "description": "Producing valid and realistic mock data for prototyping and testing has been an unsolved challenge for years. Mock data is tedious to write and maintain, but attempts to improve the process such as random value generation and field stubbing fall short as they lack essential domain context to make test data realistic and meaningful.\nIn this talk, I’ll share how we’ve reimagined GraphQL mocking at Airbnb by combining existing GraphQL infrastructure, rich product and schema context, and LLMs to generate convincing, type-safe mock data simply by adding a directive (@generateMock) to a field or operation:\n- How integrating LLMs that are highly contextualized by a schema, documentation, and UX design into existing GraphQL tools drives a leap forward in the speed and quality of mock data creation.\n- How a directive-driven approach lets engineers generate production-like, schema-conformant mock data without writing code.\n- How integrating generated mock data into the GraphQL client runtime can enable engineers to build and test clients before server implementation.\n- How this strategy guarantees that generated mock data is correct, deterministic, and stays in-sync with the server schema.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -2742,7 +2787,7 @@ "event_end": "2026-05-07 15:15", "event_type": "Tooling + DX + Testing + Documentation", "description": "Last year, we explored why the \"Graph\" in GraphQL matters. This year, the graph awakens to its full potential.\n \nBuilding on 10 years of schema visualization experience, I'll reveal advanced techniques that make even massive, complex schemas readable and intuitive. We'll explore cutting-edge layout algorithms and visualization methods that go beyond what existing tools offer.\n \nBut here's the revelation: graphs aren't just for viewing, they're for understanding. I'll show how graph metrics and analytics can reveal hidden characteristics of your schemas, providing insights into complexity, coupling, and design patterns that are invisible in traditional documentation.\n \nThis isn't just about prettier diagrams. It's about using graph theory to support schema analysis, optimization, and architectural decisions.\n \nJoin me to see GraphQL schemas in ways you never imagined possible and discover what makes the \"Graph\" in GraphQL truly powerful beyond just visualization.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -2788,7 +2833,7 @@ "event_end": "2026-05-07 15:35", "event_type": "Breaks + Networking + Special Events", "description": "", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "TBA", @@ -2824,7 +2869,7 @@ "event_end": "2026-05-07 16:00", "event_type": "Observability + Telemetry + Tracing", "description": "Viaduct, Airbnb's unified data access layer, hosts over 1.5M lines of application code from 500+ tenants, with 200+ changes merged daily—all operating as a single service. At this scale, enabling teams to independently monitor and troubleshoot their code is essential. \nThis talk describes how we approach observability with multitenancy at the core: \n- Establishing clear ownership of modules and attributing metrics, spans, and errors to those owners \n- Providing alerts and dashboards at multiple levels: system, operation, tenant, and field\n- Enabling schema-driven alerting, where tenants declaratively specify monitoring requirements directly in the schema and the platform implements them automatically\n- Using execution traces to visualize query execution and core-tenant interactions, tackling challenges like:\n- Representing batched dataloader calls (where N field requests become 1 RPC)\n- Instrumenting downstream service clients across all data-fetching code\n- Managing observability costs via selective sampling and cardinality-aware metrics \n \nOur goal: empower tenants to manage their portion of Viaduct as a standalone service—without bottlenecking on the platform team.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", @@ -2870,7 +2915,7 @@ "event_end": "2026-05-07 16:00", "event_type": "Servers", "description": "What if a city could run as a GraphQL server?\n \nIn 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.\n \nUsing 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.\n \nWe introduce a lightweight Skills SDK that abstracts runtime configuration and enforces clear ownership rules, making modular graph design approachable.\n \nFinally, we connect an AI client to the server to demonstrate structured, explainable reasoning over live city data.\n \nAll demo code and schema modules will be open sourced for attendees to explore and extend.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -2960,6 +3005,73 @@ "end_time": "16:00:00", "event_subtype": "" }, + { + "event_key": "1147394", + "active": "Y", + "pinned": "N", + "name": "From Query to Conversation: GraphQL as an AI Interface Layer - Hugh Nguyen, Ben Golub, Adam Conrad & Kewei Qu, Meta", + "event_start": "2026-05-07 16:10", + "event_end": "2026-05-07 16:35", + "event_type": "AI and LLMs", + "description": "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.\nThis 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.\nKey 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\nLessons 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.", + "goers": "0", + "seats": "0", + "invite_only": "N", + "venue": "Transbay Tube", + "audience": "Intermediate", + "id": "da2cf64328dde7c25f0ca728a21fa034", + "venue_id": "2288547", + "speakers": [ + { + "username": "qkw1221", + "id": "18743864", + "name": "Kewei Qu", + "company": "Meta", + "custom_order": 0 + }, + { + "username": "htnguyen203", + "id": "24427739", + "name": "Hugh Nguyen", + "company": "Meta", + "custom_order": 1 + }, + { + "username": "benjamin.golub", + "id": "24427748", + "name": "Ben Golub", + "company": "Meta", + "custom_order": 2 + }, + { + "username": "acon2", + "id": "24427754", + "name": "Adam Conrad", + "company": "Meta", + "custom_order": 3 + } + ], + "event_start_year": "2026", + "event_start_month": "May", + "event_start_month_short": "May", + "event_start_day": "7", + "event_start_weekday": "Thursday", + "event_start_weekday_short": "Thu", + "event_start_time": "4:10pm", + "event_end_year": "2026", + "event_end_month": "May", + "event_end_month_short": "May", + "event_end_day": "7", + "event_end_weekday": "Thursday", + "event_end_weekday_short": "Thu", + "event_end_time": "4:35pm", + "start_date": "2026-05-07", + "start_time": "16:10:00", + "start_time_ts": 1778195400, + "end_date": "2026-05-07", + "end_time": "16:35:00", + "event_subtype": "" + }, { "event_key": "1144108", "active": "Y", @@ -2969,7 +3081,7 @@ "event_end": "2026-05-07 16:35", "event_type": "Observability + Telemetry + Tracing", "description": "To run GraphQL in production with confidence, we need more than just uptime checks and HTTP 200 - we need deep visibility into the graph itself.\n \nIn this talk, we will explore how to implement the three pillars of observability: traces, metrics, and logs - specifically for GraphQL. \n \nWe'll explore OTel and GraphQL, allowing you to trace requests from the gateway down to individual Federation subgraphs and deeper.\n \nFinally, we will look at how to leverage dedicated tooling like Hive Console to make sense of this data.", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Peahi", @@ -3061,7 +3173,7 @@ "event_end": "2026-05-07 17:15", "event_type": "Keynote Sessions", "description": "", - "goers": "0", + "goers": "1", "seats": "0", "invite_only": "N", "venue": "Transbay Tube", diff --git a/scripts/sync-sched/speakers.json b/scripts/sync-sched/speakers.json index 59bc1d3f73..25079bbb68 100644 --- a/scripts/sync-sched/speakers.json +++ b/scripts/sync-sched/speakers.json @@ -53,6 +53,20 @@ ], "~syncedDetailsAt": 1749568381879 }, + { + "username": "acon2", + "company": "Meta", + "position": "Engineering Manager", + "name": "Adam Conrad", + "about": "Engineering Manager for integrating GraphQL in our mobile applications at Meta. Previously focused on React at Meta.", + "location": "Boston, MA", + "url": "https://www.adamconrad.dev", + "avatar": "//avatars.sched.co/a/b5/24427754/avatar.jpg.320x320px.jpg?834", + "socialurls": [], + "_years": [ + 2026 + ] + }, { "username": "adam_malone.2791s6x2", "company": "Hasura", @@ -649,6 +663,20 @@ ], "~syncedDetailsAt": 1758551361502 }, + { + "username": "benjamin.golub", + "company": "Meta", + "position": "Software Engineer", + "name": "Ben Golub", + "about": "Ben has been with Meta (then Facebook) since 2009 and has worked on the Graph API, GraphQL, Hack, HHVM, and more.", + "location": "", + "url": "", + "avatar": "//avatars.sched.co/f/f1/24427748/avatar.jpg.320x320px.jpg?75b", + "socialurls": [], + "_years": [ + 2026 + ] + }, { "username": "benjamin154", "company": "Grafbase", @@ -885,7 +913,7 @@ "company": "Stax.ai", "position": "Head of Engineering", "name": "Cameron Sechrist", - "about": "Cameron Sechrist is a dynamic software engineer, seasoned entrepreneur, and compliance expert with over a decade of experience driving technological innovation and ensuring robust data security across diverse industries. His entrepreneurial journey began remarkably early, with his first company founded at the age of 15, a path that has since led to three successful company exits. Outside of work, Cam enjoys hanging with his puppies, Hope and Eddie.", + "about": "Cameron Sechrist is a dynamic software engineer, seasoned entrepreneur, and compliance expert with over a decade of experience driving technological innovation and ensuring robust data security across diverse industries. His entrepreneurial journey began remarkably early, with his first company founded at the age of 15, a path that has since led to three successful company exits. Outside of work, Cam enjoys hanging with his puppy, Hope.", "location": "", "url": "", "avatar": "//avatars.sched.co/8/da/24421523/avatar.jpg.320x320px.jpg?6ce", @@ -1635,6 +1663,20 @@ ], "~syncedDetailsAt": 1772651522172 }, + { + "username": "htnguyen203", + "company": "Meta", + "position": "Software Engineer", + "name": "Hugh Nguyen", + "about": "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.", + "location": "", + "url": "", + "avatar": "//avatars.sched.co/d/03/24427739/avatar.jpg.320x320px.jpg?4bf", + "socialurls": [], + "_years": [ + 2026 + ] + }, { "username": "idit_levine.25krdj4u", "company": "Solo.io", @@ -1711,21 +1753,6 @@ ], "~syncedDetailsAt": 1758137788992 }, - { - "username": "james1756", - "company": "Airbnb", - "position": "Engineer", - "name": "James Bellenger", - "about": "Running and baking enthusiast.", - "location": "", - "url": "", - "avatar": "//avatars.sched.co/5/ff/24421556/avatar.jpg.320x320px.jpg?51d", - "socialurls": [], - "_years": [ - 2026 - ], - "~syncedDetailsAt": 1772651522172 - }, { "username": "jamie855", "company": "Grafbase", @@ -1821,6 +1848,20 @@ ], "~syncedDetailsAt": 1758551366618 }, + { + "username": "jbellenger", + "company": "Airbnb", + "position": "Engineer", + "name": "James Bellenger", + "about": "Running and baking enthusiast.", + "location": "", + "url": "", + "avatar": "//avatars.sched.co/5/ff/24421556/avatar.jpg.320x320px.jpg?51d", + "socialurls": [], + "_years": [ + 2026 + ] + }, { "username": "jeanleonino", "company": "ConfrariaTech", @@ -2202,7 +2243,8 @@ "socialurls": [], "_years": [ 2026 - ] + ], + "~syncedDetailsAt": 1772752087196 }, { "username": "laurent57", @@ -2424,7 +2466,8 @@ "socialurls": [], "_years": [ 2026 - ] + ], + "~syncedDetailsAt": 1772752087196 }, { "username": "mansi.mittal", @@ -2776,7 +2819,8 @@ "socialurls": [], "_years": [ 2026 - ] + ], + "~syncedDetailsAt": 1772752087196 }, { "username": "minghe.huang", @@ -2805,7 +2849,8 @@ "socialurls": [], "_years": [ 2026 - ] + ], + "~syncedDetailsAt": 1772752087196 }, { "username": "oleksandr_bidiuk", @@ -2819,7 +2864,8 @@ "socialurls": [], "_years": [ 2026 - ] + ], + "~syncedDetailsAt": 1772752087196 }, { "username": "omribruchim", @@ -2952,7 +2998,7 @@ "about": "TBD", "location": "", "url": "", - "avatar": "//avatars.sched.co/9/1a/18743864/avatar.jpg.320x320px.jpg?7fa", + "avatar": "//avatars.sched.co/9/1a/18743864/avatar.jpg.320x320px.jpg?18e", "socialurls": [], "_years": [ 2023, @@ -2994,7 +3040,8 @@ "socialurls": [], "_years": [ 2026 - ] + ], + "~syncedDetailsAt": 1772752087196 }, { "username": "rama_palaniappan", @@ -3035,6 +3082,20 @@ ], "~syncedDetailsAt": 1749502056389 }, + { + "username": "ravisastryk", + "company": "", + "position": "Engineering Leader | Go Ecosystem Contributor | Security Tooling Author", + "name": "Ravi Sastry Kadali", + "about": "Ravi Sastry Kadali is a Tech Lead, Staff Engineer at Samsung with two decades of security expertise. He built platform integrity systems at Meta protecting 3B+ users, delivered Windows releases at Microsoft, and developed intrusion detection systems for India's Defense R&D Org. An active open-source contributor to Kubernetes, etcd, gosec, gqlgen, he created the go-safeinput and cryptoguard-go libraries. Kadali is an IEEE Senior Member with awards for Outstanding Achievement in Cybersecurity.", + "location": "", + "url": "", + "avatar": "//avatars.sched.co/3/ce/10492261/avatar.jpg.320x320px.jpg?e74", + "socialurls": [], + "_years": [ + 2026 + ] + }, { "username": "raymie2", "company": "Airbnb", @@ -3067,7 +3128,8 @@ "socialurls": [], "_years": [ 2026 - ] + ], + "~syncedDetailsAt": 1772752087196 }, { "username": "rickbijkerk54", @@ -3140,7 +3202,8 @@ "socialurls": [], "_years": [ 2026 - ] + ], + "~syncedDetailsAt": 1772752087196 }, { "username": "ruben.cagnie", @@ -3345,7 +3408,8 @@ "socialurls": [], "_years": [ 2026 - ] + ], + "~syncedDetailsAt": 1772752087196 }, { "username": "serhii.korin", @@ -3403,7 +3467,8 @@ "socialurls": [], "_years": [ 2026 - ] + ], + "~syncedDetailsAt": 1772752087196 }, { "username": "shashank.gugnani",