Mettre à disposition un service consiste aujourd’hui à développer une application ou un site web, et à le faire communiquer avec le backend afin d’afficher les données à l’utilisateur. Ces données proviennent en général d’une base, elles sont récupérées par les applications à travers des appels réseau.
Cette communication se fait généralement en utilisant une architecture existante. A l’heure actuelle, les architectures les plus connues sont RPC, SOAP, REST et GraphQL.
Intéressons-nous à cette dernière et essayons de définir en quoi elle diffère des autres, quelles sont ses faiblesses et ses forces.
Présentation de GraphQL
Cette architecture d’API, disponible en open source depuis 2015, a été développée par Facebook dans le but de simplifier les échanges de données entre applications mobiles et serveurs, en autorisant les premières à demander exactement ce dont elles ont besoin aux seconds, et de l’obtenir avec un seul appel réseau.
GraphQL repose sur la mise en place d’un schéma décrivant les entités pouvant être récupérées par les clients, le nom et le format des champs de ces entités, et les relations entre ces mêmes entités. Le schéma sert de contrat entre le backend et le frontend, son typage fort garanti le format du retour.
GraphQL met également à disposition des clients un langage de requêtage qui va permettre de récupérer exactement les données dont elles ont besoin, à travers une ou plusieurs entités, ou d’effectuer les mises à jour nécessaires. Les données sont, coté serveurs, agrégées à partir de différentes sources : bases de données SQL / NOSQL, autre API, etc… La requête et la réponse ont exactement le même format, ce qui facilité la récupération coté front.
Apollo est aujourd’hui l’implémentation la plus populaire et la plus aboutie de GraphQL. La librairie Apollo est implémentée sur pratiquement toutes les technologies existant à l’heure actuelle, aussi bien coté serveur que coté applications (mobile et web).
Exemple d'implémentation
Pour notre expérimentation, nous avons développé un back en nodejs avec l’aide du framework NestJS, et une application mobile en Flutter.
NestJS
L’intégration de GraphQL dans une application NestJS passe par le module @nestjs/graphql, lequel se repose sur l’implémentation pour Express de Apollo, apollo-server-express.
La mise en œuvre demande de définir :
- Les entités présentes dans le schéma ; on défini les classes et on les annote afin d’indiquer à GraphQL qu’il s’agit d’objets représentant des entités
- Les resolvers ; ce sont des services qui décrivent les requêtes disponibles pour les clients, chaque requête récupérera les données sur les sources souhaitées (BDD, API, etc)
Flutter
Coté Flutter, la librairie graphql offre une implémentation en dart pur du client Apollo.
Il existe également une librairie orientée pour Flutter qui offre un panel de widgets permettant d’exécuter les requêtes et d’injecter leur résultat dans la vue. Nous avons choisi l’implémentation dart car elle permet un meilleur découpage des responsabilités de chaque classe.
La connexion au serveur passe par l’implémentation :
- D’un client ; le client se connecte au serveur définit à l’aide d’un objet HttpLink, on pourra lui adjoindre un mécanisme d’authentification à l’aide d’un objet AuthLink. Le client offre un système de cache qui autorisera l’exécution de l’application en offline.
- Des requêtes ; on décrit les données que l’on cherche à récupérer, elles nous seront retournées sous la forme d’un flux JSON que l’on pourra alors parser/
Avantages et inconvénients
Le gros avantage de cette technologie est qu’une fois mise en place, les applications clientes sont indépendantes des serveurs et peuvent évoluer sans avoir à modifier les API exposées.
Par ailleurs, là où REST nécessite parfois plusieurs requêtes pour récupérer une agrégation de données, GraphQL autorise l’envoi d’une seule requête qui renverra la liste des entités nécessaires et les liens entre elles. La gestion de la modularité côté client est également grandement facilitée du fait que l’on peut « composer » la requête. Ainsi, on peut facilement personnaliser en fonction par exemple du rôle de l’utilisateur ou de ses droits.
Enfin, GraphQL autorise les clients à mettre en place des écouteurs afin d’obtenir les mises à jour des données en temps réel.
GraphQL est en revanche plus difficile à prendre en main que REST, l’écriture du schéma peut être un vrai défi quand les entités et le lien entre ces dernières devient complexe. La gestion d’un cache est également plus complexe à mettre en œuvre qu’avec REST.
Par ailleurs les performances de l’architecture peuvent être mises à mal sur des utilisations intensives, et la scalabilité d’un tel système peut être difficile à régler.
L’ensemble de ces remarques pourra ainsi amener à créer un système hybride entre REST et GraphQL, les deux fonctionnant parfaitement de concert. On pourra ainsi par exemple gérer l’authentification en REST pour plus de simplicité, et ouvrir un accès en GraphQL pour récupérer les données.
Conclusion
L’architecture GraphQL se prête particulièrement à une utilisation coté mobile où elle permettra de réduire le nombre des échanges avec le serveur, et permettra à l’application d’évoluer sans nécessiter de développement coté API.
Elle nécessite cependant un investissement pour sa mise en place plus important que sur une architecture REST.
Si vous souhaitez en savoir plus, n’hésitez pas à nous contacter via notre formulaire de contact.