GraphQL Abstraction Breakdown?



Yep. Question is where to draw the line…

The promise of GraphQL is the “graph” abstraction supplies just enough flexibility for FE devs to customise precisely the way they like…

Yes. I like to work with heuristics / abstractions / mental shortcuts. When something doesn’t fit neatly (as in this case) I need to work it out in my head…



Marc-Andre Giroux (GitHub) is working on The Little Book of GraphQL Schema Design and his talk is available: GraphQL Schema Design @ Scale (Nov. 7, 2018, GraphQL Summit).

  • A type system to express possibilities
  • Declarative: Clients select what they need and nothing more


  • In a complex application GraphQL is rarely an interface to your database
  • Your GraphQL Schema does not need to match your existing REST resources
  • It also does not have to be a 1:1 mapping to your UI


  • GraphQL lets us model an interface to our core domain
  • For a lot of us, it is often an opportunity to design from scratch, to let go of our coupling to our database schema, our REST resources or our UI.
  • Be an expert at your domain, understand the ins and outs

Guiding Principles:

  • Design for behaviours or use cases over data
  • Stay away from trying to build a “One Size Fits All” API and embrace the different use cases and clients
  • Prefer highly optimized fields over generic/smart fields


  • Talk to, (or become) domain experts
  • Think Domain over Data
  • Sometimes it’s not about “One Size Fits All”

What is interesting is the notion to stay away from a generic “one size fits all” API/schema. With GraphQL is our BFF/Client Adapter he states that their schema is actually all their various client(-centric) adapters folded into one, sometimes leading to the same/similar information being represented in a variety of ways in order to support differing client needs.