Bienvenue sur Double Slash, le podcast dédié aux outils et aux techniques pour le développement
web.
Bonjour à tous, bienvenue sur ce nouvel épisode de Double Slash, donc un épisode de rentrée,
un épisode spécial news et comme d'habitude nous sommes avec Alex, salut Alex.
Salut Patrick, salut à tous.
Donc épisode spécial news, donc on va en profiter pour annoncer Alex que d'au-rén-avant,
on va essayer de faire un épisode spécial news tous les mois en fait.
Alors, non, non, il faut activer, les éléments de langage ne sont pas bons, c'est pas, on
va essayer, on va faire un épisode de news par mois où justement l'idée c'est de
collationner toutes les infos qu'on a, tout ce qui se passe sur le web et il se passe
beaucoup, beaucoup, beaucoup de choses et je pense que ça peut être intéressant de
mettre en place ce système de veille aussi bien pour nous et pour vous.
Donc, on aura donc maintenant un épisode de news par mois.
Ouais, on ne sait pas, début ou fin, ça sera surprise, l'une de mieux du mois.
Voilà, donc dans cet épisode on va parler de pas mal de choses, je vais faire un sommaire
vite fait, on va parler de Chrome qui nous distribue la monnaie, on va parler de Burn,
ce nouveau serveur JavaScript, on va parler de Deno, on va parler de DB un petit peu aussi,
on va parler de la fin de gratuité dans certains hébergeurs, dans certains produits.
C'est fini.
On va parler de JS, on va parler peut-être de tooling, de nouveaux produits qui nous
facilitent la vie.
Donc, ouais, un sommaire plutôt sympa et petit récap pour ceux qui n'ont pas écouté
les épisodes précédents, on a fait une petite série durant l'été sur les animations,
que ce soit en JS, en JavaScript, avec des fichiers animation en l'auti et même de la 3D
dans le navigateur.
Donc, vous pouvez retrouver ça sur les épisodes précédents et on a pris super plaisir à
faire cette série, on a appris beaucoup de choses, donc c'était super sympa.
Ok, on va commencer.
Allez, on attaque.
On commence par quoi ?
On commence par Chrome, enfin Google, enfin c'est plutôt Chrome, c'est le Chrome qui
distribue de la monnaie.
Ok, c'est des tokens, c'est quoi ?
Non, ils avaient déjà donné, en fait, ils oeuvrent entre guillemets pour améliorer
les performances des sites internet, enfin des frameworks, tout ce qui en utilise pour
développer des sites internet.
En 2020, ils donnaient déjà 200 000 euros qu'ils distribuaient dans certains outils
open source, tout ça.
Et là, ils viennent d'annoncer qu'ils rajoutent une dotation de 500 000 euros, donc divers
frameworks, il y a une petite liste sur la page.
Donc, en fait, ils nourrissent et ils alimentent l'écosystème pour subventionner en fait
pour qu'ils améliorent tous les projets d'open source.
On voit qu'il y a Next, Vue, Vite, Astros, Veldt, Preact, ESLint, Rollup et Sharp.
Sharp, et Sharp qui est un outil pour dimensionner les images, enfin travailler sur les images
au niveau de nodes.
Mais après, c'est les principaux frameworks et le but, en fait, c'est vraiment d'améliorer
tout ce qui est image, les formats d'image, tout ça, améliorer la performance des frameworks
pour que, nativement, ils soient déjà performants.
C'est vraiment le but de cette dotation.
Ils travaillent beaucoup en fait, ils ont des équipes en interne chez Google qui travaillent
pour améliorer Next, NUXT aussi, d'ailleurs je sais qui travaillent avec eux aussi.
Et puis, ils ont aussi, sur Workpress aussi, ils ont amélioré l'outil pour, voilà, toujours
la performance.
La performance est le chargement toujours plus rapide.
Donc c'est cool, ils donnent des sous.
Pour aller chercher de l'efficience, quoi.
Même si 500 000 dollars pour eux, c'est un petit peu...
Après, ils ne sont pas obligés de le faire.
C'est peut-être pour défiscaliser aussi, quoi.
On ne sait pas.
Ah, c'est dur, Patrick, c'est dur.
Parce que les mecs, on ne peut pas dire qu'ils ne font rien.
En fait, ils ne feraient rien, on leur dirait, ouais, tu ne ferais rien, tout.
Et là, tu fais, ouais, mais c'est pour défiscaliser, tout.
Après, c'est insolu, tu vois.
Non, après, je trouve plutôt la démarche est intéressante.
Après, ils viennent subventionner et on va dire aider des frameworks open source ou
des techno open source avec une communauté et tout.
Bon, c'est très bien.
Ça injecte un peu de liquidité.
Ils vont pouvoir se concentrer sur des features.
Moi, je trouve que tout le monde y gagne.
Après, de toute façon, table tournée dans tous les sens.
Plus il y a d'utilisateurs, plus à la fin, c'est Google qui gagne.
Parce qu'il est partout.
Donc, au final, évidemment, c'est un investissement, qu'il le défiscalise,
ou je ne sais pas quoi.
Oui, so what.
C'est pas grave.
Enfin, moi, ça ne me gêne pas.
Si vous pouvez mettre un petit peu d'argent aussi dans Google Analytics pour l'améliorer
au niveau performance, il serait pas mal aussi.
Je dis ça pour réduire, pour réduire en fait le coin.
Le nombre de scripts.
Ouais, ouais.
Mais c'est pas grave, tu utilises Party Town.
Exactement, Party Town.
C'est ça.
Tu le mets sur un thread séparé.
Et c'est pas mal.
En parlant de performance, cet été-là, on a vu l'explosion des run-time en JavaScript.
C'est vrai.
Ou qui était la suprématie de Node et tombé, on va dire.
Pendant longtemps, on n'a utilisé que Node sur le côté serveur.
Et maintenant, on a Deno qui a apparu un peu plus d'un an.
Oui, bien sûr.
Et il y a le dernier qui sort, Bun.
Alors ils annoncent des perfs hallucinantes.
Ouais, hallucinantes.
Ouais, ouais.
Et en fait, comment ils arrivent à avoir autant de perfs ?
Je ne sais pas en fait.
Bun, ça a fait vraiment le buzz durant l'été.
C'est sorti d'un coup et Bun, c'est hyper rapide.
Et je crois qu'il est écrit en...
C'est du zig.
Alors, j'avoue que je ne connais pas ce langage du zig.
Non, moi non plus.
Je ne le connaissais pas.
Donc ça a l'air d'être ça le secret.
L'écriture, mais surtout, il est extrêmement rapide.
Donc là, il annonce...
Ouais, donc c'est 48000 requêtes par seconde contre 16000 sur Node 18.
Node 18, c'est la dernière version.
Donc c'est quand même ultra rapide sur un server-side rendering de React.
Donc on rend une application React en server-side.
Donc c'est hyper performant.
Et aussi pareil, il a un exemple.
C'est 50 fois moins de mémoire pour générer une page sur Next.js.
Donc 50 fois moins, c'est juste...
Tout est lit.
Ouais, c'est hallucinant.
Après, pour ceux qui ont regardé un peu les battles qu'il y avait sur Twitter.
Donc chacun défendait son bout de gras entre Node, Deno et Bun.
Et là, en fait, c'est ce que je disais tout à l'heure.
La suprématie de Node, elle est tombée.
Maintenant, ça crée une émulation où tout le monde se tire la bourre.
Après, moi, ce que je vois, c'est qu'au final, c'est quand même les développeurs qui vont être gagnants.
Dans la mesure où on va avoir des applications plus rapides, plus efficientes,
peut-être qu'ils vont marcher, fonctionner de manière plus rapide.
Mais pour nous, ça ne va pas nous changer grand chose dans la manière dont on va coder et développer.
Par contre, sans doute changer des choses sur les hébergeurs, sur toute la partie infrastructure.
Où là, pour le coup, ils doivent supporter ce runtime.
Mais en tant que temps de temps de terminaire, eux, à la mettre ça en place,
si c'est moins gourmand en ressources plus efficaces, ils y gagnent aussi.
Donc la vraie question, c'est est-ce que les hébergeurs vont switcher sur cette technologie-là.
Parce que, clairement, là, ça se tire la bourre, comme à chaque fois qu'il y a un framework
ou quelque chose de nouveau qui sort en GES, il y a toute une effervescence.
Bon, là, c'est le runtime.
Clairement, ça ne va pas changer grand chose pour nous développeurs.
Mais pour moi, en tout cas, le jeu, il est surtout chez les hébergeurs, en fait.
Et ça ou pas ?
En fait, ce combat de grosse cacquette, c'est un peu ça en gros.
Ça tire toujours un peu vers le haut, en fait, parce que « burn », ils arrivent, ils bousculent tout ça.
Donc « deno » se retrouve confronté à devoir s'améliorer aussi.
« l'équipe de node » aussi.
En fait, ça pousse vers le haut.
Donc c'est une bonne nouvelle.
Et en plus, comme tu dis, au niveau infrastructure, c'est sûr que si tu utilises une runtime qui prend moins de mémoire,
ça te coûte moins cher en serveur aussi.
Donc ça peut être intéressant.
Et après, moi je sais que quand il y a 10-50 fois moins de mémoire pour gérer une page sur un XJS,
j'ai une application qu'on a déployée un petit moment qui est en prod,
où j'ai des problèmes de mémoire, en fait.
Il y a des montées de mémoire assez impressionnantes.
Et donc, il faudrait peut-être que je teste avec « burn » voir si ça règle le problème.
Mais en tout cas, c'est très prometteur.
Oui, ça annonce plutôt des bonnes choses.
Après, derrière, il y a une société, mais je ne sais pas si c'est une société,
ou un compagnie, qui vient de lever 7 millions.
C'est que le début.
Oui, je pense que c'est que le début.
On est complètement d'accord.
Cette mission, c'est vraiment une première levée.
Après, je pense que derrière, ils vont en faire beaucoup d'autres.
Parce que si vraiment « burn » est utilisé justement par les grosses hébergeurs type Versailles et les compagnie,
ils vont tous investir dedans.
Après, il ne faut pas oublier aussi qu'il y a le troisième homme.
Enfin, le troisième homme, ce serait plutôt « burn » qui arrive.
Bon, on se marchait là.
Le deuxième, c'était Deno.
Et quasiment un mois après, le « pop » et le « marketing » grandement menés,
on va dire, de « burn ».
Il y a Deno qui annonce un gros, gros changement.
Et est-ce que c'est une réaction à « burn » ?
Je ne sais pas. Est-ce que c'était déjà dans les tuyaux ?
Je ne sais pas non plus.
Néanmoins, ce qui est plutôt cool, c'est qu'avant, il fallait publier pour Deno.
Et là, maintenant, ils font une compatibilité immédiate et instantanée
avec tous les packages de NPM.
Je ne sais pas si tu as déjà utilisé Deno, mais je ne savais pas qu'on ne pouvait pas utiliser.
Moi, personne n'a jamais utilisé et je ne savais pas qu'on ne pouvait pas utiliser les packages NPM.
C'est sûr que c'était un gros handicap de ne pas pouvoir utiliser cet écosystème hyper riche en librairie.
Ils annoncent enfin de prendre en charge NPM, tous les packages pour les importer.
Tu faisais ton import spécifique et maintenant, tu fais ton import où tu vas flaguer devant NPM de point
le nom de ton package.
Et là, pour le coup, ça passe direct.
Ils annoncent aussi un retour rapide.
Ils ont optimisé le moteur.
Est-ce que ça va vraiment jouer le jeu ?
En tout cas, est-ce que ça vient vraiment exploser les perfs ?
J'en sais rien.
Après, chacun va faire des tests.
Vous dites oui, mais quand tu fais un set time out, c'est plus rapide avec burn.
Quand tu fais un console log, c'est plus rapide avec machin.
Quand tu fais une écriture de fichier, c'est plus rapide.
C'est bon.
Quand je fais un pad côté, je regarde et je dis que ça se tire la bourre.
C'est plutôt pas mal.
Ils annoncent un nouveau module HTTP.
C'est aussi pour ça qu'ils annoncent qu'ils seront les plus rapides jamais construits.
Le serveur le plus rapide jamais construit parce qu'ils ont un nouveau module qui arrive en HTTP.
Je ne sais pas exactement ce qu'ils vont changer.
Deno est construit sur du Rust.
Deno, c'est sur du Rust avec des modules HTTP.
C'est un nouveau moteur en ZIG.
Ils annoncent aussi un service client pour les entreprises.
Pour les entreprises et les entreprises des nômes.
C'est pas arrivé.
C'est américain.
Après, on va parler du gratuit.
C'est un nouveau moteur.
Après, pour revenir sur Deno et sur JavaScript,
on voit de plus en plus des frémoires
qui essayent d'être agnostiques le plus agnostiques possible
pour ne pas être mariés avec l'infrastructure.
C'est pour ça que je pense que nous en tant que développeurs,
on ne va pas tellement rentrer dans cette guerre-là.
Je pense que la guerre est plutôt chez les hébergeurs.
Parce que demain, notre frémoire sera agnostique.
Je trouve ça vachement bien.
Si on le déploie sur BUN ou sur Node,
ce sera pareil.
Pour nous, l'expérience de développeurs sera pareille.
Par contre, le rendu sera différent.
Peut-être qu'il me manque des infos.
Mais de mon point de vue,
je pense que cette bataille n'est pas entre les devs.
Elle est vraiment sur l'infrastructure.
C'est clair.
On y gagne aussi au niveau du build.
Quand on build des applications, le déploiement sera plus rapide.
Oui, carrément.
Et pour exécuter tous les tests sur les CIA.
Enchaîne.
C'est parti.
Oui, sur l'OBS.
Il y a toujours des propositions qui sont faites
pour faire évoluer le langage.
On sait que la gestion des dates natives
ne peut pas dire que ça soit super, super,
tendant et facile.
C'est pour ça qu'on a toutes les librairies qui gravitent.
On a le moment.
Mais hyper lourd.
C'est super compliqué.
On a eu toutes les librairies qui sont autour.
Les DGS, les dates FNS.
Toutes les librairies qui utilisent les mêmes API.
Il y a une proposition pour faire évoluer les dates.
Pour les rendre nativement plus facile à lire
et à utiliser avec des API qu'on connaît déjà.
Donc, ce serait vachement plus simple et facile à utiliser.
C'est temporal.
Si jamais ça passe, on pourra notamment utiliser certainement
côté serveur, après côté browser.
Il faudra le temps de se le déployer.
Enfin, j'ai envie de dire enfin.
Après, chaque langage évolue.
Après, ils sont obligés de prendre leur temps.
Surtout sur du JavaScript,
qui est aujourd'hui utilisé partout, partout, partout.
Ils sont obligés de prendre leur temps,
de bien peser pour elles-comptes, de voir l'adoption,
de bien écrire les specs de l'API.
C'est super intéressant.
Mais, ça peut nous faciliter la vie.
C'est encore en expérimental.
Doucement.
Après, on peut peut-être l'utiliser avec un flag.
Un moment donné, ça va arriver.
Avoir.
C'est pas mal.
Le free, c'est gratuit.
Free, c'est quoi déjà le slogan de free ?
Tu as tout compris ?
Pour le coup, c'est fini.
C'est tout frais.
C'est sous fraise, ça date de la semaine dernière.
Enfin, août.
Premier coup, c'est Héro-Coup.
Qui annonce.
Alors Héro-Coup, ça va être acheté, je ne sais pas quand.
Il y a un an, deux ans, par la grosse boîte.
C'est le Force ?
Oui, c'est ça.
Une grosse boîte remplie de vendeurs.
Au dans-long.
J'adore cette force.
C'est dur.
Après, c'est marketing.
Ils savent très bien.
Toujours est-il que Héro-Coup, pour ceux qui ne connaissent pas Héro-Coup,
c'est un passe, un plateforme à ce service.
Ou en tant que développeur,
on va envoyer directement le code.
Et on va faire un guide push Héro-Coup master.
Et en fait, ça va monter,
ça va builder automatiquement,
ça va déployer mon application.
Et je n'ai rien à gérer.
Je ne gère pas ma machine, c'est Héro-Coup qui gère ça pour moi.
Et pendant longtemps, ils avaient une partie gratuite.
Au BIS.
Non, au BIS, c'est déjà payant.
En fait, ils avaient un prix de tiers qui était assez généreux.
Ou en fait, ta machine, elle était obligée de dormir 7 heures par jour.
Ils ont vachement évolué les règles, mais les dernières règles, c'était ça.
Sur un cycle de 24 heures,
il faut que ton application, ton serveur,
ils dorment 7 heures, je crois,
ou un truc comme ça.
Mais si tu respectes cette consigne-là,
tu ne payes jamais.
Donc clairement, il y avait plein de cas,
où c'était super pratique.
Et aussi bien pour des devs,
je pense qu'ils sont en formation,
on peut déployer une application en production facilement,
on peut tester,
il y avait beaucoup de crash test.
Mais je pense qu'à la fin,
la facture devait être un petit peu quand même salée pour Iroku.
Et le général manager,
là, il dit que c'est fini.
Le chef, il a dit stop.
Le chef, il a dit stop.
On arrête de...
On arrête de payer le suivi.
On arrête de payer le suivi.
Et donc,
ça fait pas mal de buzz
sur l'écosystème,
parce que c'est un acteur majeur.
Après...
Un moment donné, ça arrête.
C'est vrai qu'il y a beaucoup de personnes,
même moi, je pense que j'ai un compte
que j'utilisais même plus d'ailleurs.
Donc ils ont annoncé qu'ils arrêtaient tous les plans gratuits
et ils allaient supprimer les comptes inactifs.
J'ai vu sur Twitter quelqu'un qui a essayé de se connecter à son compte
et il n'a même pas pu se connecter.
Donc apparemment, ça a déjà été supprimé.
Et surtout, ils annonçaient qu'ils expliquent
dans l'article, ils disent que leurs équipes de produits,
ils déploient beaucoup d'efforts pour gérer
tout ce qui est fraud de tout ça,
parce qu'il y a forcément des sites qui sont générés
pour faire du piching, des trucs comme ça.
Et je pense que ça les soulage un petit peu.
Donc ils disent que c'est pour ça qu'ils arrêtent le gratuit.
On le met tous ces sites de fraude.
Après, je comprends, mais en période un petit peu de contraction,
on peut déployer une application en production pour rien.
On peut mettre du post-gré pour Kedal, du redis pour Kedal.
Un moment donné, si on utilise de manière systématique
notre serveur ou l'application,
7 dollars par mois, ce n'est pas non plus monstrueux.
Si on a une vraie utilité et si le logiciel ou le service
qui tourne sur ces machines amène une vraie valeur,
je pense que 7 dollars par mois, ce n'est pas non plus monstrueux.
Mais celle et dev, il ne veut jamais payer.
C'est un problème de cette culture du gratuit.
Elle n'est pas bonne parce que rien n'est gratuit.
Ce n'est pas possible.
Après, il faut trouver le juste milieu
entre payer un serveur de 150 balles par mois
pour faire tourner une micro-appli
et le gratuit.
Oui, ça passe en payant.
Après, ce n'est pas très onéreux.
Ce n'est pas hyper cher.
Si il y a un client derrière qui peut payer,
pour une entreprise, c'est Kedal.
7, 15 dollars, c'est rien.
En plus, ils ont des possibilités
où tu coches autoscale.
C'est-à-dire, ça vient scale up, scale down.
En tout cas, l'équipe de dev n'a pas géré ça
parce qu'ils ne sont pas assez stafés.
Je ne veux pas faire l'apologie du passe,
mais ça peut solutionner beaucoup de problèmes
et ça amène une vraie valeur
pour des équipes qui sont stafées.
On voit aussi Netlify qui a réduit la voilure.
On a reçu une mail de Netlify,
la communication, le lendemain.
Je ne sais pas si ils se tombent d'accord.
Le Netlify était un poil plutôt.
Par contre, Netlify,
eux ils disent que si tu as une organisation
avec des rivaux privés,
tu ne peux plus pousser gratos.
C'est ça.
On s'est rendu compte que beaucoup d'organisations privées
appartiennent toujours à des équipes
qui les utilisent professionnellement.
En gros, il y a des entreprises qui ont des rivaux privés,
qui vont déployer gratuitement sur Netlify
et qui ne paient jamais.
Je ne vais pas dire que je ne l'ai jamais fait.
Mais c'est le même problème.
Ils déploient tout ça, ils hébergent gratuitement,
et ils ne s'en sortent plus.
C'est leur coût de l'argent.
Oui, c'est exactement ça.
En gros,
si vous avez un repos privé sur GitHub,
dans une organisation,
ce n'est pas un compte de votre compte perso.
Si c'est un compte organisation avec un repo privé,
ça ne fonctionnera plus avec les comptes gratuits sur Netlify.
Il faudra passer obligatoirement au pro.
C'est le jeu.
Mais pour ceux qui veulent se tourner vers d'autres solutions,
il existe d'autres solutions.
On pense déjà au français...
Scalingo, parlez.
Nous ne sommes pas sponsorisés.
Peut-être.
Si Scalingo nous entend.
Exactement.
Si Scalingo, on est chaud.
Il existe Capcom,
ou Coolify,
où on avait déjà parlé dans un certain épisode,
où là, pour le coup, on gère sa machine,
on vient mettre Coolify et Coolify et crée une interface.
Ce qui nous permet d'installer aussi bien
des applications
qu'on gère nous-mêmes,
du front, du back, des database,
et des services out of the box.
Ça te fait un éro-coup...
...perso.
Auto hébergé.
C'est exactement ça.
C'est le éro-coup Netlify,
auto hébergé sur ta propre machine.
Pourrais-on essayer ce truc un jour ?
Je pense, même à titre perso,
de mettre tous les analytics dessus,
soit un Ghost, soit un WordPress pour gérer le blog,
le language tools,
pour corriger le texte,
parce qu'on fait tous des fautes d'orthographe,
on est tous assez mauvais.
Je parle pour moi.
Pour le coup, c'est plutôt bien d'avoir un outil
qui gère ça.
Uptime Cuma, c'est pour gérer...
Ces services et les sites sont en ligne ?
C'est un peu l'équivalent de status page.
Ça vient pinger ton serveur
pour voir s'il répond.
Et Melee Search, le moteur de recherche.
Melee Search et Asura.
Juste une micro instance
où on met 5 ou 10 balles par mois
et on installe tous ces services-là
à titre perso.
C'est quoi cette liste ?
C'est tous les services
qui sont out of the box.
C'est un one-click install.
C'est un one-click install.
Ça me fait rêver.
Oui.
C'est vraiment...
C'est un one-click.
Oui.
Franchement, c'est...
VSCode Server ?
Je vois la liste.
Tu lances ton navigateur sur ta propre instance
et ton VSCode s'ouvre dans ton navigateur.
OK.
C'est l'équivalent de GitHub
code space, si tu veux,
mais sur ta propre machine.
Ce qui fait que tu n'as pas à payer code space,
par contre, sur la puissance que tu vas pouvoir déployer,
ça va dépendre de la machine que tu as mis derrière.
Il faut qu'on t'asseute.
Mais carrément, carrément.
Non, c'est vraiment...
Et l'autre, c'était CAP Rover.
CAP Rover.
C'est la même chose.
De la même manière, il faut l'installer.
Et on a une interface identique.
Je pense que c'est beaucoup moins poussé
que peut être...
C'est pas plus poussé.
Coolify.
Néanmoins, il y a aussi des one-click installs
sur les DB.
Je ne sais pas si là, il y a des services
qui sont déjà gérés.
Non, je ne crois pas.
Mais en tout cas, ça vient nous donner
cette idée d'infrastructure
qui nous assiste énormément.
Donc, c'est un peu en rendir,
c'est un peu une solution hybride
entre la solution totalement hébergée
où on fait tout, on gère nos machines, tout seul,
et elle le passe,
où on met la carte bleue et on déploie automatiquement.
Là, il y a peut-être un truc intermédiaire
à trouver.
C'est pas mal pour les agences
ou les entreprises
qui ont envie de passer un peu de temps là-dessus
d'installer ça, d'utiliser en interne.
Ça peut être pas mal, je pense.
Carrément.
Carrément.
OK.
Builder.io, c'est quoi, Patrick?
T'es où là?
Je ne l'ai pas à celle-là.
Tu n'as pas.
Mais sur le même doc ou quoi?
Alors, c'est...
Ah oui, 8.6.

C'est vrai.
Builder.io, c'est une organisation
qui fait plusieurs outils
mis à disposition
qui sont pas mal, donc Quick.
Quick, c'est un framework JavaScript
qui est vraiment prometteur.
D'ailleurs, je vais le tester prochainement
parce que je vais faire un crash test
dessus, parce que ça a l'air vraiment top.
Je vais regarder une vidéo.
Et ils ont aussi...
J'ai découvert sur leur rythmie
qu'ils avaient ce mythosiste
qui est un outil
qui permet de builder du code
JavaScript
en différents frameworks.
Tu peux faire une sortie en vue,
en React, en Quick, en Angular, en Svelte.
Et à partir du même code,
ça transpile le truc
dans un langage des frameworks.
OK.
Donc, en fait, tu choisis toi-même...
Tu peux l'écrire en JSX, je crois,
si je me trompe pas.
Et après,
en fait, en fait, en gros,
tu fais ton code, ton application
de la façon de mythosiste
qui est en version beta encore.
Donc, je n'ai pas encore regardé profondément
comment ça fonctionnait. Mais tu vois,
c'est du JSX, ça ressemble à du React un petit peu.
Et ensuite, ça te compile
en ce que tu veux.
Je trouve ça fou. OK.
Après, je trouve que...
Ouais, je vois mal
l'intérêt quand tu fais un choix.
Mais, par contre, ce que je constate
c'est que, pour revenir
et reboucler sur ce qu'on disait tout à l'heure,
on rentre
dans une ère où
on est framework agnostique.
Oui, totalement.
Et donc,
on comprend bien que
une fois qu'on a choisi un paradigme,
c'est dur d'en sortir.
Donc, toutes les
créateurs de solutions
ou de services
si ils choisissent
un framework, en fait,
ils sont cantonés
à une certaine typologie d'entreprise
ou de
développeur.
Donc, là, on voit toutes les solutions qui sortent.
Maintenant, elles sont toutes,
mais toutes, frameworks agnostiques.
Je pense à Astro qui est sorti
en version 1
aussi.
On va dire, de manière officielle,
ok, tu veux faire du Svelte,
BIM, tu fais du Svelte.
Tu veux faire du React.
Tu veux faire du Solid.
Vas-y, vas-y, vas-y.
Et en plus, maintenant, alors je te rebondis
sur ce que tu viens de dire sur Astro, ils viennent de rentrer
Alpine.js.
Oui, exactement.
Mais c'est hier, je crois, non ?
Oui, je sais plus quand ils ont annoncé ça,
mais voilà, ils ont annoncé qu'ils prennent en charge
Alpine.js dans Astro, donc,
au même titre que React, vu tout ça.

oui, de toute façon, l'air, elle est
au framework agnostique, donc
c'est fini, la guerre des cloches, React, vu, machin, tout ça.
Aujourd'hui, vous pouvez coder
ce que vous voulez et ça vous sort,
vous utilisez le même outil comme Astro,
Astro, par exemple.
Qu'on reteste,
ou on va peut-être faire un crash test,
un truc comme ça, parce qu'en plus, ils ont rajouté le SSR
sur Astro qui est sorti, d'ailleurs, Astro qui est sorti
en version 1.0, il n'y a pas très longtemps,
donc, vraiment, officiellement.
Et très beutille,
très, très beutille.
Oui, très, très, clairement,
très, très, très, très, très beutille.
Yes !
On ne parlerait pas un petit peu
de débaie et
de tout ça,
avec Planet Scale
qui annonce
des choses intéressantes ?
Alors, oui, oui, Planet Scale,
personnellement, je ne connaissais pas.
J'ai vu cette news que tu avais rajouté.
Je ne connaissais pas du tout Planet Scale,
j'ai essayé hier soir pour voir un petit peu
ce que ça faisait. Alors, c'est intéressant.
J'ai compris un peu le principe.
Donc, ça fait des branches,
donc, tu as une branche de production de ta DB, en fait.
Et tu peux faire des branches un peu la GitHub,
en fait, développement, machin, tout ça.
Avec des changements
sur tes DB.
Et, à mon donné, tu mets en production,
tu marches, je n'ai pas tout capté,
encore, mais...
Après, Planet Scale,
le gros truc
qu'ils ont introduit,
c'est vraiment ça. C'est
cette histoire de pouvoir merger,
de créer des branches,
en fait, dans tes données.
Et ça, c'est
ouf. Après, il y a
aussi une tendance
qui évolue. C'est qu'il y a
de plus en plus de Serverless. Le Serverless
à chaque
fois, en fait, il va aller
taper la connexion,
la base de données.
Donc, en fait,
il y a des poules de connexion
qui doivent être gérées et ça amène
d'autres problèmes.
Et c'est pour ça,
je pense qu'il y a Prisma,
d'Aub, en fait,
il y a Prisma qui gère,
qui va gérer ça aussi
sur un data proxy,
parce que
si toutes
les fonctions à
le service viennent se connecter en même temps
à la DB, ils vont ouvrir
un canal
du poule de connexion
à la DB et, à un moment donné,
ça va s'assaturer. Donc, l'idée,
c'est d'utiliser une sorte de proxy
justement avec leur data
plateforme pour, justement,
centraliser
les connexions
pour éviter d'avoir
une saturation pour le server less.
Et donc, PlanetSky
est venu
là-dessus
pour gérer
encore plus
ce problème-là
et toutes les problèmes de...
toutes les...
J'ai expliqué pour les gens
qui, peut-être, ne sont pas bien captés,
en gros,
quand vous avez un serveur node,
vous démarrez votre serveur node,
vous connectez à la DB
et là, il y a une connexion persistante
qui va rester tant que le serveur tourne, en fait.
Donc, ils ne se reconnectent pas à chaque fois, en fait,
sur un serveur node.
Le truc, c'est que les fonctions serverless,
elles sont indépendantes,
elles travaillent indépendamment des autres.
Donc, à chaque fois, ça veut dire qu'à chaque fois
qu'une connexion va être appelée,
une fonction va être appelée, il va se connecter
à la DB.
Et ça fait... si plusieurs fonctions sont appelées en même temps,
ça va faire pleins de connexions.
Et en un moment donné, c'est un goulot d'étranglement.
Donc, c'est ça que tu expliquais, en fait, c'est qu'à un moment donné,
il y a trop de connexion et ça pose problème.
Donc, il faut réussir à faire une connexion
persistante
avec des serverless.
En gros, c'est ce qu'ils font.
Exactement. C'est ce qu'ils font.
Et justement, sur l'article
qu'on introduit
où
on peut aller directement
exécuter
du SQL.
En fait,
en JavaScript, on va pouvoir
exécuter la commande enclaire.
Ils viennent donner
accès au plus proche
de la DB. Souvent, en fait,
on a un
truc au milieu,
un ORM, qui va gérer
toutes les connexions, qui va gérer
l'appel au données et tout ça.
Et eux,
en fait, ils ont fait le choix
de
donner accès directement au JavaScript.
Donc, on
tape la requête SQL
et ça part
directement. Ouais, à l'ancienne.
Après, en termes
de perf, est-ce que c'est intéressant ?
Je pense que oui.
Après, c'est vrai que c'est un gras.
Le SQL, on ne peut pas dire que ça soit
très, très joli.
Mais en tout cas, ils donnent
accès à ça. Et Planet Scale
est vraiment organisé
aussi sur tout ce qu'est Edge.
Et en fait, ils veulent
répliquer au maximum.
Et que la
DB ne soit plus un
problème
quand on passe à l'échelle.
En tout cas, c'est le projet
de Planet Scale.
Oui.
Et qui apparemment fonctionne, je crois,
sur différentes plateformes vers celles.
Après,
ce qu'ils disent.
Après, en fait, ils ont leurs propres
plateformes.
Oui, après, le driver qui est en sortie,
il a l'air d'être adapté pour
tous les principaux
hébergement.
Oui, sur le Serverless.
Et ce que ça soit sur Cloudflare
ou Netlify, Versel et tout ça.
Non, c'est top.
C'est au système.
Et juste le fait
de pouvoir
créer des branches
de la même manière qu'on fait avec du code,
là, on ne va pas venir altérer
les données.
On va créer notre branche.
Et au moment du merge,
on va gérer tout ça.
C'est assez puissant.
Mais je pense qu'on va faire un épisode
vraiment sur toutes
les DB.
Et surtout, l'approche moderne
des DB, parce que
les bases de données sont en train d'évoluer
vers autre chose, qui sont
encore plus faciles pour nous, développeurs.
Et je pense que c'est intéressant
d'en parler. Après, comme je te disais,
l'histoire des branches, tout ça, c'est pas mal,
mais je ne comprenais pas. On a déjà
des systèmes de migration.
Après, c'est sur les frameworks
qui sont un petit peu magnifiques. Mais comment tu gères
les données ?
Généralement, dans ton filier de migration,
les données, je ne sais pas.
Parce que ça prend aussi les données des branches.
Je n'ai pas tout compris dans le système.
Mais bon, il va falloir qu'on regarde ça.
Ça marche.
C'est quand même assez
puissant.
Donc, cool.
Petit design
Alpha de Storybook.
Yes.
Storybook est en version 7.0
en Alpha.
Ça veut dire qu'ils vont bientôt sortir.
Enfin, ils vont bientôt.
On n'est pas encore en Beta, mais ça va arriver.
Mais c'est des petits restylings
d'interface, tout ça.
Évidemment, il y a du... Alors, ils ont beaucoup...
La 6.5 est sortie à début de l'été, je crois.
Ou ils travaillent. Alors, le reproche principal
de Storybook, c'est le temps de build,
le poids de l'application, tout ça,
quand tu as des builds des, tout. Ils ont énormément travaillé
là-dessus, puisqu'il y a beaucoup d'autres
challengers qui sont sortis depuis, avec
histoire, je ne sais pas qui y a d'autres.
Voilà, tous ces systèmes
de bibliothèque de composants
qui sont beaucoup plus performants.
Et donc, Storybook a...
Voilà, toujours pareil, ça fait monter le niveau.
Storybook se bat pour rester
l'outil principal. Et donc, ils ont
amélioré les performances, le build, tout ça.
Et donc, la version 7.0 arrive bientôt.
Et encore, ils ont travaillé là-dessus.
Ils ont restylé un petit peu l'interface.
Ah, c'est les nouvelles icônes, tout ça.
Storybook, très beau outil, honnêtement.
Si vous pouvez l'essayer un petit peu, c'est pas mal.
Moi, c'est Patrick Approved.
Ah, voilà, je l'utilise depuis
super longtemps, depuis la version...
Je ne sais même pas. D'ailleurs, je vais passer.
Il y a pas longtemps, une version 4, je crois.
À 6. Et je m'en suis bien vu.
Donc, c'était sympa.
Yes.
Geat Explorer.
C'est quoi ?
Alors, ça, c'est pas une nouveauté.
C'est un tool que j'ai trouvé,
vient un tweet, en fait, qui te permet,
en fait, de trouver des commandes
utiles pour le guide, en fait.
Les principales commandes, quand tu veux faire des actions,
tout ça, créer des branches, tout ça.
Donc, pour les gens qui ne sont pas encore bien à l'aise
avec les commandes guides,
et pareil pour moi, je ne connais pas toutes les commandes
parkers, ça te permet
de sortir les commandes, de les afficher,
de savoir exactement la fonction.
Mais...
Alors, là, c'est plus à profil d'éducation.
Parce que, maintenant,
je pense surtout à
des tools type FIG,
ou VRAP,
ou des choses comme ça, où on va avoir
une auto-completion de toutes les commandes
dans la CLI.
Donc, là, c'est plus à titre,
on va dire informatif et d'éducation.
Oui, c'est ça, d'éducation informatif.
Il faut t'a oublier
quel est le paramètre,
ou l'option... Après, tu vas me dire, tu fais un guide
de tout tirer et tirer, ça marche, mais...
Ouais, c'est simple.
Exactement. On peut aller
sur le site et
aussi découvrir... En fait, c'est beaucoup
plus agréable
que la simple doc.
Et là, on peut aller explorer
chaque fonction.
Yes, yes, yes, yes, yes.
Yes.
On parle
de graphiql
en D-Edge.
Ou de graphiql aussi, on a oublié
de parler de graphiql.
Graphiql, exact.
Graphiql qui sort
en version 2.

Et qui est
pour le coup un peu plus
designé. Alors, graphiql,
c'est l'outil graphique
un peu de playground,
on va dire, pour aller
tester toutes les queries en graphiql.
Donc,
on va pouvoir utiliser
soit Postman, Insomnia
ou des choses comme ça.
Qui sont des logiciels
prévus
pour ce type.
Par contre, graphiql, souvent,
on va mettre ça sur le serveur
pour jouer, pour aller explorer
la doc.
C'est vraiment le playground.
C'est l'interface graphique
et visuelle de notre
API Graphiql.
Et ils sont passés en V2
avec des nouvelles fonctionnalités
mais le premier
truc qu'on voit, c'est le pollissage
clairement de
la doc aussi peut-être, la évolue, je sais pas
les docs.
La représentation de la doc,
tu veux dire, ou la doc
de l'outil.
Non, c'est la doc
ce qui est possible comme requête,
les paramètres et tout.
Comment ça, le schema générer en fait ?
Tu vois le schema
et par contre
tu vas récupérer
toutes tes docs.
C'est beaucoup
esthétique en fait.
Parce que la doc n'est pas la même.
Oui, c'est très esthétique.
Après, de toute façon,
la doc est générée
de manière automatique
sur le schema.
Donc de toute façon,
toutes les infos, tu vas les retrouver
mais c'est la disposition
de ces infos qui va être plus pertinente
et qui va être
un petit peu plus agréable
à l'utilisation.
On va se rendre les requêtes, on va dire, on va les requêtes pour voir.
Je sais pas.
Après, c'est...
Il n'y a rien de...
Pour le coup, c'est vraiment de la cosmétique
je vais dire.
Après, peut-être que
c'est de l'aisance
aussi sur l'utilisation des variables,
on peut peut-être stocker des variables
ou créer un petit peu plus un environnement.
Après, de toute façon,
pour moi, GraphiQL,
c'est quand même l'outil
pour aller faire du quick crash
et construire ta requête très rapidement.
Après, quand tu es sur un projet
un peu plus solide, où il y a un peu plus de personnes,
tu as tout intérêt
à venir historiser tes requêtes.
Et donc là, tu vas passer
sur un outil type postman
ou un somnia.
Et pour le coup, tu peux partager ça
avec tes collègues.
Tu viens variable
tes environnements,
tes variables,
tes aideurs, tes clés API,
enfin, tout ces trucs.
Après, GraphiQL, c'est un outil
qui est dispo dans certains
frameworks ou CMS en fait,
style sur Gatsby, tu l'as d'origine
quand tu lances Gatsby, GraphiQL qui dispo.
Sur craft CMS aussi,
il y a un GraphiQL qui dispo dans la mine
quand tu veux faire tes requêtes pour tester.
Ouais, c'est beaucoup pour tester.
Bien sûr.
Pour moi, je vois vraiment ça comme
playground.
Et
on parlait du
edge
dans un certain
épisode, je ne me rappelle plus lequel,
mais
le gros problème qu'on a
avec GraphiQL, c'est qu'on peut
pas te renjouer.
Cache, exactement, je lui ai perdu mon
oeil.
Mais
ce qui est
voilà.
C'est un vrai problème.
C'est un vrai problème.
En GraphiQL, parce que le client
va demander
qu'est-ce qu'on met en cache,
qu'est-ce qu'on met pas en cache,
quelle règle on applique de toute façon
de manière générale, dès qu'on parle
du cache, on sait que c'est quand même
problématique et c'est touchy.
Donc il faut
mettre des choses en place, mais c'est
complexe.
Un service qui vient se mettre
en intermédiaire dans le edge
ou justement, il vient cacher
les requêtes
pour optimiser le temps de réponse.
Ouais, en fait, GraphiQL,
tu peux pas mettre de cache
côté serveur, que côté
client. Je ne suis pas connerie.
Alors, en fait,
maintenant,
sur Asura, par exemple,
ils ont...

ils essaient de faire ça aussi
que tes serveurs.
Mais c'est moins pertinent
que de le mettre justement sur du edge
qui va être au plus près de l'utilisateur.
Donc ton cache,
il faut le déporter ailleurs.
Mais en tout cas,
côté serveur, tu peux faire de l'optimisation
sur Asura, par exemple, ils ont une directive
où tu vas mettre cache et tu vas
l'invalider d'idée,
tu vas donner une date, donc
un timeframe de 10, 20, 30,
une heure, parce que potentiellement
cette requête, elle va ressortir
beaucoup, donc autant la cacher
pour l'optimiser.
Mais ça, c'est
propre à Asura.
Là, pour le coup, ce type de service
là, et je crois qu'il y a Graph CDN
aussi qui fait la même chose.
En fait, c'est eux en fait.
Graph CDN est devenu
Stelite.
Je sais pas comment vous pouvez prononcer
Stelite, on va dire la française.
En fait,
c'est eux, ils sont devenus Stelite.
Là, il n'y a pas longtemps, c'est Graph CDN.
Et justement, ils vont beaucoup plus loin que ça.
Alors, pour info,
par exemple,
si tu fais du Next.js,
quand tu vas générer tes pages,
il n'y a pas vraiment moyen de mettre en cache.
Donc, à chaque page, il va faire la même requête
GraphQL, ce qui peut être rapidement
un problème si tu as beaucoup de pages.
Ça, c'est un gros souci
de Next.js, on peut pas mettre en cache
la génération des pages. Donc après,
il y a des moyens avec des fichiers, enfin des trucs comme ça.
Et en fait, eux, ils vont beaucoup plus loin avec
ce Stelite.
C'est qu'ils peuvent se connecter
à ton CMS, tout ça.
Je sais que je crois qu'il y a un truc qui existait
sur WordPress. Et en fait, il va mettre en cache
les réponses.
Et si par contre, tu vas
modifier le contenu, tout ça, il va re-générer
le cache en fait automatiquement.
En fait, tu vois, c'est pas toi qui va définir
un temps, en fait.
C'est plutôt le fait que tu changes
la donnée qui va générer
le nouveau cache, en fait.
Donc, c'est vraiment pas mal
en fait comme système.
Et ça améliore énormément les performances,
et ça libère totalement
ton serveur, en fait, des requêtes.
Parce que si tu as 10 000 fois la même requête,
tu la sens même plus passé, quoi.
Ouais.
Ok.
Donc, c'est la même boîte
qui ont évoqué sur...
Ok, super.
Parfait.
Et c'est eux qui prennent la charge, quoi.
Ouais, c'est eux qui prennent la charge,
après ils mettent en cache, et puis c'est parti.
Top.
Bon produit, ouais.
Parfait.
C'est bien ce que je disais, voilà.
Vite fait, j'en parle, il y a un Stelite
WordPress plugin, donc on peut mettre
le plugin sur WordPress
pour VP GraphQL et avoir un cache.

Donc, c'est pas mal.
Excellent.
C'est testé en prod
pour voir les
perves, mais c'est super
parti, non ?
Yes. Voilà pour vous. Patrick.
Un grand merci.
Un grand merci pour cet épisode
News.
Et maintenant, on est
partis pour en faire un tous les mois.
Donc, c'est une belle...
Yes, yes, yes.
N'oubliez pas la chaîne YouTube
qui est suivée nos vidéos, on fait
des lives assez souvent.
On est en train de refaire la site aussi.
Faire le live pour...
Et toute la construction du nouveau site
de Double Slash se fait
en live et open source.
Ce qui fait que sur le repo
Double Slash, sur GitHub
vous pouvez voir tout le site Internet.
Et
sur YouTube, vous verrez les lives
où on code ça
en public.
Un grand merci à tous.
Pensez à mettre un petit like,
parler du podcast, ça fait toujours plaisir.
Un petit commentaire.
Abonnez-vous, ça fait toujours plaisir.
Allez, ciao, ciao. A bientôt.

www.doubleslash.fr
Sur le site, vous allez retrouver tous les liens d'épisode, les références
évoquées durant l'émission.