Kristoffer Brabrand
Senior developer @ Behalf
GraphQL
GraphQL: A graph oriented way to think about and explore data
[without the data actually having to be in
a graph database any particular structure,
database or format at all]
Let's look at an example first...
After all that hard work, the REST API is now proper code 🍝
It's not your fault
REST is a good idea, but building applications on top of it... well. It's no fun 😢
No matter what, you'll end up with one of these:
1. frontend view specific endpoints in your API
2. huge payloads with loads of data your view doesn't need
3. many API requests per view
Entering GraphQL
Promise
GraphQL lets you define what the data looks like, how it's connected and how to resolve it.
So what does a GraphQL query even look like then?
Example #1
Basic article information
query Query {
article(id:196000) {
id
title
authors {
name
}
}
}{
"data": {
"article": {
"id": 196000,
"title": "Slik kan nettbankene bli sikrere",
"authors": [
{
"name": "Pål Unanue-Zahl"
},
{
"name": "Madeleine Bråthen Bjaaland"
}
]
}
}
}Example #2
Article with tags and categories
query Query {
article(id:196000) {
id
title
preamble
story
authors { name }
tags { id name }
categories { id name }
}
}{
"data": {
"article": {
"id": 196000,
"title": "Slik kan nettbankene bli sikrere",
"preamble": "...",
"story": "<p>De kan virke...",
"authors": [
{
"name": "Pål Unanue-Zahl"
},
{
"name": "Madeleine Bråthen Bjaaland"
}
],
"tags": [
{
"id": 1434,
"name": "Datasikkerhet"
},
{
"id": 1433,
"name": "Datakriminalitet"
},
{
"id": 1430,
"name": "Data og nett"
}
],
"categories": [
{
"id": 1107,
"name": "Teknologi"
},
{
"id": 1102,
"name": "Forbruker"
}
]
}
}
}Example #3
Tags/category listings
query Query {
tag(id:1) {
id
name
articles {
id
title
}
}
}{
"data": {
"tag": {
"id": 1,
"name": "Statoil",
"articles": [
{
"id": 8042902,
"title": "800 millioner kroner til Statoil-meklere"
},
{
"id": 6738410,
"title": "Applaus for Statoil-aksjen"
},
{
"id": 8159735,
"title": "69 kroner for Statoil-aksjen"
},
...
]
}
}
}100% 🌈 and 🦄?
The good parts
- No more front ↔ back end data dependencies
- Easier to avoid over/under fetching
- Clean abstraction of data backends
- You can model a meaningful interface to your data, regardless of the underlying structures and systems
- Unopinionated. Doesn't care how and where you get your data
The bad tricky parts
- Avoiding dangerous/expensive queries
Live coding
https://github.com/kbrabrand/graphql-intro
GraphQL på fagdag
By Kristoffer Brabrand
