GraphQL Abstraction Breakdown?

General Prog (Archived)
,
21

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…

22

FYI:

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

Non-Goals

  • 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

Points:

  • 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

Conclusions:

  • 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.

2 Likes