React Beer Lille : Zoom sur GraphQL !

SFEIRCode
SFEIRCode
Mar 4 · 6 min read

Le 26 février SFEIR Lille a eu le plaisir d’accueillir la 10ème édition du React Beer Lille sponsorisé par Saveur Bière. Ce nouveau Meetup fut placé sous le signe de GraphQL et Apollo, présentés par Adrien Harnay de chez Brigad.

Pour l’occasion, Julien Hery, Sylvain Magnier et Romain Torond, tous développeurs chez SFEIR, se sont transformés en journalistes le temps d’une soirée !

GraphQL, qu’est-ce que c’est ?

GraphQL est un langage de requêtes et un environnement d’exécution, initialement créé par Facebook puis rendu open-source par la suite. Depuis 2019, il est également le langage de requêtes standard destiné aux bases de données orientées graphes.

Cette présentation a permis aux participants de découvrir comment utiliser GraphQL avec React via Apollo. Ce dernier est une plateforme fournissant divers outils (client, server, mobile, cloud, …) permettant d’implémenter simplement GraphQL dans votre application.

Adrien nous a donc parlé de la partie client et de son utilisation avec React. Il a d’abord mis en évidence certains problèmes avec les API actuelles comme l’over-fetching (récupérer des données dont on n’a pas besoin) ou, à l’inverse, l’under-fetching (devoir faire plusieurs appels pour avoir la donnée complète). GraphQL remédie à ce genre de problème puisqu’il permet de décrire la donnée que l’on souhaite recevoir. Il présente aussi d’autres avantages comme le fait d’être indépendant du langage, du framework ou du type de base de données ce qui le rend facilement intégrable.

Apollo, une solution intéressante pour utiliser GraphQL.

Après cette rapide introduction Adrien a vite enchaîné sur le coeur de la présentation à savoir Apollo. Bien que son discours se soit concentré sur React, des implémentations sont disponibles pour les autres frameworks. Il nous a montré à travers divers exemples comment mettre en place le client pour React.

Les habitués n’ont pas été dépaysés puisque l’on retrouve une syntaxe assez similaire à Redux avec un Provider qui va venir entourer l’application. Puis, de manière plus précise, nous pouvons utiliser soit le composant Query ou bien le hook useQuery pour effectuer des requêtes et récupérer de la donnée.

Ces éléments nous fournissent plusieurs outils : on peut savoir si la donnée charge via un booléen ou on peut ré-effectuer l’appel si besoin via la fonction refetch par exemple. Le comportement sera similaire pour les mutations avec le hook useMutation par exemple. Une fonctionnalité de souscription est également disponible de la même manière afin d’obtenir immédiatement les mises à jour d’une donnée.

Apollo va également se charger de mettre les données récupérées en cache. Pour cela 4 options sont disponibles :

  • Cache first (si la donnée n’est pas présente dans le cache on effectue une requête)
  • Cache and network (on récupère la donnée du cache mais on effectue quand même la requête)
  • Network only
  • Cache only

Adrien a ensuite montré qu’il était également possible d’utiliser Apollo avec une API REST classique via quelques paramètres supplémentaires. Il a conclu en partageant son expérience. Pour lui, l’utilisation de GraphQL a permis une meilleure communication entre les équipes en ayant un langage commun qui permet, grâce à son typage fort, de documenter automatiquement les API. Des extensions sont également disponibles pour les IDE afin d’obtenir de l’autocomplétion.

Après le talk d’Adrien, nous avons trouvé intéressant d’en savoir plus sur son parcours, ses inspirations et de revenir sur quelques points de sa présentation autour d’une interview plus informelle :

Peux-tu te présenter ?

Moi c’est Adrien, je suis développeur depuis 5 ans maintenant. Après le bac je ne savais pas trop quoi faire. Un jour j’ai aperçu une publicité d’une école informatique, sans trop réfléchir je me suis rendu aux portes ouvertes et j’ai tout de suite été passionné. J’ai donc étudié à Epitech Paris.

Les deux premières années étaient assez difficiles mais maintenant c’est une vraie passion et je suis vraiment très content de faire ça tous les jours, de résoudre des problèmes avec la “magie” du code.

Tu travailles chez Brigad c’est ça ?

Effectivement, je travaille chez Brigad depuis 4 ans en tant que Lead Front-end Engineer. Au quotidien j’accompagne l’équipe Front-end sur des problématiques techniques, je fais en sorte que notre solution scale et que nos différentes applications soient viables techniquement. Je suis aussi en charge du design system qui met en commun le dev web et mobile pour pouvoir avoir le même code sur les deux appareils.

As-tu des passions ?

J’ai pas mal de passions oui. J’aime beaucoup la musique, je joue de la batterie depuis 8 ans et je me suis récemment mis au piano. Je suis aussi un adepte de sport, je pratique le tennis, la boxe et aussi le volley.

J’adore les animaux, j’en ai d’ailleurs pas mal : un chien, une tortue, un canard, avant j’avais aussi des poules !

Et enfin j’aime aussi les gens de manière générale. J’aime rencontrer de nouvelles personnes.

Avec quel langage as-tu débuté ?

J’ai commencé sur du Javascript & VB.NET.

Le back-end/ front-end n’étaient pas trop dissociés à cette époque et dans ma première boite c’était en VB.

J’ai appris à faire du JS en Vanilla et ensuite Angular, puis je suis allé naturellement vers du React et j’y suis resté puisque c’est ce qui me permet d’être le plus efficace et le plus rapide pour produire.

React VS angular ?

Pour moi, je préfère React puisque je sais résoudre un problème dessus plus rapidement qu’avec Angular même si on m’a dit que les dernières versions étaient très bien mais je n’ai pas pris suffisamment de temps pour être aussi bon dessus que sur React.

As-tu une nouvelle techno, un nouveau langage que tu as envie de creuser ?

Pour le moment je préfère ne pas trop m’intéresser à de nouvelles choses mais plutôt me concentrer sur ce que je fais actuellement et comment je peux améliorer l’efficacité de mon équipe et des outils qu’ils utilisent.

Sinon je m’intéresse quand même un peu à Reason et à aller voir des talks sur des sujets que je connais déjà et apprendre de nouvelles choses ou des sujets qui, à priori, ne m’intéressent pas forcément et en sortir avec une bonne surprise.

Pour toi, quelles sont les raisons principales d’adopter GraphQL ?

La première chose serait pour moi la facilité de prise en main et de communication : on peut facilement découvrir son API et voir tout ce qui est disponible sans avoir à parler à un autre développeur.

Le deuxième point serait bien évidemment la performance. Pouvoir être maître de ce qu’on va aller chercher et faire gagner du temps à son équipe.

Y-a t’il des points de vigilances sur Apollo ou sur GraphQL que tu souhaites nous partager ?

Je dirais qu’Apollo est encore un outil récent qui mérite encore des améliorations. De ce fait, lorsqu’on rencontre un problème, il arrivera rarement que la personne qui vient à votre aide règle le problème de A à Z. Il y a toujours quelqu’un pour explorer la codebase et apporter des conseils mais il faut avoir envie de s’impliquer dans la résolution du problème et d’ajouter sa pierre à l’édifice.

Y-a t’il une chose, une fonctionnalité que tu aimerais bien voir arriver dans GraphQL ?

Parfois, certaines normes ne sont pas forcément définies comme par exemple au niveau de certains types de pagination qui peuvent être painful à mettre en place côté back-end et du coup ce serait intéressant de le solutionner en mettant notre propre solution en place.

As-tu d’autres alternatives à Apollo pour utiliser GraphQL ?

Apollo est un peu le char d’assaut où on va pouvoir avoir le state local, on va pouvoir taper sur les API rest et ça va gérer le cache pour nous.

Si on veut quelque chose de plus simple à la manière d’un Fetch, on peut justement utiliser Fetch pour taper sur les API GraphQL et récupérer la donnée.

Après il y a d’autres lib avec d’autres défauts et une autre approche comme URQL et Relay (mis en place par Facebook) qui est un char d’assaut encore plus gros et un peu plus dur à prendre en main. Je ne l’ai pas encore utilisé mais les retours d’expériences que j’ai eu dessus en tout cas disaient que, sur le long terme, il serait plus solide.

Apollo est une solution totalement gratuite ?

Chez Brigad tout ce qu’on utilise est gratuit, la seule chose qui est payante est la partie analytics c’est-à-dire tout ce qui permet de savoir les champs utilisés sur les différents appareils. Au départ ce n’est pas forcément nécessaire d’avoir cette partie mais une fois que l’on est à fond sur GraphQL c’est vraiment intéressant.

Pour finir, as-tu une punchline, un slogan qui te définit, qui te ressemble ou que tu affectionnes ?

“Comment est votre blanquette ? OSS 117”

Nous espérons avoir pu vous aider à mieux comprendre l’intérêt et les caractéristiques de GraphQL si vous n’avez pas eu l’occasion d’assister à l’événement ou si certains points avaient besoin d’être éclaircis !

N’hésitez pas à nous rejoindre sur Twitter & Linkedin pour connaître l’actualité de SFEIR Lille !

Julien Hery, Sylvain Magnier et Romain Torond

CodeShake

Learnings and insights from SFEIR community.

SFEIRCode

Written by

SFEIRCode

Code with passion. Our goal is to help developers and technologies to reach their full potential #SFEIRCode FrontEnd / BackEnd / Mobile / Cloud / Data / DevOps

CodeShake

CodeShake

Learnings and insights from SFEIR community.

More From Medium

More from CodeShake

More on Life from CodeShake

More on Life from CodeShake

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