les architectures REST ne sont pour autant pas parfaitement adaptées à tous les usages et ne peuvent pas facilement répondre à toutes les problématiques car :
-
REST est tout ou rien, si vous requêtez un objet vous aurez spontanément tous les champs de l'objet ou rien.
-
REST oblige souvent à enchainer plusieurs appels pour obtenir les données souhaitées.
-
REST n'est pas fait pour gérer facilement les relations entre objets.
-
REST est statique, vous obtenez la réponse que le développeur de l'application a décidé de définir.
-
REST impose des échanges entre développeurs afin que les API REST implémentées puissent convenir à tous les projets.
-
REST n'est d'aucune aide pour vous garantir le type des données échangées.
- Créé par Facebook en 2012 qui avait commencé à l’utiliser pour ses propres besoins, les sources de ce projet en été libéré en 2015.
- GraphQL est avant tout un langage d'interrogation comme le SQL, où le format de la requête est le même que celui de la réponse.
" Pour utiliser GraphQl il faut définir le modèle de donnés ,"
- Le schéma avec les objets et les types de champs,
- Les requêtes,
- Et pour chaque objet métier la source de données.
-
- La source de données peut-être : --Une base de données relationnelle, --Une base NoSQL, --Une API REST
**Graphql: permet de lié les objects métiers entre eux juste en jouant sur les relations entre ces objets meme s'ils font pas partie de la meme source de données ou de technologies.**
GraphQL est capable de requêter un nombre inconnu d’éléments et d’y appliquer des conditions et filtres
GraphQL utilise l’introspection, ce qui facilite la génération de la documentation et l’autocomplétion.
DES TYPES PERSONNALISÉS
Un bundle symfony permet implémentation facile des images et des fichiers dans une API GraphQL (le paquet avec l'implémentation de GraphQL et sa documentation est ici) ID GraphQLFilesBundle
GraphQL met à disposition l’objet GraphQLScalarType qui permet de créer des types plus complexes et personnalisés que ceux proposés par défaut dans un projet quelquonque. Liste des Types mise a disposition
- ID GraphQLID
- BOOLEANGraphQLBoolean
- INT GraphQLInt
- FLOAT GraphQlFloat
- STRING GraphQLString
- LIST GraphQLList
Une Query est le type de requête possible pour la lecture. On définit le schéma côté API et le client pourra récupérer les champs qui lui sont nécessaires parmis ceux rendus disponibles dans le schéma. On peut définir des paramètres pour la méthode : Ex: Filtres, limites, ...
Une Mutation est le type de requête pour l'écriture. De la même façon, on va définir la liste des mutations disponibles avec les type d'objet en Input, les données demandées au client. Pour la réponse, on définit un type d'objet Payload qui s'utilise de la même façon qu'une Query.
Ceci permet de faire une requête d'écriture et de demander les données que l'on souhaite en retour dans le Payload.
L'upload de fichier fonctionne simplement via les requêtes multipart/form-data. On récupère le fichier via l'objet Request.
Côté front, des libs existent aussi bien pour Apollo et Relay.
Explications avec le bundle Symfony
L'authentification fonctionne tout comme avec une API REST. Nous avons fait la demo avec les tokens JWT. Donc on ajoute le header Authorization: Bearer XXXX.
Le Bundle et la lib n'obligent en rien à suivre les spécifications Relay. Or, ce sont celles-ci qui sont suivies par les libs front-end (Relay et Apollo).
Explications sur les specifications
Api-Platform - La version 2.2 propose une API GraphQL simplement en ajoutant la lib GraphQL. Fonctionnaltiés :
- Pagination
- Les filtres (intégrés et personnalisés)
- 100% des principales spécifications, incluant les requêtes et mutations.
- 100% de la spécification serveur relais de GraphQL (et qui est compatible avec aussi bien les clients Relay et Apollo GraphQL)
- La validation
- Les règles de contrôles d’accès
- La génération de requêtes SQL optimisées (jointures automatiques en fonction des données demandées)
- L'UI GraphiQL
Plus d'information sur le blog de Les-tilleuls.coop
L’implémentation de GraphQL Dans un projet est simple à prendre en main et les performances du langage permettent de construire une API performante.