The Case Against __typename

Session description

The GraphQL Schema Documentation (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.