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 movie information

query Query {
  movie(id:196000) {
    id
    title
  }
}
{
  "data": {
    "movie": {
      "id": 196000,
      "title": "Killer Sloths III"
    }
  }
}

Example #2

Movie with actors and reviews

query Query {
  movie(id:196000) {
    id
    title
    actors { 
      id, 
      firstName, 
      lastName 
    }
    reviews { 
      id, 
      name,
      rating,
      comment
    }
  }
}
{
  "data": {
    "movie": {
      "id": 196000,
      "title": "Killer Sloths III",
      "actors": [
        {
          "id": 1234,
          "firstName": "Alice",
          "lastName": "Webb"
        },
        ...
      ],
      "reviews": [
        {
          "id": 123,
          "name": "Alf Sim",
          "rating": 1,
          "comment": "It sucks!"
        },
        ...
      ]
    }
  }
}

Example #3

Actors with movies

query Query {
  actor(id:1234) {
    id
    firstName
    lastName
    movies {
      id
      title
    }
  }
}
{
  "data": {
    "actor": {
      "id": 1234,
      "firstName": "Alice",
      "lastName": "Webb",
      "movies": [
        {
          "id": 196000,
          "title": "Killer Sloths III"
        },
        ...
      ]
    }
  }
}

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
  • Mature and with a good ecosystem (thanks Apollo)

The bad tricky parts

  • Securing the graph against abuse
  • Designing the data model is challenging – once a field is exposed in the schema, it shouldn't ever be removed

Securing your graph

 

You don't want abuse. There's a few ways around it.

 

  1. The poor mans version (cost limiting)
  2. Apollo operations registry

 

The poor mans version

 

  1. Set a fixed "cost" allowed for a single query
  2. Specify cost on the different resolvers
  3. Return an error if the cost is higher than allowed

Apollo operations registry


Upload allowed queries to the registry build-time and allow only those queries uploaded to the registry to be performed.


Note: requires a an active team subscription for Apollo

Live coding

https://github.com/kbrabrand/graphql-intro

Mer GraphQL på fagdag

By Kristoffer Brabrand

Made with Slides.com

Mer GraphQL på fagdag

  • 445

More from Kristoffer Brabrand