GraphQL
Paolo Invernizzi - Software Engineer - Global BU
History of GraphQL
● 2012 - built to support Facebook
mobile Apps
● 2015 - GraphQL open sourced
● 2018 - GraphQL Foundation
State of GraphQL (2022)
● The report found 47.9% of developers use GraphQL for exposing an API intended for a personal website or app,
40.4% use it for private unexposed APIs for internal usage and 19.5% use GraphQL for publicly available APIs
intended for third-party developer consumption.
● 55.4% of GraphQL APIs hit databases, while 35% consume REST APIs and 14.6% eat other GraphQL endpoints.
This does NOT represent adoption
● Graph Query Language
● Server side runtime
● Data source agnostic
GraphQL is a language for
querying data not tied to query a
particular type of data store (such
as a MySQL database). Instead,
you use GraphQL to query data
from any number of different
sources.
It is a server side runtime typically
served over HTTP.
REST VS GraphQL
REST GraphQL
Shared Definition No Yes
Conceptual Model Resources Graphs
Organization Federated Centralized
Related Ops Yes No
Introspection No Yes
Data Typing Weak Strong
Real time No Yes
Challenges for modern APIs
● Efficiency
● Security
● Documentation
● Versioning
● Database integration
● Real time support
● Caching
● Tooling
● ….
Integration
Overfetching and
Underfetching
With a typical REST architecture, the
response may contain:
● Too much data (overfetching)
● Not enough data. Make more
requests.
Network is slow:
● 1 MB from SSD: 400 μs
● Packet US <--> EU: 150 ms
Type safety
● Predictability
● Native clients
● Code generation
Versioning
Documentation & Tooling
● GraphiQL provides documentation via introspection –> docs are never out of date
● GraphQL required that requests specify their fields –> we know which fields are used
● Schema allows to mark fields as @deprecated –> deprecate with confidence
● IDE integration