Fundamental Properties of the GraphQL Language

Fundamental Properties of the GraphQL Language Olaf Hartig @olafhartig Joint work with Jorge Pérez from the Universidad de Chile

Olaf Hartig – Fundamental Properties of the GraphQL Language

2


3

Why study the GraphQL language formally?

Highlight intrinsic limitations of all possible implementations Identify optimization opportunities Clarify possible corner cases


4

Our Results in a Nutshell

Formal definition of the language Study of computational complexity (the language admits really efficient evaluation methods) Solution to the problem of large results


5

Formalization of GraphQL

Why?


7

Why?


8

Why?


9

GraphQL Graphs (Our Formalization)


10


Typed nodes


11


One special node Typed nodes


12


Node properties One special node Typed nodes


13


Edge properties Node properties One special node Typed nodes


14


Edge properties Node properties One special node Typed nodes

We also formalize the notions of GraphQL schema and schema satisfaction based on this data model Olaf Hartig – Fundamental Properties of the GraphQL Language

15

Formalization of Query Evaluation Function


16


⟦friends { name }⟧u

=


17



=

friends: [


]

18



=

friends: [ { ⟦name⟧v}


{ ⟦name⟧w} ]

19



=

friends: [ {name:R2-D2} {name:Han} ]


20


⟦ hero[episode:EMPIRE] { friends {name} } ⟧


21


⟦ hero[episode:EMPIRE] { friends {name} } ⟧r


22


⟦ hero[episode:EMPIRE] { friends {name} } ⟧r = hero: { ⟦ friends {name} ⟧u }


23


⟦ hero[episode:EMPIRE] { friends {name} } ⟧r = hero: { ⟦ friends {name} ⟧u } = hero: { friends: [ {name:R2-D2} {name:Han} ] } Olaf Hartig – Fundamental Properties of the GraphQL Language

24

Complexity Analysis Evaluation Problem

Evaluation Problem of GraphQL

GraphQL query q

GraphQL graph G

data value d

Does Does dd occur occur in in the the result result of of qq over over G? G? yes

no


26

P

NP

PSPACE

Complexity Classes


27

Complexity of Evaluation Problems

Relational Algebra SPARQL

Conjunctive Queries

P

NP

PSPACE

BGPs (SPARQL)


28

Complexity of Evaluation Problems

Relational Algebra SPARQL

Conjunctive Queries

NL

P

GraphQL NP

PSPACE

BGPs (SPARQL)


29

Complexity Analysis Enumeration Problem

Non-Redundancy Valid query

Invalid result

hero[episode: EMPIRE] { name friends { name } id name friends { id } }

hero { name: Luke friends: [ { name: R2-D2} { name: Han} ] id: 1000 name: Luke friends: [ { id: 2001} { id: 1002} ] }


31

Non-Redundancy Valid query

Correct result

hero[episode: EMPIRE] { name friends { name } id name friends { id } }

hero { name: Luke friends: [ { name: R2-D2 Id: 2001 } { name: Han Id: 1002 } ] id: 1000 }

Fields are collected before answering


32

Non-Redundancy Non-redundant query hero[episode: EMPIRE] { name friends { name id } id }

Correct result hero { name: Luke friends: [ { name: R2-D2 Id: 2001 } { name: Han Id: 1002 } ] id: 1000 }

Fields are collected before answering Olaf Hartig – Fundamental Properties of the GraphQL Language

33

Another Complication: Type Restrictions Valid query

Invalid result

hero[episode: EMPIRE] { name friends { on Droid { name } on Human { id } name } }

hero { name: Luke friends: [ { name: R2-D2 name: R2-D2 } { id: 1002 name: Han } ] }


34


Correct result

hero[episode: EMPIRE] { name friends { on Droid { name } on Human { id } name } }

hero { name: Luke friends: [ { name: R2-D2 } { id: 1002 name: Han } ] }


35


Correct result

hero[episode: EMPIRE] { name friends { on Droid { name } on Human { id name } } }

hero { name: Luke friends: [ { name: R2-D2 } { id: 1002 name: Han } ] }


36

Ground-Typed Normal Form Ground-typed query hero[episode: EMPIRE] { name friends { on Droid { name } on Human { id name } } }

Correct result hero { name: Luke friends: [ { name: R2-D2 } { id: 1002 name: Han } ] }


37

Eliminating Redundancies Rewriting rules for queries Every GraphQL query q can be rewritten into a query q’ that is i) non-redundant and ii) in ground-typed normal form, such that q ≡ q’ Advantage: field collection is not needed for non-redundant queries in ground-typed NF


38

Now to the Enumeration Problem Let q be i) non-redundant and ii) in ground-typed normal form Result of q can be produced symbol by symbol with only constant time between symbols hero { friends: [ { name:R2-D2} ] }

Time to produce the complete query result depends linearly on the size of this result


39

Complexity Analysis Result Size

Results of GraphQL queries can be huge

start { knows { knows { … { knows { name } }… } } } 2N times

Alice appears 2N times in the result


41

Huge results in practice: Github’s GraphQL API Owners of first five repos that user “danbri” contributes to, and the owners of first five repos that they contribute to, and so on...


42

Result sizes can be computed efficiently!!!

Let q be i) non-redundant and ii) in ground-typed normal form Time to compute the size of the result of q over a graph G depends linearly on the product (size of q) × (size of G)


43

Result-Size Computation

start { advisor { univ { name } } friend { univ { name } } } q2

q3

Result: start: {

…

…

}

size(q, r) = 4 + size(q2 ,u) + size(q3 ,u) Olaf Hartig – Fundamental Properties of the GraphQL Language

44


start { advisor { univ { name } } friend { univ { name } } } q2

size(q2 ,u) =

q3

size(q3 ,u) =


45


q4

start { advisor { univ { name } } friend { univ { name } } } q3 q2 size(q2 ,u) = 4 + size(q4 ,v)

size(q3 ,u) =


46


q4

start { advisor { univ { name } } friend { univ { name } } } q5 q2

q3

size(q4 ,v) = 4 + size(q5 ,w)

size(q2 ,u) = 4 + size(q4 ,v)

size(q3 ,u) =


47

Result-Size Computation size(q5) = 3

q4


q3 size(q5 ,w) = 3

size(q4 ,v) = 4 + size(q5 ,w)


size(q3 ,u) =


48


size(q5) = 3

q4


q3 size(q5 ,w) = 3

size(q4 ,v) = 4 + size(q5 ,w) = 4 + 3 = 7


size(q3 ,u) =


49


size(q2) = 11

size(q5) = 3

q4


q3 size(q5 ,w) = 3

size(q4 ,v) = 4 + size(q5 ,w) = 4 + 3 = 7

size(q2 ,u) = 4 + size(q4 ,v) = 11 size(q3 ,u) = size(q, r) = 4 + size(q2 ,u) + size(q3 ,u) Olaf Hartig – Fundamental Properties of the GraphQL Language

50


size(q2) = 11

size(q5) = 3

q4

q4


q3 size(q5 ,w) = 3

size(q4 ,v) = 4 + size(q5 ,w) = 4 + 3 = 7

size(q2 ,u) = 4 + size(q4 ,v) = 11 size(q3 ,u) = 4 + size(q4 ,v) size(q, r) = 4 + size(q2 ,u) + size(q3 ,u) Olaf Hartig – Fundamental Properties of the GraphQL Language

51


size(q2) = 11 size(q3) = 11

size(q5) = 3

q4

q4


q3 size(q5 ,w) = 3

size(q4 ,v) = 4 + size(q5 ,w) = 4 + 3 = 7

size(q2 ,u) = 4 + size(q4 ,v) = 11 size(q3 ,u) = 4 + size(q4 ,v) = 4 + 7 = 11 size(q, r) = 4 + size(q ,u) + size(q ,u) 2

3


52


size(q2) = 11 size(q3) = 11

size(q5) = 3

q4

q4


q3 size(q5 ,w) = 3

size(q4 ,v) = 4 + size(q5 ,w) = 4 + 3 = 7

size(q2 ,u) = 4 + size(q4 ,v) = 11 size(q3 ,u) = 4 + size(q4 ,v) = 4 + 7 = 11 size(q, r) = 4 + size(q2 ,u) + size(q3 ,u) = 26 11 11 Olaf Hartig – Fundamental Properties of the GraphQL Language

53

Proposal for GraphQL Servers First, compute the size of the result. If too big, reject query. Else, inform the size to the client, and Send the result byte by byte.

(or use the size as basis of a billing model)


54

Summary

Our Results in a Nutshell Formal definition of the language ● ●

Property Graph-like data model Formal query semantics

Study of computational complexity (the language admits really efficient evaluation methods) ● ●

Evaluation problem is NL-complete Enumeration of results is linear

Solution to the problem of large results ●

Efficient algorithm to compute result size


56

www.liu.se