
Fastify, framework rapide Node JS avec Vincent Le Goff
Durée: 50m14s
Date de sortie: 24/02/2021
Un épisode avec notre invité Vincent Le Goff qui contribue activement au projet Fastify. Un framework pour Node JS orienté vitesse et légèreté. Retrouvez toutes les notes et les liens de l'épisode sur cette page : https://double-slash.dev/podcasts/fastify-node-js-open-source/
Bonjour à tous et bienvenue dans ces nouvelles épisodes.
Alors aujourd'hui on va parler de Fastify et pour ce faire on a un invité Vincent,
salut Vincent et comme toujours je suis avec Patrick. Du coup Fastify,
il m'est dit qu'on va laisser peut-être Vincent le présenter pour voir qu'est-ce que c'est et comment
on utilise et tout ça mais il m'est dit avant de parler directement du sujet est-ce que Vincent tu
peux te présenter de savoir ce que tu fais aujourd'hui, ton pas grande et voilà.
Moi je n'appelle Vincent Legoff, je travaille dans une société qui fait du bitoubi pour les
contact centers donc les centres d'appel qui s'appelle Génésis, c'est la communication.
Dans cette société moi je travaille principalement sur tout ce qui est les aspects de monitoring,
telemetrie et je fais aussi pas mal de consulting dans tout ce qui est service web en
Node principalement parce que j'ai un gros background en Node. Donc après niveau background,
ce que j'ai fait moi dans l'informatique j'ai fait des études un peu classiques,
j'ai fait un BTS et après j'ai travaillé dans des boîtes des éditeurs de société de service
à droite à gauche et après je suis arrivé justement à Génésis principalement,
ce qui m'a fait avancer dans le milieu aussi Open Source tout ça, c'est à un moment je
commençais à être frustré de faire tout le temps la même chose et du coup j'ai commencé à
pousser du code un peu dans Git, dans Delib à droite à gauche et au final je suis arrivé sur
des projets de plus en plus gros. Donc c'est pour ça que maintenant je me retrouve justement à être
maintenant de Fastify quoi. Excellent, ok et du coup introduis introduction direct avec Fastify,
comment tu le présentes et comment tu pourrais présenter le projet ? Alors en fait c'est un
Fastify déjà, c'est un service web pour tous ceux qui font du Node, d'off-connet, express,
API, il y a plein d'autres serveurs web que l'on peut trouver. Fastify ça a été monté par
Mateo Colina et Delvedor donc c'est son deux gros mainteneurs du moteur Node.js directement et
Mateo à la base lui il est doktorant et il a vraiment bossé sur tout ce qui était les streams
et le buffering sur le moteur de Node. C'est pour ça que lui à côté il a monté Fastify avec sa
société Nirform, c'est une société de consulting italienne et au fur et à mesure en fait qu'ils
ont eu pas mal de soucis avec des clients etc. Genre forcément avec des stacks assez gigantesques
comme Express etc. Au final ils ont commencé avec Delvedor à bosser sur leurs propres serveurs
qui étaient vraiment orientés Lightweight et avec un système de plugin qui fait en sorte que
tu commences vraiment sur quelque chose qui est bare metal donc en gros tu as vraiment juste un
rappeur au dessus du serveur HTTP de Node et tu n'as pas de sugarcandy dont tu veux pas. Si tu
veux commencer à savoir vide tu peux vraiment avoir le serveur vide et qui fait de la sterilisation
le plus rapidement possible. A la base ça a vraiment été créé pour ça et Fastify aussi en
parallèle il y a eu le développement de Pino, je sais pas si ça vous parle, c'est un logger.
En fait c'est monté un peu par la même équipe, c'est en gros les mainteneurs de Pino
sont les mainteneurs de Fastify en partie et en fait la combinaison de tout fait que c'est le
serveur web en Node le plus rapide actuellement. Ok et le le plus rapide en quoi en termes d'exécution,
nombre de requêtes, de parallélisme ? En termes de requêtes par seconde et de DB etc c'est le
plus rapide pour l'instant il y a des soucis en termes de call start donc par exemple pour des
Azure Functions ou des Lambda c'est pas encore optimisé parce que du coup il met plus de temps
à se lancer que d'autres services et justement on est en train de regarder là dessus pour faire en
sorte que tu puisses générer en gros tu as ton serveur et via une CI ou quoi que ce soit en fait
il y a une cli, la Fastify cli donc qui est un peu comme l'express cli tout ce genre d'outils qui te
permettent de générer du code, des boilerplate etc mais en fait le but de celle là c'est pouvoir
te générer un snapshot que tu vas pouvoir exécuter dans ta Lambda donc ce qui fait que tu vas
avoir un call start qui est extrêmement rapide. D'accord et aujourd'hui ça marche,
je vais retirer ma question et je la garde pour une prochaine mais en fait la philosophie bon
je pense que c'est un peu dans le nom mais le but c'était quand même de faire un truc rapide
et c'est ça le gros élément de différenciation avec les autres frameworks type express ou quoi
que tu as évoqué c'est vraiment la marque de fabrique c'est ça quoi. Ouais en fait la marque
de fabrique c'est aussi surtout l'assize mort du coup c'est vraiment on parle de rien et t'ajoutes
tout au fur et à mesure et un système d'encapsulation dans Fastify qui permet de créer en fait de créer
des sous instances de ta propre instance de serveur donc normalement quand tu faisais ça avec express
tu en pilais tout est middleware au début et tu faisais écouter ton serveur. Délire c'est que tu
peux construire des sous instances de Fastify pour avoir des zones protégées des zones non
protégées des zones avec plus de login etc et du coup ça a été monté là dessus pour avoir une
encapsulation propre donc ce qui permet d'avoir de la performance au niveau de ton cycle de vie de
toutes tes requêtes et aussi d'avoir une meilleure lisibilité quoi en parlant de ça du coup il
y a un système de hook qui est très complet sur tout le cycle de vie de ta requête jusqu'à l'entre
dans le servin et qu'elle ressort ça te permet de pouvoir intercepter les informations ou changer
les informations au moment vraiment où tu veux donc le plus tu vas avoir de hook en fait de
possibilité d'insérer ton code le plus rapidement tu vas pouvoir intercepter par exemple certaines
requêtes et justement gagner en parallélisme par la suite parce que du coup tu vas pas aller
exécuter du code donc sur une requête ou tu n'as pas besoin. Oui je vois il y en a quasiment une dizaine
ça va de Enric Quest, préparcine, prévalide, préhandle, sérilisation, en erreur, en scene
il y en a vraiment beaucoup quoi donc c'est grâce à ça en fait que vous arrivez à
grappiller en fait des millisecondes partout quoi. C'est ça et il y a aussi tout ce que
donc t'en as parlé de la validation et sérilisation en fait il y a un système de directement de
jeason schema qui est implémenté dans les routes, dans la définition des routes donc si tu vas
définir un jeason schema ça va te permettre d'accélérer en plus la sérilisation parce que ça
utilise, j'oublie le nom plus je base dessus c'est face to the sun, Stringy fire ou quelque
chose comme ça je ne me rappelle plus en gros ça va te permettre ça de faire la sérilisation
de ton jeason extrêmement rapidement parce qu'au lieu de prendre ton objet et de s'y
réaliser directement dans ta réponse en faisant un jeason Stringy fire, ce qui va se passer c'est
que si vous voulez vous pouvez regarder le code c'est de face to the sun, c'est dans le projet
je te donnerai le lien en gros on va générer du code qui va interpréter le schema lui-même
ce qui fait qu'on gagne énormément de rapidité d'exécution et alors c'est un peu fastidieux à
générer parce que forcément il faut définir tous ces schémas de réponse mais à terme tu gagnes
énormément en vitesse de sortie donc et c'est le genre de schema aussi que tu définis dans
les spec open API donc ça c'est une des raisons aussi qui permet d'avoir une grande rapidité
parce que tu as toutes les possibilités de ne pas reposer sur des méthodes génériques en gros
du moteur de nado donc tu vas vraiment à te dire qu'elles sont prédéfinies quoi voilà c'est ça
c'est un peu ça en fait elles sont prédéfinies ok et du coup que question un peu annexe est ce
qu'aujourd'hui tu peux utiliser par exemple des schémas graphes cuelles et auto générer
tes schema pour optimiser ça de manière un peu automatique je sais pas si je vais travailler
dessus ou pas du tout alors graph que c'est pas c'est graph que c'est complètement c'est un peu
autre chose parce que c'est un peu quelque chose à part mais alors ils ont écrit quelque chose moi
je suis un peu loin de ça parce que je fais très très peu de graph que en fait l'idée c'était
d'utiliser le ton ton ton schéma de graph que pour prédéfinir tes sorties possibles en fait et
donc générer ton schéma on va dire un peu par rapport à ton ouais de ton schéma de de
réponse il est il pourrait enfin je sais pas dans dans l'idéal dans un monde je sais pas c'est peut-être
automatiquement basé sur un sur un schéma après peut-être que c'est pas du tout le paradigme
de de fastify ou peut-être c'est à via un plugin et peut-être que je suis en regardant alors en
fait oui justement le le la libe qui permet de gérer ça c'est mercurius donc je te donnerai le
lien et c'est bien c'est écrit aussi pour par mathéo colina et du coup faudrait que j'aille regarder
le code mais je pense que il se base aussi sur le sur le même délire par contre ce que j'expliquais
au niveau de ce qui m'a c'est géré au niveau des routes alors que en graph ql c'est directement
dans le pélode exactement c'est pas non c'est pas exactement la même chose mais c'est dans la c'est
un peu un peu la même optique de toute façon quand tu vas définir quand tu vas définir ce que tu
cherche forcément t'as pas t'as pas d'appel générique donc au bout d'un moment tu gagnes
forcément de la vitesse makes sense ça marche ok et et quand tu parles de l'assise mort alors
personnellement moi j'adhère à fond et côté côté expérience développeur c'est ça se traduit
un peu comment justement alors on va dire que il ya moins alors il ya moins de
c'est il ya moins de galère de choses où on sait pas trop ce que ça fait au final parce que le c'est
le face facet 5 moi de mon expérience développeur c'est extrêmement c'est extrêmement simple c'est
extrêmement découpé sur surtout avec le système de plug-in et justement d'instance ça permet
d'avoir vraiment que ce que tu veux et pas d'avoir une boîte noire à un moment qui fait
quelque chose et tu sais pas trop ce que ça fait nous et qui te génère beaucoup de choses que tu n'as
pas besoin et donc ok en fait c'est un stade c'est pas excuse moi si j'essaye de rassumer c'est un peu
vraiment du Lego quoi c'est tu pars sur une un truc une base hyper hyper ligne toute toute fine
et tu rajoutes uniquement les blocs que tu as besoin quoi voilà aussi donc on parle d'express etc
bon par exemple express c'est c'est c'est un des plus utilisés c'est un des plus lourds aussi mais c'est
donc ça c'est avantage et ça c'est inconvénient c'est aussi pour ceux qui ont fait par exemple
de l'open API du swagger le swagger gene ça ça génère du code mais c'est pas c'est pas la folie
non plus en fait là quand on cherche à faire du bairme métal on cherche à aller vite on cherche
pas à faire forcément du code vite même si on on arrivait à faire il y a certains projets qui
font des boilerplate directement un peu comme c'est human aussi qui fait qui fait ça si je me rappelle
bien qui génère en gros qui va générer un serveur et qui va te mettre par exemple toutes tes
connexions hautes tes open API respect etc tous les plugins qui seraient déjà branchés avec un
avec un squelettane de projet qui est sympa après c'est pas forcément le le but du de
fastify de pouvoir coder beaucoup vite en gros c'est pouvoir exercer faire quelque chose qui s'exécute
extrêmement vite c'est ça la différence donc on pourrait dire que c'est un c'est un prémoire
qui est vraiment avec une grosse optique de performance quoi ouais ouais c'est vraiment ça le but et
aussi quand on parle de performance et de expresse donc faut savoir que fastify en gros il va construire
sa sa requête et sa réponse au dessus de la requête et la réponse de nod mais il va pas aller
ajouter de pointeur ou quoi que ce soit dans dans l'objet nod ce qui fait que en gros la
sérealisation du message HTTP qui passe par par nod ben il n'est pas altéré donc c'est pour ça
que ça va aller ça reste vite parce qu'il y a peu de choses à transiter en fait dans dans le
nod.row donc c'est ça qui est intéressant au final c'est ce que fait express non rajouter des
choses dans l'objet alors ça fait longtemps que je suis pas dans le code source mais pendant un moment
il y avait il y avait eu ce problème là aussi ouais des gros objets express en fait en réponse
voilà c'est ça et en gros le si tu veux le truc c'est que la requête nod et la réponse nod elles
sont immutables en fait elles sont un changé si tu en on va juste la sérealiser à la fin mais par
compte tu as la possibilité aussi de de de muter cette requête fin cette requête ou cette
réponse nod par contre faut savoir que du coup tu mets en péril le cycle de vie de fastify mais dans
certains cas t'es obligé de le faire donc je l'ai fait dans l'implémentation du HTTP 103 je sais
voilà on peut en parler aussi alors le HTTP 103 c'est une spec qui est sortie il y a déjà pas
mal de temps c'est une rfc qui était sortie en expérimental et ça commence à revenir parce
que je pense que beaucoup de monde l'ont on tenté ici c'est le HTTP HTTP 2 avec le
serveur push pour pouvoir récupérer les informations et faire que les récupérer les informations qui
vont être chargées dans la page et faire en sorte que la page se charge plus vite sauf que
on sait tous que l'HTTP 2 et le savoir-pouche ça n'a pas trop marché et que c'est un peu
ça a un peu coulé au final et je crois que c'est déprécié d'ailleurs depuis ben depuis fin 2020
le aspect de la HTTP 103 en fait ce qui se passe c'est quand on reçoit un message HTTP on peut
recevoir des des aideurs en 100 donc des aideurs d'information avant de récupérer son le code donc
qui va être soit 200 soit 300 pour la redirection 400 pour les erreurs et 500 aussi le truc ce qui va
le HTTP 103 dans les specs ça va te permettre au navigateur de savoir qu'est ce qui va aller
devoir charger sans avoir encore reçu le payload donc ce qui se passe et imagine tu fais
t'as une page d'un site web un site un site de news donc on est d'accord t'as forcément du cache
cdn cloud flare etc mais en attendant on a toujours énormément d'assets à gérer à télécharger
début donc des scripts des polices des images non les images ça prend pas des scripts des
polices des styles sheet tout ça avant on a fait donc avec l'http 2 on ouvrait qu'une seule
connexion et on a été chargé plein de choses donc ça c'était bien mais le problème c'est que
faut que tu ailles quand même évaluer le payload pour pouvoir pour pouvoir télécharger tout ça
le truc c'est avec l'http 103 c'est que ton navigateur va aller questionner et il va commencer à
recevoir déjà le message avant de que le payload y soit créé donc ce qui se passe c'est qu'il va
aller rechercher toutes ces informations là mais en gros le truc c'est de pouvoir et pour en
revenir à fastify pour pouvoir faire cette implémentation là ce qui se passe c'est que moi je
suis allé justement injecter directement dans notre pour pour ajouter ça au message http sans
sans avoir à passer par vraiment les requêtes fastify en fait parce que si je passe par la
requête fastify il est déjà trop tard parce que je vais lui donner le payload donc tout sera
s'est réalisé l'intérêt c'est dès que je sais où je vais aller et qu'est ce que je vais servir
bah je les écris directement dans le stream donc en faisant ça imagine ta requête prend 5 secondes
à générer bon on est dans un 500 millisecondes 500 millisecondes et en gros je sais que je
vais devoir desservir l'index html avec tout ça mais je sais ça dans les 10 premières
millisecondes donc dans les 10 premières millisecondes j'aurais déjà écrit au navigateur
m'a fallu que tu commences à aller charger ça mais c'est quoi en fait que la navigateur
il en voit quoi en fait le navigateur reçoit en fait quand il reçoit quoi en fait comment il
sait assez quoi l'info en fait c'est quel l'info c'est un message c'est un aider http au final
donc en gros quand tu quand tu reçois des messages http tu peux recevoir plusieurs messages http
dans le même stream et il y en a qui sont définitifs mais il y en a qui sont juste informatifs
donc on don les messages en ce moment et avec ça en fait tu peux déjà amorcer quelque chose
dans ton navigateur ce qui te permet de aller grappiller encore quelques milles secondes sur
chaque requête quoi c'est ça mais c'est dans les specs alors là c'est la dernière alors la
libe qui est utilisée pour http je m'en rappelle même j'ai oublié le nom elle a été mis à jour pour
celle que firefox utilise elle a été mis à jour pour pour prendre en compte le http sans 3 mais la
dernière version de firefox l'implément toujours pas c'est en il y a des tickets qui sont ouvert
pour la pour l'utiliser donc mais j'ai suivi un peu de loin pour l'instant c'est pas encore arrivé
mais il y a pas mal de gens qui poussent et il y a justement alors j'ai oublié son nom celui qui
bosse à blomurg et qui est qui est à la tc 39 celui qui a poussé pour pour le rust aussi dans la
tc 39 j'ai oublié son prénom on va pas pouvoir ceder je suis désolé en gros il y a des gens de la
tc 39 qui poussent pour l'http sans 3 donc j'ai le bon espoir que ça que ça perce là aujourd'hui
il ya des brosers qui l'implémentent déjà pour l'instant non ok donc tu es super toi tu es en
train de l'implémenter dans fastify c'est déjà fait mais c'est pas compliqué au final super en avance
en fait mais en gros le truc c'est qu'il y a pas mal de gens qui poussent il y a des libres qu'utilise
les navigateurs qui l'utilisent qui l'ont à plémenter maintenant le lifecycle des navigateurs c'est
extrêmement long ok rien que poulet le le repos de firefox j'ai la fibre chez moi ça a mis 4h30
voilà ouais ok non mais c'est ok et justement là tu parles de de libres tout ça est ce que tu
aujourd'hui comment ça articule un peu tout l'écosystème fastify c'est ça se développe sur des
plugins ce que j'ai ce qu'on a compris ouais c'est ça en gros nous y a un non gal serre
fastify il ya pino qui intégré avec après en qu'est ce qui va être intégré dedans en on va dire
en gros dans il ya face json strignify celui que je vous ai donné il ya hgd c'est pour les les specs
les json schema il ya du coup il ya light my request ça permet de ça permet de ça permet de
ça permet de checker tout ce qui est les entêtes http etc et après on va avoir le find my way qui
est le routeur après deux trois petits trucs à droite à gauche mais rien de bien c'est on fait
au minimum quoi après le corps de fastify c'est ça voilà après qu'on veut rajouter des choses
faut justement les installer les déclarer les registreurs quoi et il ya un écosystème qui est
disponible bon en fait l'écosystème de de fastify donc c'est les fastify dash c'est des libres qui
sont maintenues par des mainteneurs de fastify après il ya pas mal d'autres trucs aussi à côté
mais les trois quarts des on va dire des des groupes le guine qui sont qui sont utilisés pour fastify
sont déjà maintenues par des mainteneurs de du groupe de fastify on est en gros on est une quinzaine
à être actif vraiment sur un peu un peu tous les tous les fronts et il ya une dizaine d'électrons
libres qui sont sur sur on va dire l'environnement par exemple il ya toute une équipe de gens qui
font beaucoup qui bossent beaucoup sur le websocket sur il ya nukest next et je sais plus que c'est de
trois autres choses où c'est vraiment plus des gens qui sont qui bossent que là dessus qui sont
vraiment plus responsables à dessus quoi ok et je vois il ya des corps plug-in et des community
plug-in quoi c'est ça voilà donc c'est les deux et après en fait on va retrouver des
des implémentations qu'on va trouver un peu un peu partout quoi enfin je pense on va dire haute les
trucs système de cache caching de cookie de corde de csrf voilà plein de choses comme ça et en
fait on va pouvoir les mettre au fur et à mesure de nos besoins quoi si on a besoin on les injecte
si on les ingratioe si on n'a pas besoin on les met pas et c'est ce qui nous permet de garder un
truc un peu un peu ligne quoi et de pas faire un nougre bah c'est ça c'est ça aussi par exemple
si tu veux tu as imagine tu as comment on a un je sais pas tu veux avoir de la gestion de
corps sur ton serveur tu avants de la gestion de cookie et et de compression mais le truc c'est
que tu vas avoir un côté un côté API un côté frontaine d'etc et avec bah justement si tu le
faisais tout en déclaration un global le problème c'était que tu es obligé de faire des exceptions
pour des routes ou des trucs comme ça mais là tu arrives déjà à un moment où de toute façon
quand ta requête à l'arrive elle va passer par son partant plug-in donc là tu as déjà perdu du
temps l'intérêt c'est comme je l'ai expliqué avec l'encapsulation et bah tu vas pouvoir justement
chanter toute cette étape là parce que tu vas en enregistrer ton plug-in que dans l'endroit où
t'en as besoin donc en gros il est pas ta fonction sera jamais appelé quoi galette ouais je comprends
mais en fait c'est quoi c'est par rapport au hook alors ouais en fait c'est à chaque fois que tu
vas déclarer une instance en fait je déclares ton instance et tu peux avoir des sortes de sous
instances et du coup tu peux tu peux enregistrer donc ton plug-in tu peux fin on va dire l'attacher ton
plug-in à ta sous instance donc et autrement tu peux redéclarer des hooks dans ta sous instance
ok donc quoi il va pas aller il va pas aller parcer tous les plug-in pour dire est-ce que lui il
a besoin de ça est ce que lui non il va voilà c'est ça ou que ça appelle ou ça appellent pas
c'est ça ok après il y a pas mal de choses qui sont qui ont été écrites ben justement à la base
pour des besoins professionnels en fait à la base ça a été écrit pour des besoins professionnels
et du coup tout ce qui va concerner ben par exemple haut redis et la stick search tous ces trucs là
en gros c'est vraiment dans un aspect d'être le plus rapidement d'être le plus rapide possible
donc et d'avoir le moins ouais sur la fonctionnalité pure quoi qui est la gestion de de l'authentification
de l'aistique search et machin de ok je comprends après le même système en fait avec pino
pareil donc en fait pino ben il soit d'habitude normalement il est écrit dans la console et après
tu peux donc t'as plusieurs modes de console en plus pour pino il ya il ya un mode qui utilise
sonic boom ça te permet au lieu d'aller écrire dans la console une fois à chaque entrée
ben tu vas tu vas écrire plus tu vas tu vas bolquer en fait tout ce que tout ce que tu fais pour
pouvoir les écrire parce que à chaque fois que tu écris dans la console en gros tu ouvres le file
descripteur de la console tu écris dedans tu le fermes mais le problème c'est que ton opération
d'ouvrir elle le fermait c'est extrêmement coûteux donc le délire c'est pareil en gros tu vas
aller prendre tous les messages tous les uns certains temps on s'est extrêmement rapide et tu vas
aller écrire plein de fois par paquet et comme ça tu vas gagner énormément de temps à faire ça
et pareil ce que je disais au appino il est branché sur sur un même système de plugins donc soit tu
peux écrire directement dans un console soit tu vais écrire directement dans un élastique search
je crois qu'il y a même des gens qui ont fait un connecteur data dog c'est après tu le tu le
pousse sur sur ce que tu veux quoi c'est ça ok et ok je comprends on comprend mieux un peu un peu
tout ça et aujourd'hui alors peut-être que tu tu l'as dit tu tu sais à peu près combien il y a
un écossystème au niveau du corps de fastify vous êtes combien au niveau de la étude corps de
fastify ouais on est il y a vraiment 10 15 personnes d'accord il ya un discord on sait
bien d'être créé mais ouais on est voilà dans le channel tu vois on est on est 12 donc et tout le
monde est tout le monde n'est pas là mais en gros il y a entre 10 et 15 personnes qui sont très
actives on va dire et c'est pour ça qu'il y a en annexe ouais en annexe ça va dans les 25 on va
dire 25 des y a des contributeurs qui viennent une fois tous les mois des trucs comme ça après
c'est ça dépend vraiment des besoins moi c'est pareil je suis arrivé dans fastify parce que
ce qu'à la base du coup j'utilisais fastify et je me suis retrouvé à devoir pousser du code
parce que on avait il y avait des choses qui n'était pas qui n'était pas implémentée de base donc
pouvoir réécrire des choses certaines choses avoir plus de flexibilité dans certains cas
etc quoi parce que tu vois par exemple je crois que je suis pendant longtemps dans l'équipe de
maintenant j'étais un des seuls à faire du kubernetes avec des avec des architectures en
privé de cloud et en public cloud mais sur les mêmes nœuds etc avec des contraintes de rivers
proxy f5 et ce genre de choses donc au final tu te retrouves dans des contraintes pro que si tu
fais genre juste un service public tu les as pas forcément donc il y avait plein de petites choses
qu'on a qu'on a pas affiné on va dire quoi d'accord et justement sur aujourd'hui est ce qu'on
peut dire que fastify il est il est community driving où c'est ce petit corps qui décide comment
ça se passe au niveau de moi je veux créer un plugin j'ai un besoin pro ou pas ou ça m'anime
de faire un truc comment ça se passe c'est assez ouvert ou par contre c'est super ouvert comme
c'est on va dire c'est c'est une commune fastify c'est une communauté super accueillante ce que j'ai
bossé sur beaucoup beaucoup de gros projets genre des nôts je sais pas si tu parles oui voilà j'ai
en gros j'ai écrit une grande partie de la std lib avant la release une et c'est pas du tout la même
ambiance donc c'est très différent mais par contre en gros c'est les règles de base de l'open source
bah j'ai un besoin je présente mon contexte est ce qu'il ya quelque chose qui peut le fixer si si
non est ce que vous avez une idée de l'implémentation comment on pourra le faire oui je peux potentiellement
bosser dessus il n'y a pas de soucis et on a eu il y a eu certaines personnes qui étaient pas on va dire
optimale au niveau du code parce que forcément tu connais pas tout ce qui se passe dans le serveur
tu connais pas forcément tous les tous les cas tous les cas spécifiques dès que ça va toucher par
exemple à du web socket ou des choses comme ça il ya toujours des cas qui sont un peu un peu
qui sont un peu plus complexes qu'on voit voilà et qui sont hors de ton giron et bah il y aura toujours
quelqu'un qui sera là bon bah l'implémentation elle est cool l'idée allait bien on a besoin de la
feature bah on va faire des quoi ouais cool sympa le but en fait c'est de c'est de faire de faire
que la que la feature soit faite quoi après on sait pas dans le délire de aller pousser du code dans
un répo connu il faut juste que l'idée est cool bah vas-y on va on va on va t'aider à pousser du code
et puis tiens on donne les exemples etc mais il ya plein de plein de patterns en en fastify où j'ai
vraiment appris aussi au niveau du corps de note donc c'est intéressant c'est du code qui est
intéressant à lire surtout que ça a été pas mal refacteur il ya il ya deux trois fichiers qui sont
un peu qui sont un peu tordus mais autrement la majeure la majeure partie elle est vraiment bien
codée elle c'est assez propre et en plus de ça aussi donc moi je fais beaucoup de typescript et
il ya deux deux autres manneurs qui sont à fond de typescript et il y en a justement les deux
auxquels je pense sont extrêmement solides dans cette implementation et c'est pareil il ya un et
qui bosse à microsoft donc c'est pareil on a pas mal de relations chez avec microsoft et avec les
typescript tout ça donc dès qu'il ya des trucs un peu trop générique ben justement on a quand même
un peu de retour des manneurs de microsoft aussi si besoin quoi il peut intéressant quoi il peut
et vas-y patrick est ce qu'il ya des squads de courant s'il ya des gros projets qui utilisent
fastify déjà il ya les mires génésis non c'est si il ya il ya plein de gros projets il ya déjà
microsoft utilise fastify bien il ya une reforme bien génésis il ya il ya toute une liste de gros
comptes dans dans dans dans le dans le site web après pour l'instant c'est pas le plus connu mais
il ya il ya pas le plus performant non et depuis quand le projet existe fastify c'est en version 3
ouais la version 4 l'arrive sous peu on commence à bosser dessus mais non fastify ça 3 ça 4 4 ans
peut-être bon on peut regarder la première release on va les chercher si on veut mais ouais ça 3 4
ans je pense quelque chose comme ça et sur la 4 il y aura des des des gros breaking change ou pas
du tout c'est une c'est une continuité il ya des les futurs à très peu de breaking change entre
les versions de de fastify parce que parce que du coup faut faut faut arriver à migrer simplement de
de version moi par exemple quand on a migré de fastify 2 à fastify 3 on a juste eu 2 3 petits
problèmes sur des histoires de bête justement de js et type script parce que je pense que vous
savez bien et que les auditeurs le savent pour les exports c'est toujours un peu la galère
avec le module défaut le module d'export le module nommé etc et voilà des petits trucs comme ça
en fait qui n'était pas forcément dans la ci pour pour tous les tests quoi mais c'est ça reste
minère une volonté de ne pas casser entre les versions ouais c'est ça en plus pareil pour
tous les plugins il ya des systèmes de gestion de version avec la libre cem vert qui permet de
gérer tout ça aussi de savoir si les versions sont compatible ou pas ouais c'est c'est vraiment le
délire la version 4 en gros il ya deux trois petits problèmes en interne dans le code qui demande
un gros refactor mais ça c'est pour en tant que pour des pour la développeur expérience ça va
presque rien changer normalement ça devrait ça devrait rien changer mais en gros ça va changer des
paradigmes à l'intérieur du serveur quoi c'est tout ouais ça sera sous le capot quoi donc pour les
états classiques principalement ouais et dans tous les cas au niveau du du versioning de
de fastify dès qu'il ya des cales et breaking change ou des ajoutes de features si on ajoute des
features on les désactive forcément si on les active ça passe en cem vert majeur on se pose
pas la question donc c'est super suivi et vu que c'est pareil la libre est suivi si il y a un bug par
exemple dû à une à une release c'est déjà arrivé il est fixé il est fixé dans la journée quoi ou il
est rapide dans la journée ouais ouais ben matéo matéo ça je sais il regarde tous les jours moi je
regarde tous les jours parce que avec avec mon boulot je travaille sur github donc forcément
j'ai la main j'ai les notifications qui sont emmêlées aussi mais ouais principalement tous les jours
il ya du monde qui regarde quoi cool excellent et du coup voilà moi je suis le développeur
enfin je me mets dans l'impôt d'un développeur bas qui fait de l'express et qui ok qui découvre
fastify le meilleur moyen c'est quoi c'est de commencer par lire la doc ouais ben rien
dans sur le répot il ya déjà des des il ya déjà des exemples justement il y a une super doc sur
l'encapsulation sur le login sur tous les hooks après c'est c'est super simple d'approche donc c'est
vraiment juste en en lisant le répot en lisant en ouvrant le le répot il ya de quoi faire il
n'y a pas besoin de trop de trop aller chercher dans la doc profonde c'est c'est vraiment c'est
super rapide quoi c'est assez fluide quoi ok et je sais enfin j'ai vu matéo faire des vidéos aussi
qui où il explique et alors fait pas mal ouais avec son accent italien magique c'est trop classe
c'est trop classe mais du coup c'est il explique plutôt plutôt bien tout donc ok top donc toute
façon on mettra tous les liens dans dans la description de l'épisode du coup on pourra on
pourra les voir ok donc du coup version 4 un peu un truc hyper modulaire un truc avec plein de
plein de plugins qu'on qu'on plug au fur et à mesure des besoins une développeur expérience
plutôt facile et et fluide et un truc et quelque chose de vraiment branché et sur la perf à la limite
juste pour quel type de projet en fait tu conseillerais de passer sur sur fastify ou plutôt
les questions à l'inverse pour quel type de projet tu dirais non la fausse surtout pas mettre
fastify franchement là j'ai pas eu de vraiment j'ai pas eu de mauvais expérience après il ya ça je
sais je sais je pourrais pas dire pour ceux qui font tout ce qui est template ing avec des choses
genre non jou que tout ces trucs là ça j'en fais plus depuis depuis très longtemps moi je fais
vraiment que que de la ipi maintenant donc je pourrais pas parler pour ça après concernant de
l'aipi moi j'ai vraiment zéro souci je suis super content de tout de tout ce qui est fait par
ça avant là et bon j'ai un peu fait l'évangéliste à genesis par rapport à ça aussi forcément
les autres services qui des nouveaux services qui sortent en js sortent fond du fond du fastify
maintenant une grande partie après genesis c'est une très très très grande société donc j'ai pas
forcément une visibilité à travers tout le groupe mais principalement les nouveaux services
c'est tous ceux qui sont pas sur de lia ou quoi que ce soit ça va être du nôtre en fastify et
autrement ceux qui ont vraiment besoin de la perte sur sur de la yo ça va être du reste quoi
ok ok et du coup bah tu ne pourrais que que pousser les gens à utiliser fastify au moins à tester
sur pour faire une tout petit truc mais juste pour jouer avec quoi ouais voilà après le c'est super
super simple le le seul truc qu'il faut prendre un peu en compte c'est qu'il faut faire attention
c'est que justement en gros quand tu définis des routes ou des hooks dans fastify vous savoir
que les routes ou les hooks sont gère les appels en synchrone et les appels à synchrone des fonctions
ce qui fait que tu peux faire des fonctions à synchrone sur ta route mais tu peux faire des
fonctions synchrone avec un callback aussi sauf que des fois c'est déjà arrivé que les gens
fassent les deux en même temps donc parce que le comment tu déclars ta fonction pour qu'elle soit
promisable on va dire c'est pas c'est pas natif dans dans le javascript de savoir si une fonction
elle retourne une promesse ou pas donc tu peux te retrouver avec des cas des cas un peu tordu c'est
pas trop compris le paradigme mais principalement ça arrive moi ça m'est déjà arrivé mais c'est
genre une c'est des fautes d'inattention ce que tu recopies du code tu fais tac-tac ça à vite et
puis tu veux le passer en a 5 mais en fait c'était un callback et voilà c'est truc bête quoi
d'accord du coup tu bloques ton serveur quoi
bah non tu bloques pas le serveur en fait c'est la requête bah elle n'est jamais rendu quoi
elle n'est jamais rendu d'accord en fait elle est rendue
bah non du coup elle n'est jamais rendue non non elle n'est jamais rendue elle reste dans le serveur
et puis et puis ton client il attend d'accord donc en fait au final qu'est ce qui peut se
passer c'est que ta requête n'aboutit pas mais la requête de fin le pointeur nod en fait il va
se couper il va dire bah non il n'y a plus de clients en face mais après non bah tu auras toujours
l'objet en mémoire et bon ça tu te rends compte aussi parce que donc il y a aussi un système de
tests c'est que tu peux faire donc il y a tout un article et tout là dessus dans la doc c'est que tu
peux faire de l'injection en gros tu vas injecter des requêtes dans une fausse instance de fastify
donc en gros tu peux simuler tout ton tout ton workflow enfin tout ton flux de la requête dans
tes tests unitaires donc tu vas faire tu vas déclarer ton serveur donc tu fais ta fonction pour
créer ton serveur qui va te retourner une instance et après toi au lieu de la tu vas la
faire tu vas la faire écouter tu fais fastify inject directement et en fait tu vas lui dire bah
j'injecte une requête dans mon serveur fastify et au lieu de devoir faire un curl manuel ou sortir
je sais pas quel autre axio sous autre bah là tu vas injecter directement injecter requêtes ok et
du coup bah pour rebondir sur tous ces c'est un petit peu ces patterns là on les retrouve dans
la doc tout justement ouais ok donc c'est vraiment la doc en fait qui va qui va nous aider à mieux
comprendre ce paradigme et à mieux l'utiliser et pareil sur tout ce qui est best practice vous avez
une partie aussi écrit dedans ou pas plus que ça à chaque fois tu vas avoir des exemples
ok tout aussi par contre ça c'est alors il ya les best practices pour écrire les tests les
best practices pour pour écrire le code etc on n'est pas tous d'accord donc pour l'instant il n'y a
pas trop de guides voilà ça ça dépend ça dépend de plein de gens ça dépend comment ils écrivent
etc ça dépend du mec qui a écrit la doc non ouais en fait ça dépend aussi des gens des contextes
pro par exemple il ya pas mal de gens qui sont avec des développeurs qui connaissent beaucoup sur
plein de choses dans le moteur de note dans le moteur js ou quoi que ce soit et à des personnes
qui travaillent avec d'autres développeurs qui ont plus des connaissances business que des connaissances
techniques moi j'étais dans le cas dans les deux cas et dans le deuxième cas par exemple je me
se trouvais de voir créer un serveur qui était on va dire un swagger first entre guillemets et ce
qui fait qu'ils écrivent tout le spec dans le swagger et après ils ont juste à déclarer une
fonction dans certains noms et ils écrivent tous leurs fonctions dans ce nom et ça faisait tout
seul pour eux dans l'espace tout ça mais ce qui fait que du coup tu as beaucoup d'overhead en parallèle
de ça pour pouvoir intégrer tout tout ce tonneboarding de ce genre de développeurs après c'était
pour des pour des cas très spécifiques mais ça ça a évité d'avoir à expliquer beaucoup de choses
de développeurs au développeur qui en plus à la base avait pas forcément de connaissance dans
dans tout le gs fastify qui n'est pas vœu d'en avoir c'était juste pour remplir une remplir
des des tas de giras pour un besoin spécifique du coup c'est soit tu comprends la magie soit
tu utilises la magie quoi ouais mais là je parle vraiment de quelque chose qui est qui sont des
cas très spécifiques quoi c'est je parlais c'est ce sont par exemple des développeurs qui vont
gérer tout ce qui tout ce qui va gérer la télécommunication sur des services ou des
choses comme ça donc des trucs très hors de ma portée dont je n'ai pas trop envie de m'y
frôler et eux ils sont contents de pas de pas faire tout ce que je fais donc ça c'est je comprends
ça se parlait yes yes je comprends bon ben nickel et du coup bah tu veux peut-être
rajouter quelque chose de particulier ou quelque chose qui te tient à coeur sur sur fastify
même que mec c'est une communauté de développeurs qui est super ouverte qui a la chance d'un côté
d'être populaire sans trop l'être donc ce qui fait qu'on n'est pas les réponses sont pas trop
floudés ou quoi que ce soit et grâce à ça aussi les mainteneurs ils sont toujours ils sont toujours
sur le qui-vive on va dire pour pour contribuer au projet et améliorer le projet et même aider
les gens quand il y a des développements de futur ou quoi que ce soit donc c'est vraiment c'est pour moi
c'est la bonne taille j'ai travaillé sur des tout petits projets comme j'ai travaillé sur d'énormes
projets là moi chez fastify je suis très très bien donc puis tout le monde est cool et justement
il ya des gens qui ont un très très gros niveau et du coup tu peux tu peux vraiment progresser si
tu veux justement contribuer au projet dans l'optique de progresser toi même dans dans ton
compétence excellente Vincent où est-ce qu'on peut te retrouver sur le net un twitter
un site public des choses github ouais ça marche et ben et ben on mettra le lien de ton
github pour pour que les gens puissent savoir un grand merci Vincent rien merci patrick merci à
tous les auditeurs d'avoir écouté l'épisode jusqu'au bout et puis bah on vous dit à bientôt
ciao ciao on va pas trouver d'oubés lâcher au plateforme de podcast préféré et sur le site
internet du podcast 3w pour un flash tirer podcast, sur le site vous allez retrouver tous les
dernières épisodes, des références qu'est foquée durant l'émission
Episode suivant:
Les infos glanées
DoubleSlashPodcast
Double Slash, un podcast sur le développement web. Retrouvez-nous régulièrement pour parler de sujets variés tels que la JAMStack, l’accessibilité, l’écoconception, React.js, Vue.js, Next.js, Nuxt.js, le CSS et des retours d’expériences sur des implémentations.
Tags
Card title
[{'term': 'Technology', 'label': None, 'scheme': None}, {'term': 'Technology', 'label': None, 'scheme': 'http://www.itunes.com/'}]
Go somewhere
Strapi, le CMS headless 100% JavaScript avec Jim Laurie