Skip to main content

Class 11: Case Study: Meta/Relay and Netflix DGS

Duration: 15 minutes | Difficulty: Intermediate | Prerequisites: Class 8 of this course.

This class grounds Classes 2, 7, and 8 in their origins. Every statement about Meta's or Netflix's practice below traces to a public written or recorded source, linked where made; where the public record establishes less than commonly repeated claims, this class limits itself to what the sources support.

What You'll Learn​

By the end of this class, you will:

  • Trace the documented path from Relay's nullable-by-default ergonomics problem to the Class 8 proposal
  • Know the public record: the working-group RFCs, the GraphQLConf 2024 talks, and Relay's shipping implementation
  • Understand Netflix DGS as the packaging of Class 4's discipline into framework defaults
  • See what client-driven and server-driven error design each contribute, which the API-vendor case studies of Classes 9 and 10 leave out

Meta and Relay: the client that felt the pain first​

The API case studies of Classes 9 and 10 were server-side designs serving external developers. Meta's position is inverted: GraphQL started at Facebook as an API for its own apps, and Relay is the client Meta built for its product teams. When error-handling design fails there, the cost lands on every product team's components, and semantic nullability came out of that experience. This section cites the public sources for that story.

The starting condition is the nullable-by-default posture whose official reasoning Class 2 quoted. Relay's own semantic nullability guide explains that GraphQL's field-granular error handling "depends upon field nullability", which is why defaulting fields to nullable became the recommended practice. It states the resulting trade plainly:

This creates a trade-off where enabling maximum resiliency means client developers must manually handle all possible permutations of field nullability within their components.

The path from that ergonomics problem to a specification effort is also publicly documented:

  • The GraphQLConf 2024 talk. Jordan Eldredge, a software engineer at Meta and one of the names Class 8 credited, presented the diagnosis in "Semantic Nullability: A Path Toward Safe Non-Null Fields". The published abstract describes field-granular error handling as one of GraphQL's "killer features" that has "traditionally come at the cost of developer ergonomics". It promises to let clients "see" the true nullability of the server's resolvers, without sacrificing response resiliency.
  • The working group's RFC. The SemanticNullability RFC records his earlier working-group proposal, that making fields nullable to handle error propagation was hiding the "true" nullability of the data. It also records the path from the client-controlled nullability attempt (Class 8's PR #895) through its abandonment to the current design.
  • His own post. His post announcing the talk summarises the same diagnosis and links the recording.
  • The nullability panel. The same conference hosted "The Billion D∅llar Panel: Nullability in GraphQL", with Eldredge and Janette Cheng from Meta, Stephen Spalding from Netflix, Alex Reilly, and Benjie Gillam, whose draft blog post Class 8 quotes. The panel's title gives the cost framing under which the industry discusses the ambiguous null.

Meta is a central case study because Relay ships the receiving end. Class 7 covered the directives as client features; read them now as the case study's evidence. The semantic nullability guide describes it:

Relay will look for @semanticNonNull directives in your schema and generate non-nullable Flow/TypeScript types for those fields if you enable client-side error handling for your query or fragment by adding the @throwOnFieldError directive.

The @catch directive guide documents the same typing rule for caught fields. That closes the argument of Classes 2, 7, and 8. The schema tells the truth about the domain, the component declares what it does about errors, and the type system rewards the declaration with the true types. Relay shipped this behavior before the specification work concluded, and the current specification proposal generalizes what Relay already does.

The lesson from Meta's half of the class is that error-handling design driven from the client's lived experience produces different, and in this case better, primitives than design driven from the server's convenience. Every server-side pattern in this course, whether error codes, error taxonomies or response types, organizes what the server sends. Meta's contribution is the machinery for what components can safely assume. Relay was positioned to build it because Meta's scale made the cost of the ambiguous null visible across many product components.

Netflix DGS: discipline as a default​

Netflix's contribution to this course's material is quieter, and it is the most directly relevant to this site's Java track. The DGS framework took the classification discipline that Class 4 taught as design work, and made it the out-of-the-box behavior for every Spring team that adopts the framework.

Class 4 surveyed the substance, so this section weighs its significance as a case study. The DGS error handling documentation defines three things:

  • The eight-value errorType enum, with HTTP analogs.
  • The layered extensions structure: errorType, errorDetail, origin, debugInfo, debugUri.
  • TypedGraphQLError with its builders, as the vehicle.

The framework's default exception handler emits this shape without configuration.

Custom handling slots in two ways. The first is Spring for GraphQL's @ControllerAdvice with @GraphQlExceptionHandler methods, which the DGS documentation calls "the easiest way" to map exceptions. The second is a DataFetcherExceptionHandler that delegates to the framework default; our Netflix DGS course, coming soon, shows it hands-on. The typed error design comes from Studio Edge at Netflix: the DGS documentation says that "in Studio Edge we would like to have a stronger, more expressive contract", and it publishes the resulting types as framework defaults. Every service that adopts DGS emits errors classified the same way, without its team designing a vocabulary.

That is the case-study point. Three organizations in this course standardized their errors, each with a different mechanism:

  • Shopify standardized errors across an API for external developers, through documentation.
  • GitLab standardized them across contributors, through its styleguide and review policy.
  • Netflix standardized them across a fleet of services, through framework code.

All three organizations treat error classification as a contract that holds across the organization. Netflix's mechanism asks the least of each team, because the framework's default behavior already emits the right shape. Its UNKNOWN value encodes Class 4's honesty rule: a classification system needs a way to say "not yet classified" that differs from every real category. Netflix's presence on the nullability panel above, in the person of Stephen Spalding, connects the two efforts. The company that packaged server-side classification also took part in the nullability working group, which was archived in February 2026. At Netflix's scale both halves of error handling are treated as shared infrastructure.

What the pair teaches together​

Meta and Netflix bracket the API vendors of Classes 9 and 10 from both sides:

  • The vendors show what to put on the wire.
  • Meta shows what clients need to assume about the wire.
  • Netflix shows how a whole organization emits the wire format without each team having to care.

For your own stack the composition is direct, and it matches the recommendations the earlier classes made individually:

  • Take DGS-style classification as the server default (Classes 4 and 6).
  • Take Shopify-style typed outcomes where user input is involved (Classes 5 and 9).
  • Take GitLab-style written placement rules (Class 10).
  • Take Relay-style semantic honesty as the contract you migrate toward (Classes 7 and 8).

Summary​

Meta's case is the client-side origin story of Class 8, and all of it is documented in public:

  • Nullable-by-default resiliency cost every product component its ergonomics, a trade Relay's own guide states.
  • Jordan Eldredge named the diagnosis in the working group and carried it to GraphQLConf 2024: making fields nullable for error propagation was hiding the "true" nullability of the data.
  • The working group's SemanticNullability RFC records the path from client-controlled nullability to the current proposal.
  • Relay ships the receiving end today, generating true types for components that declare error handling with @throwOnFieldError or @catch.

Netflix's case is organizational. DGS packages Class 4's eight-value classification, layered extensions, and TypedGraphQLError as framework defaults, standardizing error shape across a service fleet the way Shopify's docs and GitLab's styleguide standardize theirs. Stephen Spalding's participation in the nullability working group, archived in February 2026, connects Netflix to the client-side effort as well. Together the two cases supply the client's requirements and the fleet-scale enforcement mechanism, which the API-vendor case studies leave out.

Further Reading​

What's Next​

Class 12 gathers the rules, patterns, and specification work of Classes 1 through 11 into one decision framework. It runs from "an error just happened" to exactly where it goes, what it carries, what status accompanies it, and what every consumer does next. It closes with the consolidated guideline list and the course's master reading list.