Bonjour et bienvenue dans ce nouvel épisode de Messages à caractère informatique, épisode
numéro 144.
Aujourd'hui nous sommes le 26 septembre de Milvanzanque comme d'habitude je suis Horacio
Gonzales et aujourd'hui je suis accompagné de Jean-Merveilleutel que Sebastien Bruna.
Bonjour Sebastien. Bonjour Horacio. Qui pensait qu'à ce derrière c'est Githpoul, c'est Julien Durillon.
Bonjour Julien. Bonjour Horacio, bonjour tout le monde. Et derrière Franck en PHP,
Sané Petre, que Mathieu Santo Estefano. Bonjour Mathieu. Salut Horacio, salut tout le monde.
Bon je suis super content de vous savoir là et pour ne pas déroger le bon principe on va commencer
avec un petit tour de table. Vous pouvez vous présenter et raconter un petit petit petit peu
qui vous êtes. Allez on va faire d'alordre que on a présenté. Sebastien qui tu es, qu'est ce que tu
fais raconter ? Alors qu'est ce que je fais ? Donc je suis ingénieur avant-vente pour l'équipe
commerciale de clévercloud. Qu'est ce que je fais concrètement ? J'accompagne les clients qui
enfin même les prospects généralement qui voudraient venir déposer leurs applications PHP par exemple
mais pas que sur clévercloud pour leur faire des conseils en architecture et leur conseiller des
solutions adaptées à leurs besoins. Nickel. Julian qui tu es ? Oula officiellement je suis vice
présidente d'ingénieur riche clévercloud sur des fondateurs de la boîte. Concrètement aujourd'hui
vu que la boîte atteint une centaine de personnes ça veut quand même beaucoup dire que je fais le
vieux sache sur la montagne à expliquer à quoi ressemble l'historique de la boîte techniquement
pour tous les nouveaux qui viennent pour construire le futur.
Donc Julian biesa sur la montagne c'est bon comme titre et Mathieu qui tu es ?
Eh ben moi donc je suis Mathieu, je suis expert technique chez Sennhsiolabs, avant ça j'ai passé une
dizaine d'années dans une autre agence qui appelle JoliCobb et je suis aussi membre de la
courtime de Sanfonie donc un framework PHP français à l'origine mais maintenant international depuis
2021 donc ça va bientôt faire quatre ans. Voilà et donc Sennhsiolabs expert technique j'accompagne
des clients sur des audits d'architecture sur des études d'architecture sur des missions
coups de poing ou des sujets complexes à craquer donc voilà accompagnement sur toute la stack PHP
et puis un peu ce qui gravite autour les bases de données, cash, HTTP, voilà plein de choses.
Je suis vraiment content de te voir ici parce que ce n'est pas souvent que
on a de la communauté PHP à l'intérieur de notre masque et là c'est super top quand on va pouvoir aussi
raconter des news que ce n'est pas ce que l'on raconte habituellement et c'est très bien.
Je pense que quand on a préparé l'épisode on a un planqué de Lian pour parler, ça va être
le show de ce qui est de parler de tout ça donc je vous laisse commencer. Allez Mathieu à ton
honneur. De quoi tu veux commencer à nous parler ? C'est vrai qu'on a une planquée de Lian dans l'ordre
des choses on peut parler d'un sujet qu'on a vu ensemble enfin en tout cas que moi j'ai vu quand
on s'est croisé la semaine dernière à l'abbé platform con à l'île c'est Franckon PHP qui a
annoncé le support à venir parce que c'est encore expérimental de GRPC parce qu'en fait
historiquement faire un serveur GRPC en PHP c'est moyen possible voire pas possible parce qu'on
n'a pas la moyenne d'avoir des connexions persistantes de façon native. PHP c'est un modèle
falloir me forget on oublie tout ce qui se passe à la fin de notre enquête et donc on a ce problème
là sauf que Franckon PHP qui est supporté maintenant par cléver arrive avec un en fait
un nouveau serveur d'application pour PHP qui a un mode d'e-worker qui permet de garder le même
process et d'exécuter différents trequettes avec le même process et donc on a plus ce
faraide forget du coup on a un moyen de supporter GRPC en tant que serveur et donc de ce que j'ai
compris que de ce que Kevin a expliqué parce que généralement quand Kevin il pardonne Kevin
le fondateur le créateur d'API platform et de Franckon PHP quand il parle dans ce genre de sujet
il faut un peu s'accrocher c'était assez dense comme présentation et donc de ce que j'ai compris il a
une partie du serveur applicatif donc écrit en go Franckon PHP écrit en go cette partie là va
s'occuper de la connexion persistante et va s'occuper de transformer la requête GRPC en une
requête compréhensible par PHP et donc derrière par symphonie et API platform la ravelle ce que
vous avez comme framork et à l'inverse au moment du retour de la response on va avoir la transformation
inverse qui va être converti alors je sais pas si la partie protobuf sera faite côté PHP ou côté
gauche en s'avent c'est je sais pas si encore définit mais il y aura cette voilà cette conversion à
double sens aller autour il maintient la connexion persistante GRPC par une extension du coup alors
une extension en go dans franckon PHP qui permet de gérer ce support de ver pc donc voilà ça permet
d'ajouter une des dernières briques tech web qui n'avait pas PHP nativement ça c'est top parce
qu'effectivement ce qui est un choix de PHP depuis 30 ans entre comme ça et ouais 30 ans cette année
ouais c'est ça ce qui est ce qui est dans l'architecture PHP effectivement c'est simple t'as
un fichier tu appelles ce fichier ça exécute le fichier ça répond après il y a tout un tas de
tremors quand rajouter de la la complexité à tout ça je dis pas que c'est devenu plus compliqué
mais qu'on rajoutait des choses un peu plus entreprise on va dire à ce qu'on appelait à la base
personnel home page mais ce fonctionnement là non mais c'est effectivement ce fonctionnement là de
tu l'as inscrit une fois que la script est finie ça pose enfin ça pose dans certains cas d'usage
un certain nombre de problèmes nous le plus gros qu'on va chez claver clott c'est quand tu dois te
reconnecter à la base de données quasiment à chaque fois pour ça il y a différentes solutions
mais c'est quand même le plus gros point noir je trouve en général quand on voit passer des tickets
PHP sur le support c'est des gens qui galèrent parce que il décide d'ouvrir 50 connexions pour
chaque requête ce genre de choses après parfois le problème est entre la chaise et le clavier
mais effectivement ce modèle là fait qu'il faut le savoir et quand tu commences à faire
des trucs un peu complexes tu te fais facilement avoir mais effectivement déjà franquaine PHP
qui te permettent de partir plus en mode serveur d'app ou potentiellement tu peux avoir des choses
qui tournent un peu plus long terme j'ai pas su mais il semble qu'ils ont bossé aussi sur une
pas j'ai vu passer peut-être qu'ils travaillent dessus du connection pooling aussi où je vais
passer ça j'ai dû entendre une discussion à un moment mais en fait cette extension là elle est
basée sur un autre que j'ai annoncé il y a quelques semaines maintenant c'est le fait de pouvoir
écrire des extensions PHP donc historiquement écrire des extensions PHP sans renoncer et là
ils ont ajouté le fait dans franquaine PHP de pouvoir les écrire en go et en fait franquaine PHP
fournit l'espèce de petit glucé qui est indispensable à register une extension PHP et on
peut écrire quasiment l'intégralité je crois qu'on a d'attaque à 39% du code qui écrit en go voir
presque 100% mais en effet le plus simple je crois les amis que ce le moment où on va devoir donner
une petite explication de qu'est ce que c'est franquaine PHP pour de nous parce que là je pense que
certaines personnes sont en train de nous écouter me décoille par le si si c'était la petite peluche
que sous laquelle matias se cache et pas que c'est franquaine PHP je peux l'expliquer ou je veux
dire si tu as franquaine PHP c'est un peu le nouveau le plus moderne des serveurs d'application qui est
capable de servir du PHP donc historiquement on avait mode PHP avec apache donc le fameux module PHP
qui se branche sur Apache et on avait aussi PHP FPM qui est généralement le back end qui a derrière
des serveurs à n'importe qui et en fait tout ça ok c'est super ça existe depuis super longtemps
c'est maintenu et tout mais ça n'évolue pas des masses et donc en fait Kevin Denglas qui entre
autres le créateur de franquaine PHP d'appli plateforme et le patron des tiel à créer ce
bah ce nouveau serveur d'application franquaine PHP donc c'est écrit en go ça se base en fait
sur caddy web server donc il y a un web server plus moderne qui lui aussi écrit en go qui
remplace apache voilà qui peut remplacer apache pour le coup alors caddy pour le coup voilà c'est
un concurrent on va dire entre guillemets direct à nj enix apache c'est-à-dire deux yes mais voilà
enfin tout tout c'est pas en quête ça et donc c'est très extensible et donc Kevin a fait en sorte
d'écrire quelque chose qui est capable de recevoir une recette HTTP raw enfin pure quoi brute et de
faire tourner un moteur d'exécution de faire tourner le moteur d'interprétation de PHP donc le PHP
c'est en fait il le compile il le fait tourner il le fait tourner à côté de caddy et donc c'est
ça franquaine PHP donc soit en sensaire en tant que franquaine PHP qui est une distribution de caddy
qui embarque ce moteur PHP soit on peut utiliser caddy comme serveur web ajouter d'autres extensions
dont franquaine PHP j'espère que je dis pas de bêtises si Kevin tu me les écoutes tu corriges
mais normalement ça va presse à le truc en tout cas ça donne une explication claire pour
ce qui était passé à côté de franquaine PHP et voilà et donc ça explique pourquoi la news dont
tu parle dont on parle là g r pc et maintenant possible parce qu'effectivement quand t'avais
apache avec derrière PHP, fpm et la discussion entre les deux le g r pc était plus compliqué à
l'op et en fait franquaine PHP permet de rajouter des nouveaux usages de ce type là et moi je
parlais de connection pooling à la base de données et je pense que c'est les genres de choses qu'il
y a des gens qui ont fait de temps de bosser dessus c'est bien possible c'est un gros point aussi
mais parce qu'historiquement que ce soit un gennix ou apache on a ce fameux modèle fire and forget
et soit il fallait utiliser des extensions un peu particulière pour ne pas avoir ce comportement
là et en fait franquaine arrive à un mode par défaut que le mode worker qui va en fait faire
tourner plusieurs requêtes en 30 sur le même process PHP en tout cas sur le même process de
savoir d'application je sais plus en interne si vraiment c'est le même process PHP ou si
l'en bout de plusieurs et puis après reparti ça c'est la tambouille interne de franquaine mais je
sais qu'on y a des requêtes qui peuvent être exécutés sur le même process et du coup ça
déporte en fait à la responsabilité du développeur PHP le fait de devoir risaider certains trucs en
mémoire on doit se reconnecter à des choses donc ça change un peu le modèle historique de
qu'on a depuis ben 30 ans en fait en PHP faut penser quelque trucs mais ça ne ferait pas vas-y
une transition si c'est le cas est ce que ça ferait pas revivre PHP mais c'est ça et c'est ça
mais bien je suis aussi ma transition je vous raconte ma transition parce que c'est la
mousse l'autre jour je disais justement oui c'est fou comme un PHP à évoluer ça chanier et
j'essaie d'expliquer à d'autres développeurs que PHP n'est pas mort et c'est Mathieu qui m'a dit
ah non il faut pas dire que PHP n'est pas mort exactement tu nous expliques cet idées là
ouais ça c'est un autre lien si j'arrive à le retrouver pour pas dire de bêtises dessus en fait
quand on dit que PHP est mort le problème du cerveau humain c'est qu'il entend PHP est mort
mais PHP et T mort c'est à dire qu'on entend ces deux mots là et en fait avant d'interpréter la
négation le cerveau humain il interpréter d'abord les mots principaux de la phrase et donc dans PHP
n'est pas mort PHP snap dead on entend d'abord que PHP est potentiellement mort et ensuite on va se
poser la question de non il est pas mort mais pourquoi et donc en fait faut arrêter de dire ça
parce que ça propage toujours et ça entretient la légende que à un moment PHP est mort alors
peut-être qu'à un moment PHP ça a un peu perdu et a perdu en autorité en popularité etc ça c'est
pas impossible mais on continue à entretenir cette légende là en parlant de cette fameuse phrase
PHP snap dead pour parler des nouveautés de PHP donc vaut mieux ne plus dire ça et parler vraiment
de ce qui est important dans une nouveauté PHP qu'on a du typage dans 95 19% de la syntaxe
maintenant vraiment il y a très peu d'endroits où on est plus typé on a pas mal de syntaxe qui sont
arrivés à maturité en gros et qui rattrapent en fait un peu le retard que PHP avait par rapport
à d'autres langages il ya compositeur il ya compositeur on a un gestionnaire de package qui
fonctionne très bien on tourne par là peut-être un petit peu plus tard parce qu'on a un sujet sur
l'infrastructure des package manager et surtout en fait on a des fras morts que alors on a pas
d'être de plus gros un symphonie la ravelle qui embarque une énorme majorité de la communauté
qui font tourner des applications à grande échelle on a des e-commerce internationaux aujourd'hui
qui tournent en suivant le soleil qui tourne sur du symphonie ou du la ravelle donc sur du PHP
donc ça marche très bien et c'est devenu très performant et ça devient encore plus performant
avec les versions qui arrivent voilà il ya encore quelques défauts on en parlera aussi probablement
et encore des fois à l'intérieur dans le syntaxe dans les animations natives qui sont fournies des
trucs un peu bizarres mais on essaie quand même de s'en délaisser au fur et à mesure du temps
le ménage est fait régulièrement le ménage est fait en temps et un petit ménage qui va être fait en
8 à un gros gap entre PHP 5 et ces dernières versions et jusqu'au PHP 7 et on se demande pourquoi
la version 6 a disparu entre temps c'est peut-être si le sujet de la fin de l'incertitude qui a
traversé le langage à un moment donné non c'est que la version 6 est modi de manda windows
à PHP 6 il existe un livre PHP 6 qui a été publié et édité alors que la version n'est jamais
sortie c'était des histoires de support du nicode dans le corps et en fait ça n'a jamais vu le
jour parce qu'il y a eu des des sujets dans la communauté qui font que le débat est par
arrivant son terme et donc la version a été abandonné en fait au profit de PHP 7 et du gros
gain de performance entre 5 à 7 qu'on a connu. D'une fois avec le comment le comment le comment
s'appelle Justin Time exactement c'est ça que je cherchais comme mot qui ne cesse de s'améliorer
entre les versions là le faire une transition pour un sujet qu'on a branché plus tard mais sur le
futur PHP 9 améliorerait encore plus les performances. Les futurs PHP 9 racontez-nous plus ça va
se téplez. Alors j'en sais pas forcément quand est-ce que ça va sortir déjà mais j'ai lu
des liens que je peux partager avec avec nos autres intervenants. Les nouveautés dans PHP 9 qui
continuent à faire le ménage dans les syntaxe ou les usages un peu curieux notamment le possibilité
de faire de l'incrémentation automatique, enfin auto-ethique magique de variables qui ne sont
absolument pas des variables de type numérique ou entière. De faire sur par exemple une string
qui contient à 9 faire faire un plus plus dessus et puis ça ça incrémente cette variable là
comme si c'était un nombre de façon un peu magique. Il y a un PHP 9 supprime ce genre de comportement
où on se demande déjà qui fait ça. J'imagine qu'il y en a qui doivent le faire. Pas d'offens.
Je n'ai jamais eu l'idée de faire ça personnellement en tout cas. Je dirais que le problème il n'est pas
juste que dans une variable en PHP tu peux facilement remplacer une variable qui était une string
par un entier ou vice versa et tu fais pas gaffe, tu as une fonction qui te renvoie à une chaîne
de caractère, tu fais plus dessus, rien ne plante et tu continues mais avec une variable qui ne veut
plus rien dire quoi. Je pense que c'est surtout ce genre de cas ou tu préfères que ça plante en fait
plutôt que d'avoir une interface bizarre ou une base de données corrompue ou ce genre de choses.
C'est vrai qu'on a du type HP partout mais on a aussi un peu d'auto casting un peu magique
à certains endroits où la frontière entre un entier et une chaîne de caractère n'est pas forcément
pas la conveyora hittochine quoi, c'est pas ultra figé. Ça peut être très pratique mais du coup ça
ouvre le biais à ce genre de choses un peu bizarre dans PHP où oui on peut incrementer une chaîne
de caractère avec autre chose que du numérique devant. Donc oui oui c'est sûr que PHP 9
en sorte que, non, type R, tu les gars, on ne fait pas d'incréments sur quelque chose qui n'est pas du numérique.
Oui, puis dans les autres petites nouveautés, enfin, c'est pareil, c'est une clarification sur tout ce qui a interpellation.
C'est-à-dire le fait de mettre au sein d'une chaîne de caractère une variable qui sera traduite dans la valeur de la variable,
avec visiblement des syntaxes divers qui existent encore et qui manquent de clarté, qui vont s'en rationaliser.
Aussi, il y a pas mal de choses pour faire rebondir ce que se disait Julien.
C'est sur le côté, on a envie que ça plante un moment donné et que ça nous arrête et qu'on se pense sur un sujet qui pose problème.
Certains avertissements dans PHP, jusqu'à présent, qui sont des avertissements,
dans PHP 9 deviendront carrément des erreurs qui entraîneront une interruption du code, qui demanderont d'être traités de la bonne manière.
C'est vrai que ça continue à aller dans un sens où on sécurise de plus en plus PHP.
Je trouve ça intéressant et c'est vrai que si on fait la comparaison avec les premières versions de PHP,
où on pouvait écrire un peu n'importe comment, de toute façon, ça nous disait rien, ça marchait,
c'est-à-dire sécurisé ou pas derrière, on s'en fichait un petit peu.
Là, le langage est déjà se réaligne avec les enjeux de sécurité qu'on a aujourd'hui
et surtout force l'utilisateur à adopter de meilleures pratiques dans son code.
Et ça, c'est super intéressant et ça fait profiter,
ça participe au fait de garder PHP vivant.
Et non, il n'est pas mort, effectivement.
Il n'a jamais été mort.
PHP est vivant, c'est bien, on retient PHP vivant.
Vu la quantité de PHP qui tourne aujourd'hui en prod,
c'est pas plus mal que les évolutions du langage avertent plus de sécurité
parce que ça fait partie aussi des...
Plus on réduit la surface-attaque d'une application, on mieux sait.
Et puis on sait que les applications web, dans le sens pas forcément API,
mais justement où tu vas avoir de l'interface, des tokens, des trucs comme ça,
en ce moment, elles sont fortement visées et c'est pas plus mal de réduire la surface-attaque.
Je crois que Rassholl disait que c'est le deuxième runtime le plus utilisé chez Clever.
Oui, mais nous, on ne fait pas démentir le reste de l'économie,
je vais les dire, mais de l'écosystème.
C'est un tir labour avec notre GS.
D'ailleurs, en parlant justement de ça, maintenant que PHP a un compositeur
et on a un questionnaire de dépendance qui est bremembiel,
est-ce qu'il y a les mêmes types de problèmes de attaques sur Playchain
que on a dans l'écosystème nod, en ce moment ?
Est-ce que ça vous a aussi impacté avec l'écosystème nod ?
Moins violemment, mais c'est déjà arrivé dans le passé.
Après, je pense que le trafic entre guillemets sur Package-GIS,
donc qui est l'équivalent d'NPM, en fait, que tu fais PHP,
il est certes très important.
On est toujours à centaines de millions d'installs par heure, par jour,
j'en sais rien, mais c'est très conséquent.
On entend moins parler de corruption de paquets, de vols de token
qui permettent d'insérer du mal vers des choses comme ça.
Mais j'ai souvenir qu'il y a quelques années,
on a des subis, un peu, des attaques par ce biais-là.
Mais après, la boîte qui est ce qu'on fait de compositeur,
donc le gestionnaire de paquets, de dépendance de PHP,
est développée par Package-GIS, donc en fait, il y a une boîte derrière.
Et cette boîte-là fait de gros efforts sur la sécurité,
justement, faire en sorte que n'importe qui ne puisse pas publier
n'importe quoi, sans être péjoratif, un peu le cas sur NPM,
où justement, GitHub commence à parler de sécuriser,
aider NPM à sécuriser sa sub-light chaine,
en réduisant la durée de vie des tokens qui permettent de publier,
en ajoutant en plus de trustee de publishers,
donc de l'organisation de comptes qui sont autorisés à publier,
en réduisant cette liste-là, ils augmentent le nombre de publishers
un peu sauvages, on va dire, entrelinés,
et en augmentant la liste des publishers de confiance,
ils se garantissent qu'eux ont accepté des outils de sécurité
en termes de GitHub ou de NPM plus avancés,
et donc ça sécurise la sub-light chaine de tout le monde.
Donc ça peut être intéressant.
Mais oui, c'est un peu comme sur tous les packages manager,
je ne sais pas si, côté Java, Scala, Rust, ça arrive aussi,
mais oui, de temps en temps.
Ça arrive aussi, mais voilà, c'était pas au point que pour NPM...
Oui, c'est ça, ça n'a pas l'ampleur de NPM, c'est ça.
Mais ça n'a pas l'ampleur des nombres de télé-sards-man
au cours d'une semaine que les packages NPM sont visés.
Mais c'est marrant, ça ouvre un sujet qui transverse
à tous ces gestionnaires de dépendance
qui sont clairement la columnme vertébrale
de pas mal de techno et de dépendance
de ce que nous, on fait quotidien en tant que développeur,
c'est qu'aujourd'hui, il y a une espèce de consortium
de gestionnaires de paquets,
de gestionnaires d'infrastructure comme ça,
on peut citer Mavin, PyP, Crate, Rust.
Packagesst en fait partie.
Toutes ces organisations,
on ne sait jamais trop comment les qualifier,
des fois, c'est des organismes open source,
des fois, c'est des boîtes comme Packagesst.
En fait, ils ont ouvert une lettre publique là récemment
pour expliquer que
toutes ça, ça repose sur des CDN,
ça repose sur du computing
parce que, bah, maintenant, il faut vérifier les signatures,
il faut faire tout ça.
Et donc, toutes ces intras là, en fait, elles ne sont pas gratuites.
Aujourd'hui, elles sont financées
par des bienfaiteurs, entre guillemets,
par des boîtes qui ont la conscience
que ça ne se pas gratuit,
et donc qui font des dons réguliers à ces organisations.
Et des fois, c'est juste la boîte derrière
qui a trouvé une espèce de business model
qui n'est pas forcément rentable à terme,
qui a des services,
Packagesst a un service privé
où, en fait, tu peux avoir ton propre registre,
ton repository privé.
Mais des fois, ça ne suffit pas forcément
pour financer toutes ces infrastructures,
et donc, oui, il y a une lettre ouverte
qui appelle à prendre conscience, en fait, de ça
et de faire en sorte que si vous utilisez
en tant que société, en tant que
organisation commerciale,
ce genre d'infrastructures pour faire du business,
ce sera intéressant d'évaluer
à quelle hauteur vous pourriez aider
et à financer, à supporter ce genre d'infrastructures
pour ne pas qu'un jour ça tombe,
parce que ça vous sert à créer
de la richesse, de la valeur pour tout le monde
et enfin, comprendre-soin.
On met à l'alien,
par la lettre, et on fait une phrase
« le prix de notre prix ».
Est-ce qu'on ne serait pas arrivé
à ce moment du podcast
où on fait une référence à XKCD ?
Oui !
Mais je ne l'ai pas...
Tu sais, la fameuse image
avec la petite petite qui tient tout le truc.
C'est ça.
Nous, c'est aussi une question
qu'on se pose sur comment
mettre plus de cash
devant tous ces trucs-là chez Claibor Claude,
parce que c'est déjà arrivé
qu'on se fasse avec limite
par certains services
de gestion de paquets, etc.
parce que
ils voyaient plein de requêtes
venir de nos IP,
mais en fait, c'était tous nos clients
qui venaient des mêmes IP, finalement.
Et ça fait beaucoup de trafic.
On revêchit
comment mettre du cash
enfin, pas forcément du proxy,
mais mettre en cash toutes ces dépendances.
Là où ça pose problème,
c'est que si on voulait faire un cash
à l'échelle de Claibor Claude,
ça veut dire que potentiellement
dans le cash arrivent des dépendances privées
et qu'on mettra à disposition
tout le monde et qu'on ne veut pas faire ça.
Et voilà, ça veut dire
faire un cash par client,
avoir la bonne infra aussi pour stocker
tous ces trucs-là.
Comment est-ce qu'on invalide le cash ?
C'est du boulot, on y travaille.
Mais oui, effectivement,
ça permettra de...
Si les infras dont tu parles,
Mathieu, sont disponibles,
parce que c'est déjà arrivé,
qu'il y ait des petits pannes,
on n'arrive plus à faire,
on ne sait pas trop pourquoi.
Visiblement, c'est un peu global.
Ce n'est pas juste Claibor qui s'est fait
« Right Limits ».
Et là, les clients nous vont voir en mode
« Qu'est-ce que vous avez fait ? Vous avez tout cassé,
mon projet déploie plus. »
Avec ce genre de fonctionnalité,
effectivement, on pourra...
Ça pourrait casser chez les autres,
mais pas chez Claibor.
Exactement, oui.
C'est sûr, mais c'est déjà arrivé.
Même nous, dans nos CIA,
on n'est des paquets qui ne s'installent pas,
soit parce qu'il n'y a pas 4Gz,
ou un T-Down qui touche un peu.
D'ailleurs, il y a GitHub,
c'est aussi pour ça qu'on parle de supply chain.
C'est qu'en fait, tu peux avoir ta CIA
qui va avoir un cache local,
mais sur cache local, il tape chez paquets de Giz,
celui-là, il tape chez GitHub.
Enfin, un GitHub ou autre, d'ailleurs,
on peut te lier des paquets
sur à peu près n'importe quel provider Git.
Mais c'est un vrai sujet,
c'est de se dire que ça paraît magique,
ça marche 99,4% du temps,
mais qu'est-ce qui se passe si vraiment
un jour ça tombe, parce qu'il faut de financement,
il faut de...
Il faut de maintenant, c'est en fait.
On s'habituer à que c'est des trucs qui sont là,
simplement.
En fait, moi, j'ai bien,
parce que quand je suis dans des cours
de Gensitudia maintenant,
je parle de l'écosystème,
par exemple,
au début, avant ma veine,
on allait chercher le bibliothèque
dans les sites web
de chacun des projets,
on récupérait la bibliothèque,
ensuite on allait chercher
les dépendances de chaque bibliothèque
et on passait peut-être de mière
pour mettre à jour
qu'on n'avait à peine indicé
de dépendance dans une appli,
aujourd'hui, n'importe quelle appli,
n'importe quelle langage,
on va se retrouver avec 15 centaines
ou plus cher centaines de dépendances
de ce que l'on fait à l'Oworld.
Tout ça, c'est de me mettre à jour
magiquement, en un moment où on construit
les projets et on a arrêté de réfléchir
qu'est-ce qu'il fait tenir
à une MPM registrée
à ma veine centrale
ou à Tébert.
Mais ça, à côté PHP, on s'en rend un petit peu plus compte
parce qu'on a un petit problème,
enfin un petit problème. On a un fait historique,
c'est que le modèle,
le fait d'avoir une fois de gêbes de PHP
fait que généralement, quand on l'installe,
il est configuré pour avoir un maximum
de mémoire utilisable de 68 ou 256 MHz.
Sauf que Composeur, quand il arrive à un moment
et qu'il doit résoudre un ordre de dépendance
avec 72 dépendances primaires,
il commence à râler un peu
et le mémoire limite arrive très vite.
Et c'est là qu'on se rend compte que, ah oui, c'est vrai,
c'est pas rien du tout de computer
ce genre de trucs et derrière,
on va aller télécharger la moitié d'internet.
On n'a pas au niveau de notre gêbes, mais...
C'est très drôle ce que tu dis parce que
qu'à l'année dernière, je mettais remis à PHP,
je l'avais découvert comme Composeur
et de tout compte,
et quand je l'ai découvert,
je me rendais compte qu'il fallait
une instance plutôt grosse
pour la partie construction
pour une toute petite instance
dans la partie exécution.
Et ça m'avait surpris
le fait de, ah oui,
la partie de construction est extrêmement gourmand
et après,
ça ronronnait avec une toute petite instance.
C'est ça, c'est parce que les Composeurs génèrent le point loc
et c'est comme le paquet, je finis de me dire,
en mode yes.
On encourage à pousser le point loc
pour éviter des comportements inattendus.
Et puis en plus de ça...
Et puis même le point loc de fixe des versions,
c'est sur toi.
Et en plus, à côté de ça,
si on a des dépendances
JavaScript à installer
pour générer des assets
pour le fonctionnement final,
effectivement,
ça peut être assez gourmand.
Comme beaucoup d'autres technos
qui sont très gourmand
à la construction.
Ceux que j'ai en tête
qui m'a traumatisé jusque-là,
récemment, c'est Calcom,
ce son de calendrier
qui est littéralement infâme
à buhild.
C'est pas du PHP,
sur du Node, TypeScript, etc.
Mais...
C'est vrai qu'avec PHP,
sa réputation passée,
on oublie qu'on a maintenant
cette phase de build,
même si on n'est pas un langage compilé,
il y a cette phase de build
où on va installer des dépendances.
Il y a tout un tas de trucs à faire.
Et généralement, il y a une petite PHP
qui va faire du web.
Donc on a généralement des dépendances JS.
Même si, côté Symfony,
on essaie de se passer de Node.js
et qu'on a des solutions
pour faire du JavaScript moderne
et des applications modernes
sans avoir de builder Node.js.
Je n'ai pas mis de lien là-dessus, d'ailleurs.
Je n'aurais peut-être dû.
On l'a dit tout à l'heure, après.
Mais c'est dit, si on va faire une transition
sur les builders Node.js,
c'est Sébastien qui a mis ce lien
peut-être sur bun.
Non, c'est moi qui l'a mis.
C'est toi qui l'a mis.
Parce que là, j'ai trouvé l'article
plutôt épatant.
On est en ban,
c'est un builder alternative
pour Node.
Et runtime aussi.
Et runtime également.
Il ne sait pas que le build...
Mais là, c'est surtout sur la partie build.
C'est un builder et runtime alternative
pour l'écosystème Node.
Mais un builder qui est surtout
extrêmement rapide.
Et quand il est dit extrêmement rapide,
ça veut dire
que 5, 6, 7 fois plus rapide
qu'un MPM classique
et
10 fois plus rapide que un djarn.
Et moi je trouve ça incroyable.
L'article
explique justement
comment ils sont réussi à le faire.
L'article
à profondivian
il t'explique
que dans une bonne partie
de problème c'est de system call
donc il t'explique
comment ils sont allés
à tous les endroits
en train de optimiser
et comment ils sont partis
d'un fait blanc
ils sont arrivés
à la partie
gestionnaire de paquet de ban
qui est simplement
incroyablement
rapide et pas très gourmand.
Donc l'article ça vaut
carrément la peine.
C'est extrêmement impressionnant, Bun.
En fait j'ai lu cet article.
Au début je pensais que Bun c'était juste
un
nouveau runtime
pour moi c'était le IoGS
de 2025.
Dans les fonctionnalités
de Bun il y a un support
de TypeScript natif.
Donc en fait tu le balance directement dans ton projet TypeScript
et
ça va fonctionner.
Après il le dit eux-mêmes
Bun
ne supporte pas 100%
des API de notre GS
donc il y a certains usages
je l'ai testé sur un projet qu'on a chez nous
et le truc à planter au bout d'une heure
j'avais prévu tout le monde
en mode fait un river si ça plante
sur l'infra de test
je l'ai pas mis en prod comme ça
j'étais curieux de voir
et effectivement ça va planter
mais moi je pensais que c'était
juste effectivement un runtime alternatif
et après avoir lu l'article, j'ai testé
sur le fameux projet dont je parlais
et j'ai vidé tous mes cache
NPM, Node, Bun, Yarn
tout ce que vous voulez
j'ai fait un NPM install donc à vide
il y avait déjà un point lock
par contre mais bref
ça a mis 7 secondes
à récupérer les dépendances
et à construire le projet
j'ai tout revidé, j'ai lancé Bun
0,5 secondes
genre
les téléchargements des dépendances
je suis pas sur un projet avec 50
dépendances et énormément de doutils
mais quand même le téléchargement des dépendances
le
un tard des dépendances
etc
la génération du bun.lock
tout ça, 1,5 secondes
c'était fini avant que je suis le temps de
c'était impressionnant
j'invite vraiment tout le monde
à tester ça, je vais juste remplacer
NPM install par bun install
c'est bluffant
moi j'avais eu la mouche
mais je ne sais pas si
les articles vont être en train de lire
et les gens vont juste plus sur le projet
et les prescribes, ils me disent
je ne sais pas si ils vont installer
ils doivent faire le cas de NPM
parce que c'est trop rapide
ils vont faire le cas et ils vont dire
je ne sais pas
donc je suis très curieux
voilà c'est surtout
très bien écrit l'article
que je vous explique
il y a beaucoup de choses
qui se sont publiées
c'est autre, on avait quelque part
l'avantage de commencer de 0
on a fait un truc brement optimisé
donc comme article d'anjenerie
c'est super sympathique
c'est bien de voir ses plus performants
c'est bien de comprendre les styles pourquoi c'est intéressant
mais ce que ce n'est pas
surtout parce que la façon dont ça a été écrit
bun, enfin NPM
c'est écrit en javascript
et bun c'est écrit dans
autre chose
on peut s'imaginer que
c'est écrit en zig
c'est une des raisons
qui donnent dans l'article
c'est écrit en zig
ils expliquent pourquoi
pour le cas d'usage
de NPM
la
la vm
javascript
de node
pourquoi est ralenti
le process
parce qu'il y a une event loop
qui faut gérer
tu ne fais
pas vraiment de l'apparalisation
mais pas si bien
que si tu étais en direct
avant de pouvoir faire des appels
aio en fait des transformations
utf 16 utf 8
un petit peu partout
dans un sens puis dans l'autre
et un certain nombre d'appels
pour un appel
c'est juste un appel d'aio
ça va en faire 4-5 des syscalls
de suite
parce que c'est comme ça que node a implementé
cet appel pour te donner
une interface un peu jolie
donc le fait d'être dans un langage
plus proche de la machine
leur a permis de diviser
par je ne sais plus combien le nombre
d'appels
de syscalls
pour aller chercher du disque
pour aller chercher du réseau
et ça parallélise aussi beaucoup mieux
parce qu'effectivement
la parallélisation dans Node.js
en fait ça fonctionne
sur l'Event Loops
qui fait avancer les sujets
les uns et les autres
en tournant en permanence
et quand il a fini de gérer les sujets
il revient au premier
et donc la parallélisation
est moins efficace
d'où le fait
que c'est d'une certaine manière
mono se raider node
même si ce n'est pas vraiment vrai
et que avoir plein
plein de CPU
ce n'est pas forcément utile
enfin c'est des sujets qu'après qu'on retrouve
chez les clients
ils ne comprennent pas pourquoi
ils en mettent une très grosse machine virtuelle
avec beaucoup de coeurs
ils ont toujours des problèmes
alors qu'en mettant plus de machines
mais plus petites
ils ont moins et enfin ils ont plus de performance
et ça les étonne beaucoup souvent
mais on revient
node
et exactement
ça en fait éco
à cette histoire de performance
entre NPM et BUN
Nickel
on va continuer parce qu'on a plein d'autres lianes
Julien, qu'est-ce que tu avais toi
comme liane
tout à l'heure
eh bien
comme ça fait longtemps que quand t'en mangueule
parce que j'ai toujours pas refait d'épisodes sur le carnel
je me suis dit que je l'ai mette quand même quelques petites news
il y a deux trois trucs qui ont été
opensource
qui ne sont pas encore forcément dans le
le repo officiel du kernel
mais qui peuvent être
enfin voilà, qui sont des pages qu'on peut appliquer
si on refait un build en local
il y a
des gens qui bossent
une boîte qui s'appelle littéralement
multicarnel
qui travaillent sur le fait de pouvoir
faire tourner plusieurs kernels en parallèle
dans le même système
le kernel au parallèle dans le même système
exactement, c'est-à-dire
la news c'est qu'ils viennent d'open source
leurs patchs
enfin leurs noyaux linux
sur lequel ils ont travaillé
dans cette boîte là
donc ce qui a suscité beaucoup de discussions
parce que des gens qui disent
ok c'est sympa pour faire un petit poke
mais on n'est pas encore prêts
d'avoir quelque chose de vraiment pro de
etc.
mais le logic c'est de se dire
on va essayer de faire tourner
justement plusieurs kernels en parallèle
en fait
il y a un kernel
et ensuite tu peux relancer plusieurs
mais
d'après les benches
qu'ils ont fait et qu'ils annoncent
ça permet de rajouter quand même
de la sécurité
sur tes accès
parce que chaque kernel va avoir
potentiellement un CPU sur un bout de la rame
tout en s'évitant d'avoir un hyper-viseur
entre ton système
et l'autre kernel que tu fais tourner
donc ça permet d'éviter d'avoir
à transformer des appels AIO
ou des appels de mémoire
d'éviter le CPU etc.
tout le temps
tout en gardant une sécurité
une isolation qui permet un peu
de renseigner
et de ne pas s'accuriser
et ils aimeraient aussi
en rendre encore plus facile
le fait de pouvoir changer à chaud
un noyau
sans avoir à redémarrer le serveur
ce qui est un gros sujet
parce qu'en fait
si tu as une faille
quelque part dans ton noyau
ou une faille de ton CPU
ou tu as besoin de la corriger
en mettant à jour ton kernel
tu es obligé de redémarrer tes serveurs
de suivre, d'abord viser le serveur
ou faire une plage de maintenance
quand t'es un cloud provider
c'est pas simple
de faire ça
et donc c'est le genre d'opportunité
que ça pourrait permettre
il y a déjà des travaux sur le fait
de pouvoir changer de noyau à chaud
mais apparemment ça c'est une approche
qui pourrait être aussi intéressante
wow
du coup ça permettrait du code
userland de décider
quel kernel il avait
ou ouais
l'idée est que tu pourrais lancer du code avec son kernel
ce qui pourrait répondre aussi
ça il ne le dis pas dans les articles élus
mais une des choses qu'on reproche
à Docker
c'est que tu te retrouves avec du code
qui tourne dans un
file système
qui contient
une glipser ou musul
musul etc
donc à une implémentation de la lipser
qui n'est pas forcément compatible
avec celle qui tourne
sur l'autre
et qui n'est pas non plus potentiellement compatible
avec le noyau qui tourne sur l'autre
alors effectivement les plantages liés à ça
sont rares mais
ça existe quand même d'avoir une incompatibilité
entre les deux et d'avoir des problèmes
pour s'en dépattouiller c'est quand même un peu compliqué
et donc potentiellement lancer
et puis
les gens parfois considèrent
que lancer des applications dans un container
ça va améliorer la sécurité de les applications
ce qui n'est pas vraiment vrai
potentiellement
on pourrait améliorer
l'application
enfin le... pardon
on pourrait améliorer le
le lancement de conteneurs
en lançant carrément un noyau
derrière un poil plus lent à lancer
que ton conteneur Docker
mais potentiellement plus rapide
à lancer que un hypervisor
qui lance l'avm
avec un full Linux dedans
tu lancerais quand même plus ou moins un full Linux
parce que en fait tu lances ton OS
mais
tu t'évites quand même certaines surcouches
d'accès
et a priori les différents carnails
auraient tous accès à un peu de la même façon
un petit peu
un petit peu tout
alors que souvent quand tu fais de
quand tu fais de la machine virtuelle
tu vas avoir plutôt tendance à dire
soit tu virtuélises le matériel
soit tu vas dire ce matériel là
il est lié à cette machine virtuelle là
et plus personne peut y toucher
potentiellement pour des gens
qui auraient besoin de GPU
c'est un peu à la mode en ce moment
c'est un peu compliqué de virtualiser
les GPUs
de partager des GPU entre machine virtuelle
c'est pas si simple
et ça pourrait peut-être être une réponse
à ça
donc là ça a été open sourcé
le 21 septembre donc
il y a quand même un carnel
qui est
entre guillemets maître
a priori il y a quand même un
carnel qui est en dessous
mais l'idée c'est de laisser
un accès quasiment direct au hardware
c'est ça
donc si on fait des insyscoles
au carnel un des carnelles alternatifs
il n'a pas besoin d'aller
répercuter ça sans le carnel
maître
de ce que j'en ai compris effectivement
ok
mais par rapport à un docker
où les gens souvent s'interessent
c'est pouvoir utiliser
une stack
liée à une distribution Linux particulière
comment tu retrouves
ce genre de
comment on imagine retrouver
ce genre de comportement
ce que j'ai un carnel c'est bien
mais souvent, au-delà de ça il y a tout le userland
en fait tu peux combiner les deux
de ce que j'en comprend
tu peux combiner les deux
dans le sens où
tu peux avoir ton carnel
et lancer un
un conteneur
direct
ce qu'on appelle un conteneur en fait c'est
un processus que tu lances
dans un C-group
dans un environnement un peu limité
dans un
quelque part dans ton phatistème
pas au route de ton phatistème
et avec des accès CPU RAM
que tu peux limiter
et le process
est dans son propre route
enfin c'est un route un petit peu améliorée
plus sécurisée pour faire simple
donc tu pourrais garder un peu ce fonctionnement là
mais lancer carrément toute
ta stack de
ton système d'exploitation
avec un carnel qui lancerait
un processus
mais avec un carnel potentiellement compatible
avec le système
qui vient derrière
oui c'est ça
voir un carnel avec peut-être
beaucoup moins de modules compilés
enfin si tu penses sécurité
tu pourrais aussi avoir un
noyau
qui n'a que les choses qui t'intéressent
alors que celui du système en tout
qui gère peut-être plus de choses
tu pourrais lui activer plus de
fonctionnalité
et donc pour le moment
la partie open source est
testable ça permet d'être décevée
c'est plutôt une preuve de concept
et de radéon arrive à
faire
tu peux quand même faire
des choses avec
je n'ai pas testé
je vous avoue
mais en fait oui il y a une boîte
qui bosse dessus et qui s'est dit
bah là on est arrivé sur
quelque chose de pas trop mal
et on est capable
de
on est capable maintenant de redonner
à la communauté
et d'avancer ensemble
c'est cool
qui hâte de voir qui t'a fait donner
tu n'as pas encore installé ça
sur ton ordinateur pour pouvoir
travailler
non mais j'hésiter
peut-être ce week end
je vais cloner
et je vais prendre leur noyau
c'est le compiler et voir ce que ça donne
et voir comment ça marche aussi
parce que je ne vous j'ai pas encore trop testé
bah c'est un truc qui a
fait de la vie de croiser un peu
alors va continuer
et nous restons encore de Lian
Sebastiaan et un autre Lian a nous proposé
dans les grands sujets
qu'on a chez Cleverclas
donc on parle souvent de pulsar
et voilà c'est pour ça
je n'ai pas encore un grand élément mais
j'ai commencé à regarder un peu
comment faire fonctionner et si on vient sur PHP
faire fonctionner pulsar et PHP ensemble
c'est vrai que c'est pas forcément
le protocole que l'on pense
sachant que la libre n'est pas forcément
non plus un client officiel
mais a priori
qui fonctionne quand même bien
c'est un client native PHP
qui fonctionne bien avec pulsar
sans devoir passer par la payrest
ou les websockets exposés sur pulsar
donc ça fait partie des choses que je
que j'ai commencé à gratter
pour pouvoir faire un peu plus de
paralysation de tâches
dans des workers diverses et variés
plutôt que d'utiliser les traditionnels
redis ou habitemkiu
qui sont souvent dégainés
régulièrement
et je crois que Mathieu
toi tu voulais parler
plutôt kafka dans la série
qui se rapproche
dans l'ecosystem symphonie
en fait on a un composant
dans symphonie que s'appelle messenger
qui est une couche
d'abstraction en fait
de toute cette
vaste universe
d'asynchronés donc on est capable de causer
on a le driver pour redis
on a le driver pour habitemkiu
pour SQS, enfin on a même le driver MQP
donc en fait n'importe quoi qui respecte
le contre-record MQP on peut causer avec
et il y a longtemps
qu'on a une poulre request
ouverte sur kafka
il y a longtemps que je n'ai pas vérifié dans quel étail
ça m'étonnerait qu'elle soit mergée je l'aurais vu
mais il y a longtemps que ça s'est en cours
et c'est vrai que personne
pour l'instant s'est trop penché
sur le sujet de pulsar
je n'ai pas l'air vérifier récemment
sur le dépôt symphonie mais je crois pas avoir vu
de gens même dans les issues
discuter du support de pulsar
mais c'est vrai que ça pourrait être intéressant
mais je pense que ce n'est pas grand chose en pulsar
c'est pas la techno pour dégain
le plus souvent
après l'intérêt
probablement Julien pourra en parler
mieux que moi sur les intérêts profonds
depuis le sard
mais on a
une meilleure distribution
des
c'est un système
mieux distribué
des outils
qui sont de fin
plus complets
qui rendent de fin
c'est pas très clair ce que j'entends raconter
mais qui permet d'avoir de l'utilisation
plus poussée du concept
d'évents
de messages
dans une queue
déjà pour
peut-être qu'on peut expliquer aux gens
ce que c'est que pulsar, Kafka etc
si il y a des gens qui écoutent le podcast depuis 4 ans
je pense qu'ils ont déjà dû en entendre parler
mais j'espère qu'on a toujours
des nouveaux auditeurs
pulsar, kavka, rabit mq
tout ça c'est des technologies
qui fonctionnent pas tout exactement
pareil mais dont le but
est de pouvoir
faire transiter des messages
dans ce qu'on appelle un message broker
en anglais
c'est à dire qu'il y a des gens qui vont
envoyer de la donner
sur le serveur
ou sur le cluster en général
rabit mq
à mqp
kavka ou sur pulsar
et ensuite on a des consommateurs
qui vont aller lire les messages
avec tout un tas de systèmes
quand on voit un message
ou quand tu lis un message
tu peux t'assurer qu'un groupe
de consommateurs
puisse ne dire un message qu'une seule fois
donc s'il y en a 5 consommateurs
qui lisent les mêmes
en général on a des queues, des topiques
il y a différents noms en fonction de la technologie
mais quand les messages arrivent
ils sont dans une queue de traitement
et en fonction de la technologie
et en fonction des options que tu peux mettre
tu peux dire bah là mes 5 services qui tournent
en fait c'est 5 fois le même service
et j'ai juste envie quand un message arrive
il soit lu par un des 5 services
et pas par les 5 en même temps
et donc il y a des mécanismes dans toutes ces technologies
là qui permettent de faire ça
ou tu peux pouvoir dire
quand un message arrive je veux que tout le monde le lisent
parce que tu as envie d'informer les gens d'un événement qui vient d'arriver
donc on peut faire pas mal de choses
l'avantage d'utiliser
enfin on pourrait se dire
on pourrait envoyer les messages en HTTP
sur chacun des services c'est prêt
l'avantage d'utiliser des outils
un peu comme
comme RabbitMQ
comme Kafka, comme Pulsar
on cite les 3 parce qu'en fait c'est 3
protocoles différents
c'est que
en général tu peux essayer de stocker
un peu les messages en attendant qu'ils soient lu
c'est à dire que quand tu fais ton appel à HTTP
s'il n'y a rien qui répond en face
ton appel est juste perdu et toi t'es censé
quelque part dans ton client
garder le message pour le renvoyer plus tard
j'aurai une stratégie de retry
voilà, avoir du retry
et en fait c'est du boulot
qui n'est pas si simple que ça
et en fait les différentes technologies dont on parle
te permettent d'envoyer le message
en général on s'assure que ceux que l'hosteur
lui tienne de plus souvent possible
et ensuite
le service qui est censé
lire le message que t'as envoyé
il le lira plus tard quand il sera à nouveau disponible
ou quand il aura fini de traiter
les autres tâches
et pourquoi c'est important ?
parce que c'est un pièce de base
dans la plupart des systèmes distribués
parce que tu as toujours le même problème
tu as
de différentes personnes qui doivent
faire des machines qui ont besoin d'être prévenus
de fois il ne peut pas être là
de fois il peut avoir de la tasse réseau
et donc dans la plupart des systèmes distribués
il y a ce type de technos
d'informations d'une autre
pour garantir à un moment donné
que les différents composants
peuvent avoir cette information
mais dans l'écosystème PHP
on s'en sert beaucoup
parce que je vais revenir encore une fois sur le truc
on a ce Fire & Forget
qui est un peu historique
et on ne veut pas bloquer la réponse
HTTP au client, au browser
on veut répondre le plus vite possible pour être
performant efficace et donc j'ai un lance
qui est couramment en ressources et en temps
on le déporte sur du traitement synchrone
avec ce genre de mécanisme
avec un worker qui vient lui déplier
et en fait le principe de base
c'est de se dire on a quelque chose
de long à traiter
ça peut être resize d'image
ça peut être un appel ALLM
qui prend x au seconde
et ce truc là on ne veut pas qu'il bloque la requête
HTTP que l'utilisateur vient d'envoyer
donc on va déporter ça dans un autre process PHP
qui lui va écouter à travers ce message
worker
on lui demande d'exécuter quelque chose
et ça pop sur un autre process PHP
j'ai une métaphore
je voulais préposer une métaphore
que j'utilise souvent pour expliquer
pardon
pour expliquer le concept
pour ceux qui n'auraient pas encore
saisis l'essence du truc
c'est vraiment
si vous êtes dans un restaurant
on a les serveurs qui sont à l'étage
et la cuisine qui est en bas
ils envoient les commandes dans un tuyau
et à l'autre bout
ils viennent récupérer au fur et à mesure
les commandes
il y a différents cuisiers
qui viennent récupérer une commande
pour pouvoir les exécuter
et ensuite les envoyer
aux clients
il faut imaginer que sans ça
ce serait le serveur qui enverrait
sa commande à la tête
d'un cuisinier et si il n'y a pas de cuisine en face
ça tombe par terre et puis c'est perdu
ça c'est un peu le côté HTTP
c'est la personne qui répond
le personne ne se penchera pour ramasser la requête
c'est perdu, c'est tombé par terre
alors que si c'est dans le tuyau
ça reste, si il n'y a personne pour la récupérer
à l'instant T, c'est pas grave
elle est dans le tuyau, il n'y aura plus qu'à venir
la récupérer quand il y aura quelqu'un
disponible
et puis surtout
la possibilité
si on les laisse dans le tuyau
pendant tout le service
de pouvoir remonter dans les commandes
ce qui nous permet à la fin peut-être
par exemple le serveur
qui va s'occuper de facturer
de récupérer toutes les commandes
qu'ont été faites
par le client
pour lui ensuite lui envoyer la note finale
ce qui peut être pratique
donc le côté un peu persistance
le côté de je prends quand je suis
disponible pour traiter la demande
et pas devoir
récupérer et réceptionner l'avion au papier
que m'envoient le serveur là-haut
si il n'y a personne, il tombe par terre
et puis il va tempir en le pied de signe
et plus personne ne s'en occupe
la métaphore utilise souvent
si ça peut aider certaines personnes
il est bien
maintenant il y a un client
pour Pulsar en PHP
nous on aime bien Pulsar
en tout cas à l'époque où on a décidé
de partir sur Pulsar
il y avait deux trois limitations qu'on voyait à Kafka
et Pulsar avait l'air d'être plutôt un bon cheval
en termes de stockage
on aime bien avoir un topic
c'est là où il y a les messages qui arrivent
et qui sont lus
il y a
du réglage de la rétention
dans Kafka, dans Pulsar
un peu dans RebitMQ
et l'architecture de Pulsar
faisait qu'on trouvait que c'était mieux
en termes de stockage
des topics
pour en fait ne jamais rien perdre
de ce qui est mis dans un topic
tout en gardant ce fonctionnement de pouvoir s'inscrire etc
je ne sais pas à quel point Kafka est capable de le faire
mais en tout cas
à une époque
ça le faisait moins bien
et c'est pour ça qu'on a choisi Pulsar
mais je sais que Pulsar peut
on l'utilise d'ailleurs
aller offloader dans un S3 like
les contenus des topics
en fait quand tu as des messages
qui sont plus vieux qu'un mois
et tu sais qu'en fait il n'y aura jamais les chercher
pour faire de la production
tu verras les chercher pour faire de la dynamite
pour rejouer des vieux trucs, retrouver des infos
en fait ils vont être stockés au format
je ne sais pas quoi parquet
un truc comme ça dans S3
et tu pourras aller
via Pulsar, il ira relire
les fichiers dans le S3
au moment
où tu en auras besoin
ça sera plus lent
forcément le moment où tu iras chercher les 3 derniers mois
de messages
forcément tu vas perdre un petit peu de temps
mais en attendant dans le cluster Pulsar lui-même
tu vas avoir juste le dernier mois de messages
ce qui lui permet d'être plus efficace
là-dessus
on n'est pas forcément là pour faire de la pub de Pulsar
mais...
je sais que Mathieu
et pour rebondir
par rapport à tous ces protocoles qui existent
dans les projets chez Clever Cloud
ça va être aussi d'exposer
des connecteurs dans les sortes de procs
qu'on place devant Pulsar
qui sont capables de causer dans le protocole
AMQP, dans le protocole Kafia
dans le protocole MQTT
parce que Pulsar est posé à Y-10
nativement
en Pulsar et c'est basé sur
quelque chose de...
non c'est leur proto, c'est comme Kafka
enfin c'est comme Kafka mais c'est pas Kafka
d'accord, c'est passé pas du proto-buff
ou quelque chose comme ça
non non, le protobuff
c'est un format
pour le message et tu peux
en plus, tu peux mettre
ce que tu veux
un tableau de byte
qui peut être encodé en proto-buff
qui peut être encodé en JSON
en... comment ça s'appelle en Abro
si tu veux
et il y a un système
Pulsar est capable de comprendre
si tu lui dis les différents formats
et tu peux
mettre sur un topique un schéma
et Pulsar va refuser des messages
si ils sont pas dans le bon schéma
on l'utilise assez peu parce que c'est très casse-gule
je suis bâti
c'est pas trop la responsabilité du broker
généralement de...
au début on trouvait ça cool
et en fait le moment où tu dois changer
le schéma de ton topique, laisse tomber
c'est un peu le problème de la migration
de base de données mais à échelle
où tu as 0,2 secondes
de fenêtre de faire ta migration
exactement, donc en fait
finalement on n'utilise pas, on déclare tout en red byte
et puis on essaie de versionner nos schémas
pour que de chaque côté ça soit capable
de relire
et on va même préférer parfois
se dire si on passe
d'un format V2, un format V3
pour je sais pas les access logs
par exemple on est en train de bosser dessus chez les crêveurs
peut-être qu'on aura un autre topique
où on saura que dans ce topique là
c'est du V3
versus le topique d'avant
où on était en V2
et voilà
mais pour terminer
surtout ces protocoles
de MQ on va dire
l'intérêt
c'est de avoir
une seule technologie en back end
qui est pulsar et d'exploser des procs
qui discutent dans le protocole
qui t'intéresse
pour simplifier derrière
pour éviter d'avoir
X Cluster, Rabbit MQ
X Cluster Kavka
et tout sur un pulsar
Cluster Pulsar, plusieurs Cluster Pulsar
enfin, importe
et ben, matéria MQ
exactement, c'est dans votre tournouiste
mais on n'a même pas besoin
de le dire maintenant
maintenant c'est une sabité qui existe
exactement
tout ça dans un
ce qu'on appelle, pour rejeter dans la grande case
du topique à ce service
tu veux du topique, du message que vous venez
et tu consommes
tu as un token
c'est ça, tu as un token
tu as un protocole, ok vas-y
et si t'es pauvre et que tu veux pas te prendre la tête
redis un système de Q
qui est beaucoup utilisé dans PHP d'ailleurs
Pg, Pg est un système de Q qui marche très bien
Pg est aussi un système de Q
donc en fait, tu peux réutiliser ta redis
que tu utilises pour tes sessions PHP
pour mettre tes Qs dedans
et pareil pour ta pose risquuelle
il y a
t'es pas obligé de dégainer
le Kavka, le pulsar, qui sont effectivement bien pour
quand t'as des grosses usages
c'est ça, et que t'as des besoins vraiment
de distribution, de...
des systèmes distribués, sinon il y a des solutions
pour des petites applications
ça peut être très vite ouvert qu'il
c'est ça
bon bah je pense que
on est pas bar quand même
ça fait un même minère qu'on discute
on va finir ici cet épisode
mais avant, comme d'habitude, il va falloir
qu'un de vous me donne
une musique de fan, allez, qui va se lancer
qui a quelque chose, en ce moment
toute la journée dans les casques
qui est obsédée par une musique
qui invite de nous faire partailler
comme Mathieu est l'invité, on va laisser choisir
la musique de ce prix
j'en ai plusieurs, ça dépend
de ce que je fais de mes journées
soit ça va être dans le train
soit ça va être en codant
et j'ai acheté un lien
Horacio
c'est un groupe que j'ai vu en live il y a pas longtemps
d'ailleurs
du côté de chez moi, du côté de Njör
c'est Mojt, c'est un groupe allemand
donc c'est une fanfare
en fait, donc c'est des cuivres
des percudes, des choses comme ça
et ils ont la particularité
de faire un peu l'inverse
des groupes électro qui reprennent du classique
et ils font l'inverse, ils reprennent des tubes électro
en fanfare
ça doit être assez incroyable
et ils descendent dans la fausse
faire des morceaux avec le public
parce qu'ils n'ont que des instruments partables
en fait comme une fanfare
et c'est vraiment excellent, donc ils ont fait des lives
à Paris, à Coachella, donc là il y a un live
à Coachella où ça reprend, you and me de disclosures
et vraiment c'est assez bluffant
c'est grave, ma cam, mais je pense que mon épouse va te détester
elle adore et elle connaissait pas
et je le fais découvrir parce qu'elle est percussionniste
et vraiment elle a adoré
en passant un super concert
je connais pas, je vais écouter, ça a l'air très sympa
merci pour cette gestion de fan
et merci à vous trois pour être là
pour cet épisode
et surtout merci à tous les personnes qui nous écoutent
bonne journée à tous les monde
merci, salut, bonne journée