--- title: 'Takeaways From GraphQL Summit 2022' date: 2022-10-14T00:14:06Z description: 'GraphQL Summit 2022 takeaways: the 5 talks I recommend from 22, including Netflix and Fidelity on Apollo Federation, Reddit’s supergraph and Apollo Router 1.0.' draft: false tocOpen: true coverImage: 'images/cover.jpeg' tags: - GraphQL - API Design - Web Development - Conference - Software Engineering --- ## 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 | Talk | Recommend | | ---------------------------------------------------------------------------------- | --------- | | The Champion's Journey | | | Schema Design | | | Opening Keynote | | | Creating Connected Subgraphs | | | Building Great GraphQL Developer Experiences @ Scale | | | Escaping GraphQL Monoliths and Embracing Apollo Federation at Fidelity Investments | Yes | | Navigating the Normalized Cache | | | Schema Updates on Mobile GraphQL Clients | | | Steps to Take Until You Remove All the REST | | | Authorization Patterns in GraphQL | | | From Graph to Supergraph Scale Fast Without Breaking Anything | | | The Future of Supergraph | | | How a Supergraph Powers the Front Page of the Internet | Yes | | The Future of Real-Time Data in GraphQL | | | Stranger Graphs Scaling Netflix Financials with Federation & GraphQL | Yes | | GraphQL is Not a Trap | | | Designing GraphQL Friendly REST APIs | | | Netflix's Supergraph Saga Continues: Collaboration @ Scale | Yes | | What's New in Apollo Server 4 | | | Apollo Router: The Next Generation Supergraph Runtime | Yes | | Can We Still Be BFFs | | | Solving the Two Hardest Problems in Computer Science with GraphQL | | | How Walmart Redesigned and Unified their Customer Experience in Just 11 Months | | ### 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](https://github.com/MoonHighway/schema-design-workshop) - [Apollo Server Testing & Mocking](https://www.apollographql.com/docs/apollo-server/testing/mocking/) - [Mocker: Casual](https://github.com/boo1ean/casual) ### Day 2 Started the day with a cup from [Rugged Coffee](https://www.ruggedcoffeeco.com/) 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](https://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