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