#28

Le GraphQL

c'est vraiment la fin du REST ?

www.meetup.com/CaenCamp

@caencamp

@alexisjanvier

@marmelab

Alexis Janvier

developpeur chez marmelab

depuis 2014

Atelier d'innovation digitale, développe vos projets d'innovation web et mobile avec agilité, pragmatisme et gourmandise.

à Nancy, Ils n'y connaissent rien à l'équitation.

graphql

est une technologie dédiée aux API web

(Application Programming Interface)

Par exemple, une API de gestion de playlist : 

- des albums

- des artistes

- des releases

- des albums similaires

- des liens spotify

Quelle techno.

pour réaliser cette API ?

une API SOAP

Une API Rest

RESTful

HATEOAS

...

Rest est un style d'architecture permettant de construire des API.

* les liens comme relation entre ressources (Hypermedia)

​* l’URI comme identifiant des ressources

* les verbes HTTP comme identifiant des opérations

(GET, POST, PUT, PATCH, DELETE)

* les réponses HTTP comme représentation des ressources

Et le rest c'est SUPER !

Mais ...

Liste des albums: GET /api/albums

Ajout d'un album à une playlist: POST /api/playlists/:id/albums

Création d'une playlist: POST /api/playlists

Liste des playlists : GET /api/playlists

La construction des endpoints

albums?artist=xenia

ou

artists/xenia/albums

Le format de la réponse du retour

 

 

- en XML

- en json

ok, mais respectant le format HAL, JSON-LD, JSON:API ... ?

Les informations contenues dans la réponse

- Trop d'informations, et on gaspille bêtement de la bande passante et de la mémoire.

- Trop peu d'informations, et on est obligé de multiplier les requêtes.

La documentation

 

Il faut souvent le créer indépendamment de l'API

Il faut la maintenir en parallèle de l'évolution de l'API

On peut utiliser des outils : Swagger, API Blueprint, Open API ...

L'utilisateur ajoute un album à une playlist

playlist.ajouterUnAlbum()

playlist.addAlbum()

POST api/playlist/:id/albums

=

=

Le graphQL

data query language

{
  getPlaylists(id: “1”) {
    title
    album
  }
}

Créé en 2012 par Facebook, c'est  open-source depuis 2015.

 

Github propose son API graphQL depuis 2016

SpotifyLink

Artist

Album

Playlist

Release

Ceci n'est pas un graph

Approche graph first

DDD, ubiquitous language, mock

coordination des développements back et front

Album {
    idMb
    cover
    title
    artists
    publicationDate
    releases
    similars
    spotifyLinks
}
Artist {
    idMb
    type
    name
    country
}
Release {
    support
    label
    date
}

On va definir le schema

type Album {
    # Id musicBrainz
    idMb
    # Url for album cover
    cover
    # Album's main title
    title
    # Artists credited to the album
    artists
    # First publication date
    publicationDate
    # The different releases of the album
    releases
    # If you liked it, you might also like this albums
    similars
    # Spotify listening links
    spotifyLinks
}

Le documenter

type Album {
    # Id musicBrainz
    idMb: String! ,
    # Url for album cover
    cover: String!,
    # Album's main title
    title: String!,
    # Artists credited to the album
    artists: [Artist],
    # First publication date
    publicationDate: Date!,
    # The different releases of the album
    releases: [Release],
    # If you liked it, you might also like this albums
    similars: [Album],
    # Spotify listening links
    spotifyLinks: [SpotifyLink],
}

Le typer

Coding time

  • De la magie (makeExecutableSchema)
  • Un serveur express
  • graphiQL
  • Les resolvers
  • Le choix des sources de données
  • Les mutations
  • Introspection

Backend

query {
  __type(name: "Artist") {
    name
    fields {
      name
      description
      type {
        name
        kind
        ofType {
          name
          kind
        }
      }
    }
  }
}
  • limite de l'exemple à react/redux
  • HOC
  • Ajouter les artistes

Frontend

Conclusions

 

Pour un projet d'API publique ... pas certain, ou en plus d'une version REST

Pour un projet back(s)/front(s) dont l'API n'est pas publique : un gros OUI

PLUS

- approche graph first

- DDD nommage des mutations

- documentation et découverte

- économie de réseau

- approche composant (redux, style inline, HOC sur une requête nommée stockée côté serveur)

- à priori mature (Facebook, Github)

 

MOINS

- pas de data (microservice, base64)

- un peu trop de magie

MERCI