Bonjour à tous, bienvenue sur ce nouvel épisode de Double Slash, donc épisode numéro 13
déjà et donc comme d'habitude on est avec Alex, salut Alex !
Salut Patrick, salut tout le monde ! Donc Alex qui a un petit petit voix aujourd'hui.
Ouais, je suis désolé, j'ai la voix en feu, le froid est arrivé je crois.
Ouais le froid on va dire. Et le sujet du jour aujourd'hui c'est un sujet assez intéressant.
Alors on va parler de GraphQL, donc on a préparé un petit sommaire sur GraphQL,
donc on va parler de déjà faire un petit résumé d'aide l'ES, restes et tout ce que ça implique,
expliquer ce que ce qu'est GraphQL et pourquoi. Et vous expliquez aussi un petit peu l'utilisation
de GraphQL, comment ça fonctionne, on verra l'imitation etc. Les avantages et
inconvénients évidemment pour pourquoi utiliser restes ou GraphQL. Et on va finir aussi par les
outils, les outils les plus utiles pour tout ce qui gravite autour de GraphQL. Donc on va quand même,
je vais quand même vous rappeler, d'habitude on le fait à la fin de l'épisode mais on va
changer ça. On va le faire au début d'épisode comme ça vous l'entendez. Donc si vous aimez
le podcast double slash pour nous récompenser c'est assez simple, ça serait vraiment sympa,
nous mettre une petite note sur Apple ou Spotify, tout le n'importe quelle plateforme que vous
utilisez et un petit commentaire ça serait sympa pour nous soutenir, ça nous fait plaisir et en
même temps ça nous fait remonter dans les classements donc ça nous donne un peu plus de visibilité.
Donc un grand merci à vous pour l'action que vous allez faire.
Oui un grand merci et puis déjà merci aussi à tous ceux qui nous écoutent déjà. On se rend
compte quand même qu'il y a pas mal d'auditeurs et ça fait super plaisir. Donc on fait ça.
Trèsième numéro donc si toi tu es un peu superstitieux mais en tout cas ça commence mal
c'est un bon épisode sur GraphQL, c'est un épisode qu'on discute depuis longtemps,
qu'on veut vraiment faire depuis longtemps et donc on y va. Donc c'est cool. GraphQL.
Allez go. On va commencer de suite par pourquoi aujourd'hui on a besoin de REST ou de GraphQL.
Pour rappel REST a été inventé, enfin créé, il y avait déjà des protocoles qui existaient
avant ça on avait du saup ou des choses comme ça qui sont un petit peu très sympa à utiliser.
On va résumer ça comme ça. REST a été créé en 2000, donc contrairement à Saup qui est un
protocole comme HTTP par exemple, REST est une norme qui définit comment créer une sorte
d'API avec des réponses, un tout protocole. Donc ça a été créé en 2000, en 2000 je ne sais pas si
vous vous souvenez, ça fait quand même assez loin. L'iPhone n'existait pas, enfin tout ce qui était
mobile n'existait pas, on n'avait pas de headless comme aujourd'hui. On faisait surtout des gros sites
monolithiques et puis voilà avec un côté serveur, un côté front et puis voilà. Donc aujourd'hui
c'est vrai qu'on a quand même besoin de beaucoup plus d'API, tous les gros services qui existent
aujourd'hui ont des API, on va citer Twitter, Facebook, enfin tous ces systèmes là, donnent accès à
des API pour utiliser les services. Donc c'est un petit peu pour ça qu'on a besoin de tout ce
qui reste ou GraphQL. Donc REST est utilisé depuis 2000, il est très bien, il sera encore beaucoup
utilisé GraphQL je pense, enfin je ne sais pas ce que t'en penses mais GraphQL est bien mais REST
fonctionne bien aussi. Et bien sûr tout marche en fait et pour avoir utilisé des API en immobilier,
ils sont encore en saup, donc il faut jouer avec. Le protocole fonctionne après, c'est
différentes manières de fonctionner, tout marche. Après je pense qu'on va le voir justement tous
les avantages et les inconvénients de chacun mais en tout cas GraphQL est partie d'un problème et
d'un besoin et ils ont trouvé une solution et ça vient un petit peu inverser le paradigme.
Ce qu'il faut juste savoir c'est que GraphQL à la base c'est un projet qui a été internalisé chez
Facebook, en fait ils ont développé ça en interne et ils ont commencé à bosser dessus en 2012
et après ils ont open sourcé en 2015. Donc ils ont vraiment travaillé dessus en interne d'abord et
après c'est et maintenant c'est vraiment utilisé partout par les plus gros quoi, Twitter,
Shopify, GitHub, un courseur à Yelp, New York Times, ils utilisent tous ce moyen pour
échanger les données. Chose importante qu'on n'a pas évoqué encore c'est que GraphQL en fait
c'est pas un langage à part entière, ok c'est un protocole mais c'est surtout un query language,
c'est une manière, c'est un langage en fait de requettage, c'est comment je vais aller
appeler mes données. Et donc c'est un langage à part entière qui vient structurer et qui change
un petit peu le paradigme par rapport au reste quoi. Donc on va dire le gros paradigme qui change
c'est que c'est le client en fait qui va demander les infos c'est à dire contrairement à du reste
où c'était un peu du push c'est à dire c'est le bac qui va pousser des infos sur une route,
là c'est le GraphQL qui va demander des informations et donc ça change toute la
manière de développer et de construire l'API. Juste pour résumer par rapport à,
enfin là tu parles justement de définir en fait ce qu'on demande comme info au serveur,
pour rappel en fait reste le principe de base c'est que chaque endpoint représente une
ressource en fait. Donc l'URL en fait représente une ressource on va imaginer un site qui a slash
api slash books par exemple et on va définir que ça la ressource ça sera les livres pareil pour
les auteurs donc chaque ressource à son URL donc ça veut dire quoi en fait en gros si vous avez
besoin des livres donc vous allez appeler l'URL books mais dans ces livres en fait vous allez avoir
aussi des auteurs par exemple donc pour avoir les auteurs des livres en fait il va falloir appeler
encore des URL pour récupérer chaque auteur donc tout ça ça fait voilà c'est très bien c'est
très structuré seulement l'inconvénient c'est qu'aujourd'hui avec les mobiles etc on a besoin
d'économiser un petit peu les ressources et gagnant vitesse aussi de chargement et ça fait beaucoup
de requêtes en fait donc ça c'est déjà un point que GraphQL résolve en partie quoi.
Ouais parce qu'il faut il faut faire chaque ressource est égal une route donc ça veut dire
il faut construire des routes au fermeture des demandes et si la demande de ressources par
exemple pour un client mail ou un client desktop je vais pas avoir besoin des mêmes informations
donc bah je vais toujours en fait soit avoir une route où il y a trop d'informations soit il y en a
pas assez donc c'est le under et over fetch excusez moi et donc je vais je vais je vais toujours
avoir soit pas assez soit trop d'informations du coup il faut reconstruire des routes et à la
fin il y a beaucoup beaucoup beaucoup beaucoup de routes si on a un client un client web un client
une autre API normal et une API un client mail un client mobile pardon ça peut faire beaucoup
beaucoup de routes et en termes de de maintenance c'est c'est juste catastrophique quoi c'est
compliqué ça devient ouais c'est aussi ça ouais c'est donc c'est un peu l'inconvénient de reste
c'est que donc si enfin quand on parle de reste comme ça de cet fonctionnement là on parle vraiment
des des API des grosses API qui vont être tweeters et compagnie donc où il y a beaucoup de gens qui
utilisent des API qui vont se connecter dessus et qui voilà qui ont besoin d'infos là votre
votre service il est créé via une API et le problème c'est que si à un moment donné twitter
décide de changer le nom d'une fin d'une valeur etc et ben là c'est bien compliqué puisque vous
faire une sorte de versioni en fait de la pays reste et on va passer de la v1 à la v2 puisque
les réponses vont changer les appels éventuellement vont changer et là ça devient un petit peu un
truc très compliqué puisqu'il faut qu'on se retrouve avec des versioning de la pays reste et
ben ça aussi pareil je crois que graffes que elle résout un peu le problème aussi c'est très simple
il n'y a qu'une seule route donc il n'y a qu'une seule route c'est le seul unique end point d'entrée
et en fait la logique va être répartie dans ce qu'on appelle des résolveurs qui vont venir
analyser la demande vu que c'est le client first ce qu'on appelle client first c'est le client qui
va faire la demande donc il va envoyer de l'information alors c'est que du poste ça fait
bizarre souvent on a l'habitude en reste d'avoir un verbe une route avec une ressource
ben là vu qu'il n'y a qu'une seule route il n'y a qu'un seul verbe c'est que du poste
ça fait un peu bizarre au départ après on s'y habite très très très très très vite et
en fait dans la demande qu'on va faire on va venir explicit la demande est vraiment explicite on
va demander la ressource donc nos livres et on va ouvrir des des accolades en fait dans notre
query qui est la demande d'information et on va lui demander que le titre la description et si
les ressources sont imbriquées côté à côté serveur on va pouvoir appeler aussi l'auteur par
contre l'auteur je veux que le nom de l'auteur et peut-être dans une autre page dans une autre
requête j'aurai besoin de l'auteur avec toute sa bio son avatar et tout ça mais ça sera le client
qui va demander donc en fait on n'a qu'une seule on n'a qu'une seule route à maintenir et c'est
le client qui demande les infos spécifiques qu'il a besoin yes en fait la plupart du temps enfin
je sais pas si c'est une norme mais c'est graffes c'est slag graffuel en fait en général dans les
services non c'est après tu peux mettre tu peux mettre ce que tu veux mais souvent c'est ça les
conventions bien sûr en termes de conventions c'est plus simple pour tout le monde de mettre
slash graffuel et puis comme ça on sait que on sait directement où aller quand même oui par contre
c'est vrai que tu parles de postes mais j'ai aussi des motes fin j'utilise des systèmes maintenant
où le get passe aussi sans problème alors je sais pas si c'est ça évolué ou ok alors je n'ai pas
jamais testé moi je suis été bête et discipliné jusqu'à là ouais c'est vrai qu'à la base c'était
comment il s'appelle pas ce man ça s'est mis à ouais et deux fois je passe en get ça passe
sans problème donc je sais pas je sais pas comment s'agir ça ça a l'air de plus trop être un problème
en tout cas aucune idée ouais bah on en parlera peut-être après sur le niveau du cash mais je
sais que bah juste en vrai on en parlera après donc ok donc en gros on a déjà vu à peu près
l'histoire pour quoi l'histoire bon c'est comme tu l'as dit c'est facebook qui a créé ça un peu à
l'image de bon alors facebook est très ils sont très créatifs on parle de réacte on parle de
graffuel mais il y en a tellement d'autres et ce qui est bien c'est qu'ils mettent un open source
donc ça nous permet de les utiliser et après évidemment c'est aussi ça qui a fait que que
graffuel a explosé c'est quand ils ont passé en open source fin si on veut utiliser une technologie
on est quasiment obligé de l'ouvrir si ça aujourd'hui ça me paraît difficile de rester sur
une techno propriétaire et d'avoir un taux d'adoption très très fort ouais ouais et en puissant
puis en général tu te dis bah si enfin si facebook ça fonctionne chez eux normalement ça devrait
fonctionner partout parce qu'on n'aura jamais la même charge que facebook donc ça se tient
ouais donc on va passer à l'utilisation tu vas nous expliquer un petit peu bah t'as déjà
commencé mais bah comment ça fonctionne sur sur sur les queries ouais alors en fait un truc un truc
typique j'aime pas du tout faire le parallèle entre les actions et les verbes entre les get
les postes et tout ça mais juste pour le besoin de l'exercice en fait on va on va imaginer que
moi je suis sur mon mobile et je veux afficher en fait tous les livres et bah ça serait l'équivalent
d'un get en fait bah là je vais faire une query et donc je vais marquer le premier mot de ma
requête ça va être query et à l'intérieur en fait je vais marquer je vais décrire tout tout ce que
bah toutes les ressources que je vais que j'ai envie d'avoir un gros avantage aussi c'est que
il ya de dans graphql la documentation se fait de manière incrementale et automatique c'est à dire
que quand le baccan a développé les résolveurs donc c'est la petite fonction qui va nous permettre
d'aller chercher les les bonnes les bonnes informations bah on va automatiquement générer
la documentation ce qui fait que moi je peux accéder à la documentation et je vois comment
est structuré et comment je peux appeler mes informations donc quand je vais faire ma query
avec books je vais voir en fait tous les champs qui sont disponibles pour la ressource book et donc
ça va être vachement plus facile et pareil si j'ai des ressources imbriquées les auteurs ou les
catégories les choses comme ça je vais pouvoir automatiquement voir dans la documentation ce qui
fait que mon marquette get fin ma query je peux la construire vraiment hyper simple et de manière
fluide même pour ingénieur par exemple qui arrive et qui connaît pas du tout la pays bah en fait
ça va être super simple parce que je vais pouvoir cliquer sur sur sur la doc et je vais avoir toute
la toute toute l'information tout est renvoyé de man sous en json sous alors ça c'est le gros
c'est équivalent à reste je vais envoyer l'information je vais récupérer l'information
en en json par contre moi je vais avoir aussi besoin de par exemple de créer des ressources et là
en fait ça serait l'équivalent d'un poste en fait je viens envoyer des informations ou et vous faire
une une édition donc put update et voilà et là pour le coup la sémantique a changé c'est ce qu'on
appelle une mutation et de la même manière dans la documentation je vais retrouver des des infos
sur les mutations que je vais pouvoir créer les ressources et je veux aussi avoir les champs qui
sont requis pour la création de cette ressource donc bah c'est vachement en fait l'utilisateur et le
client pour le coup la partie front elle est vachement drivé parce que bah c'est marqué noir
sur blanc sur le contrat qui est qui est le schéma et c'est vraiment le contrat entre le
backend et le front et c'est ce qui va donc c'est tous les échanges vont se faire via grave que elles
basé sur ce schéma là donc quand je vais ajouter une nouvelle ressource bah je vais avoir toute la
documentation qui va se faire automatiquement donc ça c'est pratique et surtout je peux pas me tromper
quand je viens envoyer une donnée elle est c'est marqué rick weyer si elle si si je l'ai pas
bah ouais c'est pas possible quoi donc ça vient rajouter une sorte de validation aussi au moment
de de l'envoi quoi ouais parce que en fait quand tu fais tu es pas je te commets pour en fait quand tu
fais tes résolvers au niveau du serveur tu fais aussi les schémas de toutes tes ressources en fait
comme tu fin comme tu l'expliquais et il ya un système de type page en fait à l'image de type
strip en fait où tu vas définir si c'est string si c'est obligatoire si c'est voilà toutes les types
de voilà le type des ressources donc c'est du type page donc ça c'est écrit comme tu dis noir sur
blanc et c'est vrai que c'est très pratique parce que quand tu utilises graphique u l ou n'importe où
une semdia tu as ouais automatiquement la doc avec les ressources qui s'affichent sur le côté donc
tu t'as même pas besoin de toute la disposition et en fait on exactement et en fait on on dit
quand on développe souvent alors il ya une approche même si elle peut être controversée parfois mais
il ya une approche qui dit skim a first quoi c'est à dire avant de faire notre notre api la partie
front et la partie back va va se mettre autour de la table et va vont écrire le schéma le schéma
ensemble et donc ils vont définir tous les types donc type type book après on va avoir
différents différents champs et donc titel auteur voilà n'importe quoi donc ça c'est des champs et
après on va avoir ce qu'on appelle en graphique des scalards ça va être des strings des id des
intégers un boulet un dison ou un autre type par exemple un auteur à plusieurs bouquins donc
il va avoir un champ de books et après on va avoir un tableau de type book donc c'est vraiment
du type h pour ceux qui connaissent type script voilà on est on est on est assez proche par
contre il faut faire attention le schéma ne veut pas dire le schéma de base de données
et souvent en fait on fait on fait un rapprochement entre les deux on se dit ouais le schéma ça va
être le schéma de base de données alors que pas du tout c'est vraiment le schéma comment on va
appeler les données peut-être que les données les données en en dans la base vont être structurées
différemment même si souvent on y est très très très proche mais on peut avoir d'autres informations
qui ne sont pas qui ne sont pas à plable on va dire par par le client parce qu'on a besoin de
stocker d'autres informations pour faire des calculs ou que c'est donc ça c'est en fait c'est plus le
modèle de tes résolveurs puisque les résolveurs en fait ils vont appeler bah si je prends un exemple
de php n'importe et en fait tu crées des résolveurs pour les books par exemple et après ton résolveur
bah quand on appelle des books il va les chercher dans la base de données le title l'auteur etc et
ça correspond à ce que tu veux renvoyer en fait pas forcément à tout ce qu'il y a dans la table
book en fait c'est ouais c'est exactement c'est plus le résolveur mais donc et donc c'est
vraiment le résolveur qui va déterminer ce qui est renvoyé et tout ça c'est tout se fait dans
le résolveur ouais et troisième petit truc qui est quand même assez sympa dans gravql il ya une
autre dimension donc il y a les queries pour récupérer de la donnée il ya les mutations pour
les envoyer et il ya une autre une troisième partie qui s'appelle des souscriptions et qui s'apparente
à du web socket en clair la query elle va pas partir et s'arrêter on va ouvrir un channel donc
c'est web socket et en fait on va aller à l'écoute de toutes les instances de pardon de la ressource
qu'on a choisi par exemple je vais écouter toutes les transactions bancaire par exemple et à chaque
fois qu'il y a une transaction bancaire qui apparaît et bah en fait elle va popper automatiquement
sans donc c'est vraiment c'est l'équivalent d'un web socket un channel ouvert et je viens
écouter toutes les nouvelles ressources qui apparaissent donc ça c'est pratique aussi parce
qu'on n'a pas besoin de mettre en place une autre une autre techno c'est dans le même
langage c'est dans le même la même façon d'appeler les données et on va récupérer ce côté
instantanéité immédiaté donc ça c'est plutôt pratique alors pour pour expérience on aurait envie
de le mettre un peu partout on dit ouais on fait des subscriptions des subscriptions ouais et puis
finalement non il faut se poser vraiment la question est-ce qu'on a vraiment besoin d'une
instantanéité d'une instantanéité sur sur cette ressource là dans cette page là et et après
on arrive à raison gardée et puis à trouver le bon juste milieu mais en tout cas c'est quand même
pratique d'avoir le côté le côté sans refraîche sur certaines ressources c'est quand même sympa
de pouvoir le faire avec la même brique techno carrément tu veux comme par exemple sur twitter
par exemple les messages privés quand tu es en train d'écrire à quelqu'un tu vois qu'il écrit
aussi en même temps tu vois après tel message message qui monte tout seul c'est un peu ce type
d'usage en fait et ouais c'est top en plus que ça soit intégré directement dans graphql c'est
après ça fonctionne alors pas de hard-conneries moi j'ai jamais utilisé ça toi tu l'ai utilisé c'est
plutôt lié à notre je pense pas que sur php qui puisse le faire sur un server php qui
renvoie du graphql je pense que c'est plutôt sur du nôtre principalement après je peux dire
de connerie en fait ça va ça va ça va dépendre comment tu a implementé ta librairie graphql
parce que aujourd'hui toutes les toutes les tous les langages majeurs en fait l'on l'a implementé
donc ça soit en php javascript go ruby ou voilà tout tout tout tous les langages ont
développé leur leur client serveur pour pouvoir justement construire la pays graphql donc pour le
coup en php je pourrais pas parler je ne sais pas par contre ce qui est sûr c'est quoi sur côté
nod il ya des il y a des outils qui permettent de faire ça par contre les websquettes passe par
un autre channel qui s'appelle qui en fait on est obligé d'ouvrir un autre channel en wbs à côté
pour pour justement pouvoir avoir accès aux souscriptions donc en fait dans le client on est
obligé d'avoir un autre chose pour gérer ce côté justement instantanité quoi ah oui c'est pas une
spain requête classique c'est vraiment un truc à part non c'est pas sûr non en fait quand tu
vient implementer côté client il faut bien que ça passe par un autre un autre channel ok ok donc
ok bah pour résumer ouais donc tout ce qui est lecture c'est les queries tout ce qui est
modification c'est mutation enfin création modification c'est l'imitation et les subscriptions
pour tout ce qui est voilà websoquette avec des informations qui reviennent toute seule
on peut parler aussi alors une des premières questions que j'avais moi quand j'ai commencé
graphQL c'était bah comment tu fais quand tu as des bah tu sais tu fais une query mais à un moment
donné tu veux tel id ou tu veux tel page ou tel ou faire une recherche par exemple tu ça fonctionne
comment en fait tu as une notion de variable en fait où tu vas pouvoir injecter des variables c'est
à dire que ma query elle accepte en paramètres un variable une variable et cette variable ça peut
être je peux la récupérer de mon de mon url par exemple en mode le truc classique books slash id et
bah je vais récupérer mon params id que je vais passer à ma à ma query et comme ça en fait ma
query elle accepte une variable de type id et comme ça j'ai mon résolveur qui va venir utiliser
cette id pour aller fêcher et faire une recherche sur cette id là et ça va me renvoyer la ressource
donc en fait on peut on peut variabiliser en fait les queries et les mutations parce que
bah de façon sur l'imitation il faut bien qu'on vienne injecter des données donc ces données elles
doivent être mis dans des variables et les mutations à chaque fois il me quand tu fais une mutation ça
te renvoie le spurt par exemple tu vas créer un book ça va te renvoyer l'objet en général si
si c'est enregistré correctement alors oui alors après en fait tu vas même choisir
tu vas même choisir ce que tu vas recevoir alors après ça va dépendre des use case mais parfois
tu as besoin de récupérer tout l'objet ou parfois tu veux juste vérifier que ton objet il est bien
enregistré en base de données et qu'il a une id et donc dans ce cas là au moment où tu vas faire
ta mutation il faut toujours que tu demandes quelque chose en retour et donc ce que tu vas
demander bah ça peut être juste l'id par exemple comme ça tu peux te mettre une notion de succès
uniquement à la réception de cette id ça veut dire que bah ton l'intégralité de tes données ont
bien été transmise au baccan et que le résolveur a fait a fait son boulot il est enregistré en base
de données il a une id il renvoie l'id donc moi côté client si j'ai mon id ça veut dire que
que mon côté que bah que toute mon action elle est propre elle est faite et elle est terminée donc
je peux afficher le succès sur sur mon client parce que j'ai mon id par contre bah tout ce que je
vais envoyer je vais je vais le recevoir aussi et une fois de plus c'est à la demande de toute
façon c'est c'est un peu le concept de graffes ql c'est tout est à la demande et c'est le client
en fait le front qui va demander qu'est ce que je veux comment je le veux et comment je veux le
structurer et on peut même aller pousser des trucs un petit peu plus loin en mode moi je veux pas
je veux appeler la ressource books par contre quand je l'appelle quand tu me renvoie l'information
de books moi je veux l'appeler librairie parce que j'ai envie de faire comme ça et ben le graffes ql
permet en fait de renommer les champs ce qui ce qui nous permet en fait de faire des variations
côté front assez rapidement alors après il faut pas jouer à ça parce que sinon ça va être vite
être le bordel mais en tout cas on peut on peut renommer les champs en fait hyper facilement donc
c'est aussi une ressource c'est plutôt une solution assez assez pratique et on va appeler
comment on veut et de la même manière on va pouvoir aussi appeler différentes ressources
au même niveau en fait on va construire son gisonne de retour en fait de la manière dont
on appelle les données va conditionner la structure et la manière dont vont être structurer l'information
à notre retour et donc ça c'est assez assez puissant c'est pour ça qu'on dit bah ces clients
de faire ce quoi c'est vraiment client et et l'idée je pense qu'elle est partie des développeurs
bac qui disaient non mais moi j'en ai ralcu de faire la même chose à chaque fois le front il change
il change d'avis il y a un designer qui a rajouté un petit champ un petit truc du coup une petite photo
du coup il faut il faut l'information il faut recréer une route il faut non moi ce que je vais
faire je vais coder un résolveur pour la ressource book et t'appelles comme tu veux t'appelles
les champs que tu veux tu les renommes comme tu veux tu fais ce que tu veux mais en fait ils
ont fait le boulot une fois et donc en termes de taffes bah c'est vachement plus avantageux de
passer sur du graffQL parce que bah t'as accès à tout et tu te sers et c'est le client qui demande
ouais c'est top c'est top et au delà de bah déjà au delà de pouvoir avoir les auteurs en même temps
que le livre etc on peut aussi faire plusieurs queries dans une seule dans un seul appel
exactement donc ça c'est top aussi c'est à dire que tu peux récupérer les livres mais tu peux
récupérer d'autres choses qui sont rien qui ont rien à voir avec les livres dans la même requête et
ça c'est exactement et au même niveau en fait je vais pouvoir appeler les books avec à l'intérieur
des books les auteurs à l'intérieur des auteurs les trois meilleurs book 1 classé par je sais pas quoi
et au même niveau que je vais pouvoir demander autre chose les commentaires de je sais pas quoi
vous le pouvez pas dire de la personne qui est connectée ou une connexion exactement et donc
vraiment appeler comme je veux mais c'est pas c'est pas une query une ressource
c'est vraiment une query autant de ressources que je veux bon après il faut aussi faire preuve de
bon sens quoi c'est est ce que on charge la page est ce que on charge dans le composant après
côté fronte après ouais c'est fin côté front il va falloir savoir qu'est ce comment on veut
structurer est ce que c'est chaque petit composant qui envoie sa requête ou justement on vient
utiliser la puissance de graphql en une seule requête pour récupérer toutes les informations
en une seule requête ce qui nous évite de de faire 5 6 7 requêtes sur une seule et même page
pour afficher toutes les informations là on n'a qu'une seule requête qui part avec ben toutes
les ressources dont on a besoin on récupère et on vient réhydrater exactement les informations
par rapport et donc en termes d'efficience ben c'est vachement plus intéressant quoi et on vient
moins taper le serveur dans tous les sens pour en plus récupérer des informations de l'auteur ça
se trouve on a toute la bio on a les 50 champs de l'auteur alors qu'on veut juste afficher son nom
ouais c'est clair donc là donc c'est c'est enfin quand on vient analyser le reste parfois ben
ouais on se rend compte qu'on utilise peut-être 5 ou 10 % des ressources qu'on a en dispo donc pourquoi
transporter de la data alors qu'on en a pas besoin ben c'est le concept qu'a résolu graphql quoi pour
justement passer sur un truc en demande carrément bon bah super du coup va passer aux avantages et
inconvénients même si les avantages on a déjà pas mal parlé je crois que c'est plus avantage on a
déjà bien avancé beaucoup mais quelles sont les inconvénients ton avis tu vas me dire il n'y en a pas
alors ben si si il y en a après le le premier problème même si dans les dernières versions
où c'est assez récent ils ont mis à jour je crois que cet été une librairie qui s'appelle apollo
où en fait qui vient faire des énormes progrès sur le cache ouais mais ouais le cache en fait c'est
ouais ouais vas-y on délègue tout et tout est dans cache sauf que ben deuxième problème qui arrive
tout de suite c'est oui mais quand est-ce qu'on vient invader le cache comment on le fait voilà c'est
c'est toujours toujours le problème donc c'est toujours compliqué de façon gérer du cache et
gérer ben à quel moment on le dégage à quel moment on le met on le met à jour par contre il y a
apollo qui qui ont fait des trucs plutôt sympa qui est en fait qu'on appelle de l'optimistique ui c'est
à dire en fait la réponse normalement ça devrait être id et le nom du bouquin alors dans le front
j'affiche ça en attendant la retour le retour du serveur et quand le retour du serveur je fais
la mise à jour avec les données serveurs en clair il vient regarder ce qu'on attend comme
réponse il part du principe que ça marche et il l'affiche et s'il y a des modifications il le fait
il le fait il vient réhydrater la donnée avec les infos avec les infos du serveur c'est un peu
complexe à mettre en place quand même je te cache pas donc donc et sur les dernières versions
d'apollo justement sur le client apollo apparemment ils ont simplifié ça n'ayant pas joué avec je
sur la dernière version je ne pourrais pas je ne pourrais pas dire mais en tout cas moi à chaque
fois on sait vraiment casser les dents sur le sur le cache c'est un peu complexe quand même
c'est un peu ce qui revient souvent sur graphique l'a pas la première le problème du cache en fait
tout simplement c'est difficile à gérer au niveau serveur parce que vu que c'est le client qui
demande ce qu'il veut donc c'est pas forcément toujours les mêmes réponses donc et en plus
il n'y a qu'un seul endpoint donc graphique par exemple slash graphique donc c'est compliqué de
gérer en HTTP déjà premièrement par rapport à reste d'avoir des du cache puisque les c'est
gait de faire des appels en gait parce qu'en gait justement tu peux avoir des roquettes
différentes puisque l'acquérité est dans l'url du coup et du coup l'url peut être mis en
cache donc j'ai vu j'ai lu cette solution là qui peut être mise en place en tout cas pour de la
lecture en fait de la query je connais pas ouais ouais c'est et puis après ouais c'est en fait ça
dépasse beaucoup le le cache du côté client en fait plus que côté serveur en fait ouais vachement
donc mais c'est vrai que c'est un des inconvénients en tout cas pour pour des petites saps ça
risque pas d'être un inconvénient mais c'est vrai quand tu as des API qui sont assez balèze qui sont
vraiment tapés de nombreuses fois par seconde ça peut être vite un problème donc ouais c'est
mais clairement ouais apollo tout ça il travaille beaucoup clairement après ouais ouais vraiment
après ce qu'il faut ce qu'il faut ce qu'il faut aussi bien définir c'est le scope du projet
faire une API grave que elle pour pour un blog est ce que c'est est ce que c'est juste nécessaire
ouais je sais pas voilà c'est en fait ce qu'il faut pour moi le le le graph que elle sur une API
un peu solide fat elle elle se justifie quand on va avoir plusieurs clients plusieurs
ouais quand qu'en potentiellement on va y avoir plusieurs clients et et une grosse évolution
dans la dans l'appli parce qu'on va garder cette flexibilité quoi c'est à dire que le résolveur
on va on va le coder une fois et puis et demain le lab l'app va évoluer beaucoup donc on va être
obligé d'or si on est obligé de changer à chaque fois les verbes ça les routes ça va être
compliqué bah là on fait du graph que elle comme ça on est on est un peu futur prouve quoi donc il
faut il faut bien définir parce que ça ça peut vite être super compliqué à mettre en place
une grave un un serveur graph que elle pour pour juste un blog quoi par contre ce que je comprends
aussi c'est l'intérêt du front d'utiliser une API graph que elle parce que bah je me fais je me
je me prends pas la tête j'appelle comme je veux et c'est pour ça qu'on voit toutes toutes les
librairies qui qui ont qu'ont explosé tous les cms et les un peu qui ouvrent des API graph que elles
justement parce que le front on va dire reprend un peu le pouvoir sur sur sur le bac parce que
bah il appelle comme il veut la manière dont il veut donc ça amène une grande liberté donc c'est
pour ça que c'est intéressant mais il faut bien bien savoir quand on commence quand on va fournir le
service via une API est ce que ça vaut le coup de le faire via du graph tuel ou via autre chose
et bien comprendre les tenants les les les aboutissants et sur quoi on s'engage pour voir si c'est
intéressant si ça vaut le coup ou pas quoi donc après moi je pense que aujourd'hui sur des
applications un petit peu plus conséquentes où aujourd'hui on arrive très vite à on va faire
une version mobile ou une version pwa par exemple hashtag épisode pwa avec stéphanie mais mais
avec stéphanie absolument mais bah si si en fait on veut créer un service web bah ok on va avoir
un service desktop par contre demain peut-être qu'on va faire une extension ou une version mobile
ou quelques sèches bah ça vous évitera de recoder plein de choses là le le serveur il est déjà
prêt et c'est le client qui va appeler les données comme il veut quoi donc ça va définir aussi les
ambitions et le scope du projet pour voir si c'est intéressant de pas de de coder directement sur
du sur du graph tuel ou pas ouais clairement enfin ça fin au niveau client au niveau développement
front c'est vrai que ça facilite grandement les choses et fait c'est même un régal c'est par
contre c'est vrai qu'au niveau serveur ça le fait ouais au niveau serveur par contre c'est beaucoup
plus complexe et c'est vrai que ça demande plus de travail pour les dev back pour implémenter toutes
les enfin voilà les schémas les résolveurs oui oui et non oui et non parce que parce que en fait
ça va faire plus de taf soit au départ sauf que derrière on y touche plus oui simplement
plus des roues c'est à dire que cette ressource là exactement et tout le travail qu'on a à faire
de maintenance ok bah donne moi une une ressource avec les bouquins et les commentaires et l'auteur
tu vois et en fait ça on a plu c'est ok je fais une fois le taf pour les bouquins je fais une fois
le taf pour les commentaires je fais une fois le taf pour les auteurs et après démerde toi
mon pote démerde toi et donc c'est là où ça ça comme pour moi c'est intéressant donc quoi peut
être qu'au départ c'est peut-être plus long à mettre en place peut-être quoi que après il
y a quand même des outils maintenant qui permettent de faire des choses quand même assez rapide et
plutôt plutôt propre mais si on veut faire les choses bien ça prend du tout de façon
ouais clairement mais mais bah clairement si tu vois en fait ça se calcule quoi ça c'est un
scale c'est un calcul qui doit se faire et c'est pas si délirant que ça tu vois il y a peut-être
un aller un tout petit sur et fort à faire au départ par contre demain sur sur le pour moi sur le
long terme tu tu y gagne mais vraiment j'ai d'accord je suis d'accord dans le cas où tu es une tu
crées un service qui va avec une API centrale et tu vas avoir différents clients qui vont se
connecter on peut imaginer des applications des trucs d'ordinateur n'importe quoi ouais clairement
moi je conseillerais de partir sur du graphQL comme ça tu es voilà tu as un vraiment une API robuste
et tu peux définir tu peux multiplier les clients après si tu fais un système beaucoup plus simple
où tu vas pouvoir tu vas faire des routes qui vont te renvoyer un peu ce que tu veux tu vois tu fais
un petit peu custom on va dire on fait un peu souvent quoi tu commence à faire tu es à rajouter
des choses dans les dans les réponses ouais là graphQL peut-être ça se discute parce que voilà
tu as la main sur les réponses et puis voilà tu vas le faire une fois tu vas pas trop modifier
il y aura qu'un seul client donc là ouais le le travail en fait peut-être pas la chandelle mais
ouais dans l'ensemble si vraiment tu vas avoir plusieurs clients où tu vas ouvrir ton API
etc. Ouais graphQL c'est quand même je pense il vaut mieux passer là dessus pour être tranquille
et puis ouais pas pas faire des pas faire des versions de API v1 v2 v3 c'est sûr voilà c'est
pour moi c'est sûr quand quand 2020 si tu veux faire une API c'est vachement plus facile de le faire
en graphQL d'autant plus que maintenant ou même un service parce que aujourd'hui graphQL il y a des
outils qui permettent de en fait moi ce que le truc puissant que je trouve à graphQL c'est que
c'est le seul dans c'est le seul point d'entrée pour n'importe quel client donc un client us un
client web un client voilà une autre API par exemple et c'est le seul point d'entrée et derrière au
niveau des résolveurs il y a possibilité de brancher une API REST il y a beau il y a possible
il y a possibilité de brancher une base de données il y a possibilité de brancher un autre service
tiers par exemple si mon service je vends des bouquins et je veux utiliser le service de paiement
stripe et bah je peux connecter mon stripe en graphQL à mon résolveur et en fait mon
comment le front tout va être géré via le seul endpoint de mon service par contre dans mon
résolveur je vais aller chercher la base de données je vais envoyer l'info à stripe via
graphQL aussi et ainsi de suite donc en fait je peux je peux venir connecter d'un service tiers
directement et c'est totalement transparent pour pour le client en fait et donc ça c'est plutôt
c'est plutôt pas mal et on peut aussi transformer des API REST en fait je branche les restes sur
mon graphQL alors je dois mapper tous les champs tout ça voilà il y a des outils qui font ça mais
ça marche plutôt bien et en fait c'est totalement transparent il n'y a qu'un seul point d'entrée
pour le client ce qui facilite énormément la vie clairement ouais ouais carrément et du coup
bah t'as sauté sur le dernier sujet les outils direct donc tu parlais de bah on peut parler de
prisma qui a alors prisma tu en avais parlé dans une conf c'était quoi les dernières je sais plus
prisma v1 et prisma qui a complètement changé sur la v2 donc ce que tu disais ou à la v1 c'était
ouais la v1 c'était ce que tu disais en fait c'est à la base c'était toutes les branches sur
n'importe quoi et il te renvoie du graphQL c'est ça non le principe de la v1 alors en fait la v1
c'était ils appelaient ça un ORM c'était l'orm intelligent et tout ça donc tu pouvais brancher
différentes bases de données et tout et lui il te générait tout et crud automatiquement et et t'avais
bah toutes tes résolveurs qui étaient déjà prêts et mais c'était juste juste ton ORM quoi donc
c'est à toi de faire et de coder tes résolveurs pour appeler les données et tout donc lui il venait
inspecter en fait la base de données il regardait tous les champs qui étaient disponibles il te
construisait un schéma basé là dessus donc c'était la version un peu inspection t'avais une
autre possibilité où là tu venais écrire ton schéma et tu lui donnais à prisma et prisma venait
générer toutes les tables dans la base de données basé sur les champs et pareil tous les
tous les crudes quoi donc ce qui était plutôt plutôt pas mal et là sur prisma 2 ils ont un peu
changé ils sont venus passer en tipe plus plus plus et ils sont venus ce qui s'appelle maintenant
le data layer donc ils ouvrent un petit peu plus par contre ouais ça ils ont ça reste quand même un
ORM mais plus intelligent il ya plus de ça mène plus de possibilités par contre toute la manière
de fonctionner ne marche plus donc moi tout ce que j'avais fait sur prisma 1 ça marche plus en
prisma 2 donc il faudra tout refaire après moi j'avais un peu acquis la raison pour enfin
les trucs c'est vu que les services bas qui étaient un peu en retard on s'était mis d'accord
sur le schéma et donc moi j'avais donné le schéma à bouffer à prisma et comme ça en fait je venais
générer tous mes crudes automatiques et comme ça moi je pouvais m'en servir comme comme staging
hyper rapidement pour pour avoir bah mon API pour développer quoi et comme ça j'étais pas limité
et vu que on s'était mis d'accord sur le schéma de toute façon ils allaient récupérer les
informations enfin je devais avoir les informations sur le de la même manière que ça
avait été défini quoi donc eux ce qui leur permettait enfin moi j'étais pas limité par leur
avancement de leur côté et eux en fait ils avaient le modèle du schéma donc ils pouvaient coder au
faire mesure évidemment quand on a quand on a supprimé prisma et on a remis leur API il y a
eu de la casse mais franchement il y a eu quasiment rien quoi donc ça a été hyper fluide donc ça
nous avait permis d'aller très très vite donc ça c'était c'était plutôt pas mal
aujourd'hui des prisma like il y en a ça pop un peu partout il y en a plein il y a un autre
truc qui est vraiment vraiment solide qui s'appelle asura qui est fait en askel et eux ils annoncent
comme un graffQL engine et bah c'est un peu le même délire par contre là on a une interface
graphique mais on peut le faire aussi en mode en mode si elle est où on vient déclarer en SQL
nos tables donc ben telle table telle chante telle relation et tout ça et automatiquement lui aussi
vient nous nous générer toute la pays au faire un mesure donc ça c'est assez rapide et puissant
on vient aussi gérer tous les rôles à l'intérieur c'est à dire quels sont les autorisations
de modifications de lecture dans leregistrement ça donc tout est fait directement dans le
graffQL engine donc ça c'est assez assez pratique c'est très très très puissant et ça tourne sur
une petite instance des recours la plus petite machine je crois que ça permet je ne sais plus
combien de requêtes à la seconde enfin on est on est super sur un donc ça c'est assez assez
assez puissant et en plus ils ont rajouté tout un service toutes des possibilités de faire du
serverless à côté donc c'est à dire sur la business logique en fait toute la gestion de
mes ressources de mon API je vais la faire via asura et quand j'ai une business logique faire
des calculs de faire de je sais pas quoi et bah je viens appeler des des fonctions à
de service et là en fait bah je viens exécuter ma business logique donc c'est assez vraiment
vraiment pas mal ça permet de faire des trucs plutôt plutôt puissants donc assoura donc c'est
bien mais ça on s'est assoura donc c'est soit tu sais ça existe en sas et en cell fosterd ou c'est
forcément alors alors moi j'ai connu c'était en cell fosterd on ly et là maintenant ils ont fait
une grosse grosse levée de fonds ils ont déménagé dans la vallée à sans francisco et puis ils ont
fait un cloud service donc bah c'est soit soit tu le host chez eux et ils ont des fonctions un
petit peu un premium qui qui viennent faciliter tout ça mais tu peux toujours utiliser la version
cell fosterd que tu mets sur un digital océan et ils sont sur le dit ils sont sur le marketplace en
trois clics tata machine qui est poppé ou tu l'installes sur une version d'air au cou et tu branches
ta ta passe de données tu donc ta ta passe de données elle peut être n'importe où elle peut être chez
amazon chez chez recours que sais-je et tu peux mettre plusieurs tu lui indiques les accès alors
est-ce que tu peux mettre plusieurs bases de données je sais pas je pense mais je pourrais pas je
vais pas te répondre je ne sais pas le principe c'est donc ça te fait un serveur qui va se brancher
sur une base de données et qui va te permettre d'avoir des un serveur graphique sur cette base
de données en fait ça fait une sorte de exactement de middleware en fait entre la base de données
sauf que derrière t'as aussi une gestion des droits etc du cache aussi de la passion
d'indemnique oui ok non c'est vrai et réitemiting aussi t'as le système pour les limiter les
requêtes tout ça alors en fait c'est un problème c'est un problème qu'on n'a pas évoqué dans
graphql mais vu qu'on appelle ce qu'on veut on peut rentrer en fait dans les infini loop quoi par
exemple je donne moi les bouquins donne moi les auteurs du bouquin donne moi tous ces bouquins
donne moi tous les auteurs du bouquin et ainsi de la profondeur et en fait on rentre dans une dans
un truc complètement infini donc là en fait on vient définir la limite de profondeur en
quel on veut et aussi quand on commence à implémenter du graphql à la main
voilà et on va être aussi limité avec un problème de toutes les query n plus 5 qui vont
pas toujours être optimisés donc il faut faire attention à ça pour et en fait le fait de passer
par des engines voilà il ya je sais pas combien de mecs qui ont réfléchi à ça potentiellement
ils sont quand même bien plus intelligents que nous donc ils ont fait une libérie qui
marche plutôt pas mal donc autant le autant l'utiliser quoi donc ça va vraiment la soirée
à polo et à polo serveur aussi à polo serveur qui est qui est vraiment pareil qui est super solide
qui est super solide et qui qui a des systèmes comme je disais pour brancher des restes à polo
serveur qui est plus nôtre des nôtes par contre c'est que du nôtre je crois non ouais qui est
qui est qui est javascript après il ya un autre service aussi qui s'appelle une autre
libraire qui s'appelle graphql mesh qui est pareil qui est assez assez assez nouveau qui va agrégé
en fait toutes les données qui marchent plutôt bien et il ya un truc qui s'appelle graphql
guild qui a été repris ça a pas mal bougé et là ça c'est un peu stabilisé mais du coup ils sont
hyper actifs sur la création d'outils d'accord donc donc ça c'est plutôt c'est plutôt bien
côté à la limite pour pour commencer moi ce que je vous conseillerais pour pour commencer
graphql c'est vraiment faire le à ou tout graphql sur l'url il ya une url qui s'appelle
à ou tout graphql et en fait on vient vraiment décomposer étape par étape et ça marche
plutôt bien en fait c'est c'est c'est prêt à ouais c'est assez didactique on va dire et pour
commencer bah ça marche très très bien après il ya un autre hippo bah toujours le osom
macOSome sur github sur github il ya osom graphql ou pour le coup on va trouver beaucoup beaucoup de
tutoriels beaucoup d'infos sur les librairies et tout ça il ya aussi pas mal de podcasts qui sont
dédiés à ça donc non il ya il ya tout un écosystème en fait qui nous permet de se mettre à jour
sur du graphql et moi je vous conseille aussi de commencer par la consommation c'est à dire en
tant que client client vous venez vous venez consommé du graphql en tant que développeur
fronte consommé du graphql c'est tout de suite vachement sympa et puis après bah
s'intéressez vous à comment comment on fait une API graphql et là ça sera ça ça peut être cool
côté client toi tu utilises quoi général apollo apollo apollo client ok apollo client
parce que bah ça fait déjà plusieurs projets que j'utilise du coup je me suis bien pris la tête
à configurer mon client avec à sécuriser les points et tout ça à vérifier les jwt et passer
toutes les infos à passer des variables des variables d'environnement dans le dans le
aider de la requête enfin voilà j'ai fait un truc un peu solide au départ et donc maintenant
en fait ouais j'utilise apollo ouais donc apollo de façon apollo client on va leur sur apollo
ils sont là depuis depuis quasiment le début je pense de graphql en tout cas depuis que ça
a été mis en open source donc ils ont quand même pas mal d'années d'expérience les outils sont
assez robustes utilisés par des grosses sociétes fait le vêtement carrément pis on fait le vêtement
sur le vêtement ils ont pareil même délire tout est open source mais ils utilisent un truc
s'appelle apollo engine justement qui permet d'analyser les requêtes les optimiser tout ça
donc c'est toujours même délire c'est open source et derrière il ya des services premium mais on
peut largement utiliser tout ça et ça marche ouais c'est super solide c'est clair ok bah pour les
outils de façon bah comme d'habitude on va mettre tous les liens dans les notes de l'épisode sur le
site slash podcast et bah vous remercie d'avoir écouté l'épisode jusqu'au bout et puis n'oubliez
pas une petite note sur sur votre lecteur de podcast ça serait c'est toujours sympa un petit like un
petit pouce un petit commentaire c'est toujours cool et merci à bientôt à bientôt alex à bientôt
ciao ciao on va pas trouver l'oubslash sur le plateforme de podcast préféré et sur le site
internet du podcast www.flash-podcast.fr sur le site vous allez retrouver tous les liens d'épisode
des références évoquées durant l'émission