GraphQL est devenu une approche classique dans nos applications.

Les avantages apportés sont maintenant reconnus.

Le principal avantage  apporté est que les différentes requêtes métiers sont maintenant portées par le client. On évite la multiplication des end-points spécifiques qui tentent maladroitement de respecter les conventions inhérentes à REST.

La mise en place du approche GraphQL dans nos applications passe par l’utilisation d’une lib et d’un peu de configuration. Chaque stack technique possède sa lib.

On peut même trouver le composant Apollo, qui vient se faire l’interface pour une application legacy qui ne serait pas en mesure de mettre en oeuvre nativement un end-point GraphQL (Apollo fera l’objet, probablement, d’un prochain article).

Aujourd’hui, je viens vous présenter la librairie Caliban.

Caliban est librairie écrite en Scala et qui permet d’exposer un end-point GraphQL. Jusque-là nous sommes dans le thème avec le sujet de l’article 🙂

Avec GraphQL, on doit fournir un schéma décrivant les données manipulées par l’application et ainsi permettre au client de construire ses requêtes GraphQL.

Hormis le simple faite que la lib soit écrite en Scala, la librairie s’appuie sur la puissance du système de type du langage pour la génération de ce schéma.

Pour ce faire, Caliban va s’appuyer sur la dérivation des types pour découvrir la structure des données et enfin générer un schéma.

Cette approche est particulièrement intéressante, cela veut dire que la maintenance du schéma se fait automatiquement avec l’évolution du code.

Caliban s’appuie sur la librairie Magnolia pour dériver le model (librairie éditer par propensive – Jon Pretty ).

3 types d’actions sont proposées dans l’implémentation :

– Mutation  : ce qui va opérer les changements sur notre modèle

– Queries : Ce qui va permettre de lire les informations

– Subscription : Exposition d’un stream sur lequel on pourra recevoir des événements sur les modifications du modèle.

Aussi, Caliban supporte Zquery. Ce qui lui permet des optimisations (Cache, Batch) ainsi que s’interfacer avec plusieurs datasources.

On vient principalement de parler de la partie serveur. Caliban propose également la partie client qui est en mesure d’exploiter le schéma généré pour créer le client correspondant.

On constate que cette librairie propose plusieurs avantages sur l’approche GraphQL.

Un autre aspect très intéressant de cette librairie est à noter.

Avez-vous entendu parler des IO monade (une introduction au concept a été faite sur ce blog dans un autre article).

Cette approche émergente dans le code commun, fait qu’il n’est pas encore évident de trouver un ensemble de composants constituant la stack applicative (serveur, accès aux données, etc).

En effet, lorsque l’on implante les IO dans son code, il important qu’on les retrouve à tous les étages. Ci-dessous un exemple :

– Serveur d’api : Http4s

– Accès à la base de données : Doobie / Quill

Si l’on veut enrichir notre application avec une couche GraphQL, il faut que le composant que l’on va rajouter support les IOs.

Bonne nouvelle, Caliban qui supporte Cats et Monix est IO Monade compliant ! 🙂

Un avantage supplémentaire pour Caliban.

Pour résumer, les raisons d’adopter cette libraire sont nombreuses, en plus de l’adoption de GraphQL.  Personnellement, les deux principales qui m’oriente vers ce choix sont :

– L’utilisation du système de type pour générer le schéma ==> Sureté dans le code

– Propose le support des IOs ==> Cela s’inscrit dans la mouvances des applications modernes.

Le mieux maintenant est de l’essayer : https://ghostdogpr.github.io/caliban/ : )