Slide 1

Slide 1 text

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!

Slide 20

Slide 20 text

https://pietercolpaert.be Meet JSON-LD! { "@context": "http://schema.org/", "@type": "Person", "name": "Jane Doe", "jobTitle": "Professor", "telephone": "(425) 123-4567", "url": "http://www.janedoe.com" }

Slide 21

Slide 21 text

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

Slide 28

Slide 28 text

https://pietercolpaert.be http://linkedconnections.org

Slide 29

Slide 29 text

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 ;)