GraphQL ou le futur des APIs

Junior Gantin
Aug 19, 2017 · 6 min read

GraphQL est l’un des “buzzwords” du moment dans le monde du développement informatique au même titre que ReactiveX, les PWAs, Webpack ou ReactJS. Cet article vise donc à expliquer les concepts fondamentaux de cette spécification qui selon plusieurs personnes (moi, le premier) représente le futur des APIs.


Dans un de mes articles, j’ai expliqué le but et le rôle des APIs dans le développement d’applications informatiques scalables.

Une API est une sorte de tunnel (c’est juste une représentation) par lequel transiteront toutes les données que vous échangez entre votre source de stockage et votre application. C’est une sorte de middleware qui se place ainsi entre votre serveur de données et votre application. L’image ci-dessous exprime assez bien cet état de chose.

Le rôle d’une API dans une architecture client-serveur

Durant longtemps, les développeurs ont utilisé une approche développée par Roy Fielding dans sa thèse intitulée Architectural Styles and
the Design of Network-based Software Architectures
. Cette approche est connue par tous les développeurs d’APIs: REST (REpresentational State Transfer).

Si aujourd’hui, un débat fait rage dans la construction des APIs, cela veut sous-entendre que REST ne répond plus à nos besoins. Alors que reproche-t-on donc à REST?

Je vais essayer d’énumérer les “points faibles” de REST.

1- Avec une API REST, le client ne peut pas récupérer une partie des champs d’un objet. Il reçoit tous les champs de l’objet.

2- L’une des critiques qui revient sans cesse est qu’un client doit parfois enchaîner plusieurs requêtes afin de récupérer des données précises.

3- La gestion des relations entre mes objets est un véritable casse-tête.

4- Le client ne peut “requêter” que sur des “endpoints” définis au préalable par le développeur de l’API.

6- Le typage des données.

Au vu de cette liste (que certains pourraient rallonger encore et encore), on pourrait se poser la question de savoir pourquoi REST a t-il été utilisé malgré tout?

REST est et restera pour quelques années encore le standard des échanges client-serveur avant que GraphQL ne devienne la norme absolue!


GraphQL, tout nouveau et tout beau!

GraphQL a une grande adoption de la part de la communauté des développeurs. Bon c’est quoi GraphQL au juste? En un mot?

GraphQL c’est l’avenir des APIs.

Oui et je l’assume. GraphQL c’est une spécification sortie tout droit de Facebook et qui permet de repenser totalement les échanges de données entre client et serveur.

Pause! Je viens de dire que GraphQL est une spécification. Donc cela veut dire qu’il y a une grosse documentation à lire (adieu la procrastination) afin de comprendre comment l’utiliser et surtout “n’importe qui peut programmer un serveur respectant les spécifications GraphQL”.

Je reprend ici les propos de Lee Byron qui explique le but de la création de GrapQL.

The primary motivation to create GraphQL was that, according to Lee Byron, Facebook “started with a system that looked a lot like a traditional RESTful server but found it difficult to use as iOS developers, and saw conflict between the desire to load all information in a single round trip while keeping REST resources well isolated.” Lee Byron

Avec GraphQL, le client a le pouvoir: il peut récupérer des réponses flexibles afin d’éviter des requêtes supplémentaires.

Donc si je comprend bien, on doit oublier REST? Et GraphQL n’a pas d’inconvénients?

Un instant, je vais essayer d’énumérer les limites de GraphQL. La technologie ultime ou parfaite n’existe pas … encore.

1- Comme n’importe qui peut écrire son serveur, on fait comment? Quel est l’état des implémentations dans les langages et frameworks? Bah ouais, tout le monde ne fait pas NodeJS (L’implémentation officielle de Facebook est en JavaScript)! Je parle ici de la qualité des implémentations.

2- La courbe d’apprentissage de GraphQL. On repense nos échanges client-serveur!

Dans la suite de l’article, j’explique les concepts nouveaux qu’apporte GraphQL à travers un exemple de serveur.


Qu’allons-nous construire? Par manque d’inspiration, j’ai décidé de construire une simple TODO API . Ready?

#GOT

N’en déplaise au développeurs NodeJS, Ruby ou PHP (Oui, je sais! Je ne pouvais pas citer tous les langages), j’ai choisi Python comme langage pour développer le serveur GraphQL.

Comme je le disais, avec GraphQL il existe une multitude d’implémentations dans tous les langages (même en Prolog). Recherchez-vous celle de votre langage préféré? Un seul dépôt Github: @awesome-graphql

Pour les développeurs Python, la référence reste Graphene, l’implémentation GraphQL en python. Nous utiliserons Graphene-django afin de l’intégrer dans le framework pour les développeur web avec des échéances: Django.

Mon premier serveur GraphQL!

Comme cet article n’a pas vocation d’être un cours sur Django, je vais supposer que vous êtes familier avec Python & Django. Les notions seront expliquées puis illustrées en Python.

Pour créer une API avec Django, il est courant d’utiliser Django Rest Framework (DRF pour les intimes). En effet avec DRF, il faut créer un modèle (classe ou entité), son sérializer, sa vue et ajouter le endpoint adéquat. Grace à GraphQL, eh bien vous n’avez qu’à définir le modèle et le schéma!

Jetons un coup d’œil au fichier models.py

from django.db import modelsclass Todo(models.Model):
name = models.CharField(max_length=100)
completed = models.BooleanField(default=False)
def __str__(self):
return self.name

On définit ici une entité Todo, possédant deux attributs: name et completed.

GraphQL à la rescousse!

Pour requêter une API GraphQL, l’on utilisera un seul endpoint. Dans notre cas, nous choisissons /graphql.

from django.conf.urls import url
from django.contrib import admin
from graphene_django.views import GraphQLView
urlpatterns = [
url(r'^admin/', admin.site.urls),
url(r'^graphql', GraphQLView.as_view(graphiql=True)),
]

Toutes nos requêtes se feront via cet endpoint!

On dispose de deux types de requêtes: les Queries et les Mutations. Les Queries consistent en une opération de lecture de données (le R de CRUD). Les Mutations par contre, effectuent l’opération d’écriture des données (finalement, il reste CUD).

Donc si je veux créer une nouvelle tâche, je dois effectuer une mutation sur l’API GraphQL? Absolument!

Un resolver sert d’intermédiaire entre une opération GraphQL et la logique serveur adéquate (Le C de MVC). Si je veux créer une tâche, je dois créer un resolver create_todo, et je l’associe à la mutation.

L’association…

class Mutation(graphene.AbstractType):
create_todo = CreateTodo.Field()

Puis la définition du resolver

class CreateTodo(graphene.Mutation):
class Input:
name = graphene.String()
completed = graphene.Boolean()
todo = graphene.Field(TodoType)
@staticmethod
def mutate(root, args, context, info):
completed = True if args.get('completed') else True
todo = Todo(name=args.get('name'), completed=completed)
todo.save()
return CreateTodo(todo=todo)

Les développeurs Python auront remarqué la création d’une instance de l’objet Todo.

Mutation: création d’une tâche

On réalise la mutation grâce au résolver createTodo. Le résultat de la requête( à droite) retourne les champs demandés. Un autre exemple.

Mutation: Création d’une autre tâche

C’est la même action que la précédente. Par contre, seul le champ completed a été demandé. Ainsi la réponse ne contiendra que ce que vous aurez demandé.

Avec GraphQL, le client peut recevoir uniquement les données qui lui sont indispensables.

Une Query!

On récupère ci-dessus, toutes les tâches créés. On peut également récupérer une seule tâche.

Query

GraphQL, c’est tout?

Absolument pas! Il reste un certain nombre de notions à appréhender: les Aliases, les Fragments, les Variables, le Caching, la Pagination, … RTFM

Conclusion

GraphQL nous oblige à repenser totalement nos échanges client-serveur afin de conférer une autonomie totale au client. La qualité des implémentations de GraphQL dans les autres langages hormis JavaScript (maintenue par Facebook) est souvent décriée. Raison pour laquelle, Netflix a créé Falcor, son alternative à REST. Toutefois, l’adoption autour de GraphQL prouve que cette spécification a de beaux jours devant elle.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store