GraphQL, gRPC or REST - Resolving the API Developer's Dilemma

This session compares REST, GraphQL, gRPC, and other API styles to help developers choose an appropriate approach for a specific application context. It covers architectural constraints, supporting technologies such as HTTP/2, graceful API contract evolution, and treating APIs as products.

Syllabus

Intro
MY TWITTER TIMELINE IS A TYRE FIRE
API COMMUNITY IS SMALL WE NEED TO WORK TOGETHER
NO! THAT'S NOT THE WAY APIS WORK!
THERE IS NO UNIVERSAL BEST API STYLE
THERE IS ALWAYS A BEST API STYLE FOR YOUR PROBLEM
CONSTRAINTS = PROPERTIES
LET'S DISPEL SOME MYTHS
REST IS STATE-MACHINE OVER HTTP
FRIENDS DON'T LET FRIENDS BUILD RESTISH APIS
GRAPHQL BREAKS CACHING
WHAT KIND OF CACHING?
GET WITH PERSISTED QUERIES
OVER/UNDER FETCHING
HELLO HTTP/2, GOODBYE NETWORK HACKS
GRAPHQL IS NOT JUST ABOUT NETWORK EFFICIENCY
THE VALUE OF GRAPHQL IS THE SUM OF IT'S PARTS
GRAPHQL ELIMINATES THE NEED FOR VERSIONING
VERSIONING IS A STRATEGY NOT A REQUIREMENT
VERSIONING VS GRACEFUL EVOLUTION
GRACEFUL EVOLUTION SHOULD BE THE GOAL
YOU CANNOT OVER COMMUNICATE WITH USERS!
TOLERANT READERS ARE MODEL CLIENTS
BUG FOR BUG COMPATIBILITY
DOMAIN MODELLING IS PURELY A REST CONCERN
GRAPHQL DELAYS THE LAST RESPONSIBLE MOMENT FOR IDENTIFYING USER NEEDS