Speaker: Garrett Heinlein from Netflix

For other QCon blog posts, see QCon live blog table of contents

Use case at Netflix

• Takes big bets
• Organize data as single entity graphs
• Wanted to merge graphs so can cross query
• Early on in GraphQL journey

Team dynamics

• “Monoliths are great” – single code base, atomic changes, simple deployments. “It might be a big ball of mud, but you love that ball of mud”
• Can’t have over a dozen people working on one system
• Microservices reduce costs with smaller teams and lessen communication
• REST APIs require care to change spec changes

GraphQL

• Express what is possible
• Can get just data need
• Schema is the source of truth
• Can focus on product
• Optimize exploration over documentation

Disadvantages

• Rewriting code. But don’t have to change everything
• Multiple entity graphs require managing release cycles

Consider

• Designing graphs
• Talk to others who have already done
• Whether focus is data or clients
• UI or entity centric schema
• Who owns the schema? ex: ivory tower committee, informed captain per entity
• DIstributed writes. Reading is far easier. For now Netflix is limitting updates to single entity
• Error handling

Q&A [he left a lot of time for Q&A which was good because lots of good questions!]

• Performance? Can do rate limiting. Can whitelist allowed queries for production. batching. Recommends Apollo product.
• Concurrency and parallelism? GraphQL planner (like explain) so can optimize query. Complicated. Will be open sourced [missed product name]
• Lazy problems with different sources? If know something can fail, put that error state into the schema
• Multiple teams using entity with different view? Each team owns subtype and one team owns main type.
• Business logic errors? Evolving topic. Can “or” return type so can be User type *or* “404 type”. Then calling code has different logic based on return type.
• How deal with breaking changes in Federated graph? Apollo helps with this. Can report on specifications and performance based on production usage
• Team communication for design? Working groups for things like pagniation. Now have federated team to build entity graphs and teams maintain their entities.
• How avoid duplication? All using graphql. Not doing long enough to have bloat.
• Deprecation strategy? Netflix doesn’t tell people what to do. Developers choose. Thinks Facebook never deprecated anything internally. Hasn’t encountered yet at Netflix.
• Need to write resolver for each query. Bigger benefit is for clients

My impression

I’ve used GraphQL with GitHub as a consumer. It was interesting “formalizing” that knowledge by learning why another company started using it. Along with some pros and cons. They are early in the journey. I’d be interested to see this talk in another year or two after they have more experience. I enjoyed the talk as is though. It provided good insights and things to think about.