GraphQL vs. REST
Let’s talk Web APIs
Pieter Colpaert
Ghent University – IDLab – imec
Open Knowledge Belgium
Slide 2
Slide 2 text
https://pietercolpaert.be
Slide 3
Slide 3 text
https://pietercolpaert.be
But oranges are
obviously better
Slide 4
Slide 4 text
Client:
Give me all the things
HTTP /thing1
HTTP /thing2
HTTP /thing3
Client:
Give me all the things
HTTP /graphql?q={thing1,thing2,thing3}
joins happen on the client joins happen on the server-side
GraphQL: a convenience tool for front-enders
Slide 5
Slide 5 text
https://pietercolpaert.be
Data dumps
Smart servers
Entire query
languages over
HTTP
Subject pages
HTTP API
Smart agents
Yet, what do we want the server to do?
Slide 6
Slide 6 text
https://pietercolpaert.be
Data dumps
Smart servers
Entire query
languages over
HTTP
Dataset split in
fragments
Smart agents
algorithms
as a service
Other solutions possible?
Subject pages
HTTP API
Slide 7
Slide 7 text
Client:
Give me all the things
{thing1,thing2,thing3}
joins happening on the client-side,
but the front-end developer doesn’t have to know
HTTP /thing1and2
HTTP /thing3
Slide 8
Slide 8 text
Client:
Give me all the things
{thing1,thing2,thing3, ...}
And… Why even stick to your
own server?
HTTP /thing1and2
HTTP /thing3 To the Web and beyond!
Slide 9
Slide 9 text
Towards automated data
integration
and why GraphQL needs REST
Slide 10
Slide 10 text
https://pietercolpaert.be
What did we do?
We made the datasets interoperable on 3 levels:
1. Syntactic
2. Semantic
3. Querying
And query them using e.g., Comunica (http://query.linkeddatafragments.org)
Slide 11
Slide 11 text
https://pietercolpaert.be
What did we do?
We made the datasets interoperable on 3 levels:
1. Syntactic
2. Semantic
3. Querying
Fixed this using “Linked Data”
Slide 12
Slide 12 text
https://pietercolpaert.be
name type city population
Gare du Nord Station Paris 2.2m
{
"Gare du Nord" : {
"type" : "Station",
"city" : {
"name": "Paris",
"population":"2.2m"
}
}
}
Station
2.2m
Table / CSV / Spreadsheet
JSON XML
Serialisations
Slide 13
Slide 13 text
https://pietercolpaert.be
.
.
“2.2m” .
Table / CSV / Spreadsheet
3 time a datum
Triples – Resource Description
Framework (RDF 1.1)
{
"Gare du Nord" : {
"type" : "Station",
"city" : {
"name": "Paris",
"population":"2.2m"
}
}
}
Station
2.2m
JSON XML
name type city population
Gare du Nord Station Paris 2.2m
Slide 14
Slide 14 text
https://pietercolpaert.be
World Wide Web
Garedunord
city
Paris
Gare du Nord
type
Station
Paris
population
2.2m
HTTP Machine 1 HTTP Machine 2 HTTP Machine 3
The Web: a decentralized data ecosystem
A user agent visiting each machine knows more than any of the machines
independently
E.g., data.sncf.com E.g., transport.data.gouv.fr E.g., wikipedia.com
Slide 15
Slide 15 text
https://pietercolpaert.be
Solution
Gare du Nord → http://www.wikidata.org/entity/Q745942
is a → http://www.w3.org/1999/02/22-rdf-syntax-ns#type
Station → http://vocab.gtfs.org/terms#Station
Uniform Resource Identifiers (URIs)
Slide 16
Slide 16 text
https://pietercolpaert.be
1. Describes how to express triples in different
serializations (RDF)
2. Introduces global identifiers (HTTP URIs)
for domain models and their instances
Linked Data
Slide 17
Slide 17 text
https://pietercolpaert.be
Hahahahahaha
You will never get governments to
actually do that
Slide 18
Slide 18 text
https://pietercolpaert.be
But they are already doing that:
data.vlaanderen.be
Flemish buildings, addresses, domain models, organizations, … with their
official URIs published as Open Data
Slide 19
Slide 19 text
https://pietercolpaert.be
Hahahahahaha
Writing full URIs everywhere
is way too difficult!
https://pietercolpaert.be
Or RML.io
Maps unstructured data to Linked Data
http://rml.io/yarrrml/matey/
Slide 22
Slide 22 text
https://pietercolpaert.be
Another great starting point
wikidata.org
Wikipedia, but for triples!
Slide 23
Slide 23 text
https://pietercolpaert.be
What did we do?
We made the datasets interoperable on 3 levels:
1. Syntactic
2. Semantic
3. Querying
Fixed this using Linked Data!
???
Slide 24
Slide 24 text
https://pietercolpaert.be
Let’s apply this to route planning
Slide 25
Slide 25 text
http://api.{mycompany}/?from={A}&to={B}
&departuretime=2019-03-27T12:02.024Z
&wheelchairaccessible=true
&transit_modes=plane,railway,bus,car
&algoritm_mode=shortest
...
This interface will need to answer all questions for all third party apps…
Slide 26
Slide 26 text
https://pietercolpaert.be
data dump
Route planning
algorithms as a service
Asking questions
Your
system
3d party
Your
system
? ?
?
?
?
?
Does not scale:
Extra users comes with extra load
Does not give
necessary flexibility
to companies
Slide 27
Slide 27 text
https://pietercolpaert.be
Page X
Page ...
Page 2
Page 1
time
next
next
Publishing time schedules in fragments
on the Web
https://pietercolpaert.be
Publishing roads in tiles
Demo:
https://hdelva.be/slides/sotm2019/#/
Slide 30
Slide 30 text
https://pietercolpaert.be
Both together
https://planner.js.org/example.html ⇒ an SDK for front-end developers
Slide 31
Slide 31 text
https://pietercolpaert.be
Take-aways
1. Try to fit your Linked Data in 1 HTTP response
2. If it doesn’t fit,
a. fragment your data in multiple resources
b. Base your fragmentation on the same way as adding an index in a database
c. Add hypermedia links so your clients automatically understand it’s now fragmented
3. Let the client do more, but hide this from your front-enders through SDKs
Oh, and for the record REST is not the enemy of GraphQL ;)