Takeaways From GraphQL Summit 2022

A Bit Background

I've been working from home since March 2020. I've also avoided traveling in the past three years. When Jen, my manager, asked me if I wanted to go to GraphQL Summit 2022, I immediately realized that I should have been outside more often, and I took the opportunity. Besides, there are colleagues I have never met since they were hired during the pandemic.

Talks I Attended

Day 1: Workshops

The Champion's Journey by Dan From Expedia Group

• Champions start from their own early developer experience and lead with empathy — remembering what it felt like before things got easier, staying humble that everything can still be made better, and sharing what you learn along the way.
• Culture matters as much as code. Dan talked about "peeps and culture," leaders, and how many different tribes touch a graph — app teams, service teams, product & design. One stat stood out: it's not typical for front-end teams to own most of the graph work; in his org, service teams own about 80% of it.
• Rolling out GraphQL internally is really an "internal economy" problem — power, "coins of the realm," and who gets to make decisions matter just as much as the technology itself.
• The strongest pitch for GraphQL, in his experience, wasn't performance or DX — it was collaboration.
• Federation raises a recurring fork in the road: do you end up with a fragmented graph, or one mono graph? He pointed to PayPal as an example of navigating that tradeoff.
• Being declarative helps, but there are real pains too — database ownership issues came up more than once, and mindset matters as much as tooling.
• He referenced the "Supergraph" and raised open questions worth sitting with: where does TypeScript fit in, and what logic belongs in lower-level services versus the graph layer?
• His advice for getting started: go from a proof of concept to a small production pilot to prove value — and pick a hard problem to start with, not an easy one.

Schema Design

• Schema Design Workshop
• Apollo Server Testing & Mocking
• Mocker: Casual

Day 2

Started the day with a cup from Rugged Coffee before diving into back-to-back talks.

Opening Keynote

• SuperGraph Dev Kit
• Apollo Router 1.0 & Apollo Federation 2
• GraphOS

Building Great GraphQL Developer Experiences @ Scale (Netflix)

• History
  • BFFs for different consumers: TV, iOS, web
  • 500+ contributors
  • 300+ domain graph services
  • 3,000+ types
• Challenges
  • Design comes first
    • APIs are harder to change once they're out
    • Schema Registry
    • SUPs (Schema Update Proposals)
  • Consistency & guidelines
    • GraphDoctor, a diff-aware GraphQL schema linter
  • Rapid iteration & prototyping
    • Variants as a sandbox for integration
    • GraphLabs
    • Preview environments via Reggie, their graph registry UI
• Takeaway: federated schema design, a schema linter, and preview environments go a long way at this scale.

Escaping GraphQL Monoliths and Embracing Apollo Federation at Fidelity Investments

• Monolith vs. microservices, framed around a domain capability model (e.g., a chat client)
• What starts to break as you scale:
  • Higher TPS
  • Errors surfacing from backends
  • Data access controls
• Their answer: Apollo Federation, with developer experience as the north star
• Takeaways: improve dev experience, tame graph complexity, improve team collaboration, and reduce merge conflicts

Navigating the Normalized Cache at Wayfair

• Used Android as the example platform
• Framed around network latency and "rage metrics" — rage clicks, scrolling at random ("scrandom"), backtracking
• Idle wait times hurt more than raw speed: how people feel is more important than actual performance
  • Simplified metrics: Speed Index, missed interactions, CLS (layout shift)
• How data flows between navigations, and shared data bindings
• Open problems: TTL management and direct cached-fragment access

Schema Updates on Mobile GraphQL Clients (Apollo GraphQL)

• Mobile apps are strongly typed and ship binaries with the GraphQL schema baked in
• Impact: type conversion and cache-key normalization break when the schema changes
• Mitigation strategies
  • Flat, response-based models — didn't work
  • Infer type from key fields — worked
  • Infer type from naming convention — worked
• Covered implementing type conversions and normalized cache keys
• Future possibility: run-time schema updates

Steps to Take Until You Remove All the REST at Pinterest

• Shared migration stats
• The big-picture problem: is there a reusable component or a repeatable pattern here?
• General approach: define a domain model, expose a store API
• Why abstraction didn't work for them
• Current architecture
  • Don't force extra layers — use what you've already got
  • Normalization
  • GraphQL → REST
  • Apollo Connectors
  • The N:N problem

Authorization Patterns in GraphQL (OSO)

• Pattern #1: delegate to business logic for authorization (REST or GraphQL) — exceptions for doing auth in GraphQL directly are when it's easier, or when you're GraphQL-first
• Pattern #2: resolvers, e.g. a directive like @check(permission: String! = "Read", resource: String)
• Pattern #3: return permissions to the front end, e.g. viewerPermission: "Admin" | "User"
• Summary and further reading: osohq.com/post/graphql-authorization

From Graph to Supergraph: Scale Fast Without Breaking Anything

• Framed from a business point of view: the API as a service

The Future of Supergraph (Apollo GraphQL)

• Thinking about data in three buckets: one service, all the services I control, and all the services I don't control
• Current issues with wrapping APIs: it's a lot of work, it's limiting, and it makes you responsible for someone else's data model
• Linking with Federation: graph linking, namespacing, schema composition, and multi-level routing (hub-and-spoke model)
• Extending a type you don't control by namespacing fields

How a Supergraph Powers the Front Page of the Internet (Reddit)

• Reddit: 54M daily active users

Day 3

Keynote: The Future of Real-Time Data in GraphQL

• What comes after @defer? Mostly a performance question.
• Where GraphQL still doesn't shine: refetching, schema updates, and over-fetching (compare to HTTP/REST's ETag, If-None-Match, 304 Not Modified)
• Could GraphQL use an HTTP-style tag header? Could GET requests unlock HTTP caching?
• Common thread: GraphQL isn't great for ongoing conversations — could an Elasticsearch Scroll API-style approach with a runtime request ID help?
• Multipart/mixed accept header and incremental delivery (a multipart response with a cursor and hasNext: true)
• What about incremental re-delivery? Result diffing beyond a simple 304 — a proposed cursor-based query revalidation and diffing scheme, using base62 encoding
• Entities with the router: entity-based invalidation
• And what about @live queries?

Stranger Graphs: Scaling Netflix Financials with Federation & GraphQL

(An internal application.)

• Netflix Studio's content lifecycle and accounting
• Characteristics: lower RPS, business workflows, source-of-truth data, multiple data sources, denormalized data
• Migration path: REST → federated GraphQL
• Issues along the way
  • Performance efficiency in resolution: over-fetching on the server side, possibly solved with a DataLoader
  • Data store performance: an ORM over MySQL, and batch-save calls that weren't actually batching inserts under the hood
  • Application-level caching
  • A default browser via the Studio Gateway browser extension
  • Moving from sync to async
  • Orphans: missing data in the federated graph

GraphQL is Not a Trap (Twitter)

• Versioning
• Principles: one schema, one graph; data as a graph

Netflix's Supergraph Saga Continues: Collaboration @ Scale

• A quick history: a single PC in 1998, starting simple, a move to the cloud in 2008 ("highly aligned, loosely coupled"), hitting "black holes" in 2018, and by 2022 the graph spans Netflix Games and Tudum too
• Now: dozens of schema updates and hundreds of subgraph updates per day
• Issues: bad APIs, distributed systems, and people
• Potential pitfalls
  • Microservice madness — slice the graph deliberately
  • Use federation, but not too much, and mostly along team boundaries
  • Schema anarchy — addressed with a schema working group, documented best practices, Schema Update Proposals, and linting

What's New in Apollo Server 4

• A few things were mildly confusing at first

Apollo Router: The Next Generation Supergraph Runtime

• Written in Rust, built on top of Hyper