Bonjour à tous, bienvenue sur ce nouvel épisode de Double Slash, un épisode spécial, on
va changer un petit peu de ce qu'on fait d'habitude, mais avant de commencer on va
déjà dire bonjour à Alex, salut Alex, on s'en va ? Salut Patrick, salut tout le monde.
Et nous avons évidemment un invité pour parler d'une techno qu'on ne maîtrise pas
forcément, donc c'est Ludovic qui est avec nous aujourd'hui de Laravelle, je te su. C'est
comme ça qu'on dit ? C'est ça tout à fait, bonjour.
Bienvenue et merci d'avoir accepté la invitation pour ce podcast. Donc comme je disais au début,
en fait on a tendance à parler beaucoup de techno front, on nous qualifie même de podcast front,
même si on parle de base de données, on est assez ouvert. Puis on s'est dit que ce serait pas mal de
parler un petit peu de Laravelle qui est un framework un peu plus monolithique, on va dire,
mais ça on va en parler durant l'épisode. Et puis on va commencer par toi Lido, tu vas te
présenter ton background, ce que tu fais dans la vie, tout ça. Allez, bonjour à tous, moi c'est
Ludovic, j'ai créé la chaîne Laravelle Jutsu pour partager un peu ce que j'apprenais au fil
du temps sur le framework Laravelle pour lequel j'ai eu une certaine affinité au début.
Cette chaîne là elle m'a surtout servi de vitrine en fait. Au début c'était pas
l'objectif de professionnaliser les choses, d'en faire mon métier. J'y allais un peu à
tâton, je trouvais que c'était cool. Puis à un moment donné je me suis dit ça a l'air de prendre,
ça peut me faire ma vitrine, c'est on jamais pour une entreprise et c'est ce qui s'est passé.
J'ai fini par être recruté ce qui fait qu'aujourd'hui je travaille pour une agence web
épecta et globalement je fais partie des autodidactes, des nombreux autodidactes qui ont
appris sans avoir passé par la case école, la case diplôme. En plus j'irai regarder un petit peu
tes vidéos sur ta chaîne, ça fait un petit moment quand même que tu fais la chaîne. J'ai vu
il y a des vidéos qui datent de 4 ans presque. C'est ça, ça fait à peu près 4 ans à ce moment là,
on va pas se mentir, c'était juste un peu pour m'amuser, je faisais que c'était un petit peu
du copier-coller de ce que je voyais, de ce que j'entendais, ça m'amusait plus. À ce moment là,
je n'aurais pas pu, ce que je faisais en vidéo, je n'aurais peut-être pas pu le faire comme ça
ou le réadapter de façon professionnelle, ce qui est plutôt le cas depuis une bonne année où
j'ai décidé de reprendre les bases sur PHP et l'APO et pour mieux embrasser le framework en fait.
D'accord, enfin en tout cas les vidéos, enfin les dernières que j'ai vues sont de bonnes qualités
en tout cas, assez technétiques. On y va, on commence par déjà on va présenter la ravelle,
en fait, qu'est-ce que c'est la ravelle, comment on peut le présenter à quelqu'un qui ne connaît
pas la ravelle ? Alors la ravelle, c'est un framework PHP qui a été créé par Taylor O'Twell,
il a plutôt actif sur les réseaux sociaux, si on jette un petit coup d'œil au comite, il a
en très très grande partie créé le framework entièrement et sur ces dernières années,
la tendance, si on check un peu les comites, c'est marrant parce qu'il a tendance un peu à déléguer
Dries Vint qui lui aussi est plutôt actif mais bon globalement c'est quand même lui qui a posé
les bases. Ce framework PHP, il a sorti en en fait il a sorti en juin 2011 donc peut-être qu'on
n'est pas si loin de la date anniversaire, je ne sais pas mais en tout cas il y a eu un atter
en fait assez direct, assez monumental. Ce qui a fait qu'il a gagné en popularité c'est que
c'est peut-être aussi un peu son défaut, il est là pour proposer une certaine richesse de
fonctionnalité, on peut retrouver ça sur la homepage, en gros on va vous dire on vous donne le framework
donc le cadre et ciel, l'ensemble de librairie, tout ce qu'il faut avec le système de montage etc
et en gros vous vous focus, le développeur il se focus sur la logique métier, il se focus sur là où
les fonctionnalités implementées et en vrai il y a toujours un truc, il y a toujours un package
lié à la ravelle qu'on peut installer, la ravelle lui-même vient avec énormément de choses qui vont
bien en gros ça va vous économiser du temps, des larmes et c'est vraiment ce côté pratique
et ça ça a beaucoup plu, après nous en France on est plutôt une terre de symphonie donc ça a
moins pris, en revanche ce qui est rigolo c'est que comme j'ai été recruté par Epecta qui est
une entreprise belge, ça s'explique en fait que ce soit la Belgique et finalement pas une entreprise
française qui m'a recruté parce qu'en fait il y a une usine un package de la ravelle qui est
implementée en Belgique donc l'influence elle est quand même forte dans ce pays donc forcément
on se rejoint sur les stacks et les techno dans les entreprises. Tu penses qu'en France
aujourd'hui on est toujours plus proche de symphonie que de la ravelle en fait ? Globalement de ce que je
vois sur les réseaux sociaux parce que moi je fais partie de la communauté la ravelle donc les
retours, les tweets, les news, tout ce que je vois c'est 100% anglais américain ou hors de France
c'est vrai que les développeurs français symphonies, les symphonistes ils ont, non, ils
peuvent apprécier le framework mais leur allégance elle va la plupart du temps symphonie et ça va
jamais, je parle un peu, c'est pas la guerre mais c'est un registre militaire mais symphonie qui
a un excellent framework absolument mais pour des raisons voilà ils sont avec symphonie et ils
vont pas forcément adhérer le fait d'avoir cette boîte à outils magiques qui est la ravelle,
ça peut se comprendre, ça peut aussi apporter des défauts mais globalement voilà.
Et tu parles tout à l'heure, deux secondes Patrick mais tu parles tout à l'heure, il y a deux
contributeurs qui sont hyper actifs néanmoins comment se organise la gouvernance sur les choix
qui ont été fait ? Est-ce qu'aujourd'hui là on peut en tant que contributeurs faire aussi évoluer
le framework vers un autre paradigme même si il est en place donc je pense que c'est dur de bouger
les lignes mais comment se organise la, on va dire la décision quoi, la gouvernance ?
De rester sur le, par exemple de changer l'architecture logicielle du framework ou de
simplement faire des comites ? Les deux. Alors pour les comites il y a globalement il y a deux
choses déjà tout le monde peut bien sûr essayer de faire sa petite pour le request, ça y a pas
de problème, ça va être passé au crible par Taylor Otwell, par Dreyse Vint, par tous ceux qui sont
qui vont essayer de garder, j'allais dire, de rester dans le cadre, de rester dans le la ravelle
ça après ça va à privirie pas pas changer, je pense pas, on va pas changer d'architecture,
le la ravelleway ça restera le la ravelleway, on reste sur du MVC, si on a envie et bien sûr
il y a, c'est avec, c'est volontiers que les développeurs la ravelle et l'installent, il y a
plein de packages pour pouvoir céder dans une autre architecture comme DDD, mais ça va rester
après on peut aussi faire des comites sur la doc, donc on est aussi libre d'en faire,
si on voit une petite bourde ou qu'on a envie d'ajouter son exemple, on peut le faire aussi,
pareil ça sera toujours passé au crible, en général par Taylor Otwell ça reste quand même
son sacréation, mais on reste sur du la ravelleway dans tous les cas, ce qui va plutôt être ajouté,
c'est quand on arrive à vraiment à quand on fait une proposition assez innovante qui reste dans
dans la veine du framework, mais vraiment qu'il y a un espèce de, quand même il y a un consensus
entre tous les gros bonnets de la ravelle qui disent ça, ça peut être cool pour aider les
développeurs, parce qu'à la base c'est vraiment, l'objectif c'est ça c'est de fournir, de fournir
des classes, des façades, des choses pour se simplifier la vie, alors après ça peut être
un peu son défaut, parce que ça peut un peu pécher au niveau de la personnalisation,
si on a vraiment envie de faire des choses plus vraiment customes en profondeur, mais ça c'est
la veine du framework. Ça rejoint un peu l'esprit de Rubien Rels où en fait le concept c'est vraiment
convention, over configuration, c'est à dire tu respectes toutes les règles qu'on t'a donnée et
tu gagnes un temps de m'aboul et t'évites de recoder la roue, et enfin moi ce que je perçois
je suis pas du tout dans l'univers PHP, je suis pas du tout dans l'univers la ravelle, par contre
ce que j'ai été longtemps rubiste et puis après je suis passé du côté dark de la force en faisant
du JS, du type script et tout ça, mais aujourd'hui je me retrouve en fait un peu la simple cité et
le truc vraiment mais straightforward sur l'implémentation des features dans la ravelle et j'ai l'impression
que c'est un peu la même idée, la même veine. C'est tout à fait ça, c'est pas la première fois
que je lis ou que j'entends cet argument, je pense que Taylor Otwell d'ailleurs il s'en cache pas,
notamment pour la doc qui est considérée comme une doc quand même assez sympathique, c'est vrai on
trouve vite ce qu'on veut, voilà par exemple il avait dit que clairement quand il avait décidé
d'y faire comme ça, de la façonner comme ça, c'est ça venait de code igniter, alors c'est pas
un framework que j'ai connu mais apparemment il est considéré pour avoir une doc vraiment très
très bien faite et du coup sur le framework en lui-même c'est vrai qu'il y a une grosse
inspiration de ruby. Tu m'as piqué un peu ma question de tout à l'heure, mais c'est que ça en fait.
Non mais si tu veux, il me semble que l'idée de base était vraiment de faire une sorte de ruby
en Ray, en PHP en fait, ce que d'un côté symphonie a un peu loupé en fait puisque symphonie c'est
très verbeux et ça m'étonne encore que ça soit autant aimé parce que quand tu passes,
il me semble que la Ravel c'est hyper simple en fait à prendre en main et puis à coder en fait.
Il y a une simplicité, ça fait partie des arguments qui sont mis en avant,
simplicité du coup élégance au niveau de la syntaxe, ça tire l'œil en plus de mémoire dans les
dans les docks un petit peu plus anciennes, c'était vraiment qu'on peut retrouver sur les
YouTube, les graficarts etc. C'était vraiment ça qui était mis en avant et ça a bien pris. Bon mais
après comme on l'a dit tout à l'heure, c'est vrai que symphonie ça s'impose ici, mais voilà,
chacun à sa dimension. Ouais, pour avoir fait des symphonies, il y a une grosse différence entre si
tu veux faire de l'authentification sur symphonie et si tu en fais sur la Ravel, c'est rien à voir.
Tément plus simple sur la Ravel. C'est vrai. Chacun s'écho.
Et en termes de package, en fait, chaque on va dire brick et fonctionnalité clé,
vous parlez d'authentification, je pense les bricks clés, c'est aussi l'autorisation,
comment tu vas requêter ta base de données, donc avec un ORM, tout ça. En fait,
c'est des bricks qui sont implémentés d'entrée ou c'est des petits modules que tu viens
construire et que tu appelles au besoin ? J'allais dire, c'est les trois. C'est à dire que
des fois, on a déjà des choses qui sont implémentées. C'est à dire, je pense par exemple, on va avoir
une API HTTP pour faire ses propres requêtes HTTP. Voilà.
Ça, par exemple, ça va être construit sur des composants symphonies, mais ça sera,
contrairement à ce qu'on peut penser, c'est jamais totalement appuyé sur symphonie. Il y a
quelques composants qui sont réutilisables, maintenables, fiables et où Taylor s'est dit,
bah ok, je vais m'inspirer de ça, je vais un peu m'appuyer sur ça, ça va faire un truc cool.
Au niveau du PSR, notamment ce fameux librairie HTTP qui a inclus dans le framework,
elle répond, il n'y a jamais de violation profonde du PSR. On peut un petit peu détourner
des petites choses, mais ça sera toujours compatible, il n'y a pas de problème.
Après, il y a des, donc ça c'est les choses incluses. Après, il y a des choses qui ne sont pas
incluses qu'on retrouve dans l'écosystème de la Ravel, notamment l'authentification.
Et après, je vais venir à la troisième partie, parce qu'en fait, c'est quand ça fait des fois
la transition. On a, globalement, fortify, ça va être un package d'authentification,
aucune opinion sur le front. En gros, ça va être une déclasse interconnectée entre elles,
qu'on va pouvoir réutiliser pour se connecter, pour faire tout ce dont on a besoin en termes
d'authentification. Et c'est tout. Après, on met le front qu'on veut, on peut réutiliser Blade,
qui est du coup le moteur de template. On peut utiliser du vu ce qu'on veut. Après, on va avoir
JetStream. JetStream, c'est vraiment l'usinagaz. Ça, je l'ai jamais vraiment exploité professionnellement,
mais ça vient véritablement avec tout un arsenal. Il y a vraiment la gestion du profil
qui est déjà là, la gestion des teams pour les users. Voilà. Et après, on a un peu l'entre-deux.
On a Breeze, lui, qui va, on va choisir un petit peu sa flavor niveau front. Est-ce que je veux du
vu ? Dans ce cas-là, il va créer l'authentification et les vues. Vu du coup, est-ce que je préfère
ma flavor ? C'est plutôt de rester sur Blade. Pareil, l'authentification, il va la générer
côté PHP et côté front. On va se retrouver avec des vues Blade. Il va mettre l'accent sur la
réutilisabilité avec les composants Blade. C'est des Blades, mais en mode un petit peu vu, histoire
de ne pas trop se répéter. Ça va être un petit peu les trois packages qu'on peut utiliser. Or,
mis tout ça, il y a des choses, il y a des interfaces, il y a des façades plutôt des façades
qui sont mises en place dans le framework qu'on peut utiliser, une façade haute. Si on a vraiment
envie de le faire à la main, ça met vraiment 10 minutes. On peut aussi le faire comme ça,
on a vraiment la main dessus. Et après, le troisième type de package, je pensais à Sangtum,
parce que Sangtum, à la base, au début, c'était Airlock, après, je crois pour des
soucis de droit d'auteur, ça a été renommé. Bref, c'était Sangtum. Pour l'authentification,
pour l'API par exemple, il peut par exemple envoyer des tokens pour son API. Ça, c'est quelque
chose qu'on devait installer à chaque fois. Et en fait, ça a fini par intégrer carrément le
framework. Donc maintenant, Sangtum, on l'a direct en installant le framework.
En mode native.
En mode native, c'est ça. Donc ça, c'est toujours cool. On peut générer des tokens, on peut
faire une authentification pour l'API basée aussi sur la session. Finalement, c'est tellement utilisé
qu'ils se sont dit qu'on va l'intégrer. Après, c'est un petit revers. Là, pendant ce temps-là,
le framework, il grossit quand même. Il prend une certaine taille. Mais voilà, on voit qu'il y a pas
mal de package. Il y a le framework qui est d'intégrer beaucoup de briques logicielles qui sont
là pour faciliter la vie du développeur comme ça, pour reprendre un peu le slogan. On peut se
focus sur la logique métier. Ok. Après, si on essaie de résumer, il y a quand même beaucoup de choses
qui sont livrées nativement avec et on n'a pas besoin d'installer d'autres packages, d'autres
extensions parce que nativement, quand j'installe mon MVC sous la Ravel, j'ai déjà
taqué de choses. Et donc, potentiellement, je peux faire beaucoup sans installer une dépendance tier.
Contrairement à d'autres petits frameworks en JS, par exemple, où ils ont une approche totalement
minimaliste, ils disent que moi, je ne vais faire qu'une API HTTP. Par contre, je veux rajouter
un autre module, ils ont tout splité. Là, la Ravel a fait un système inverse. C'est ça ?
C'est ça. Après, à l'inverse, si on a vraiment besoin de faire quelques appels HTTP, est-ce que
c'est vraiment la peine d'installer la Ravel ? Est-ce que c'est vraiment la peine d'installer
la Ravel ? D'accord. C'est vraiment que ça va être un cas où en général, on va préférer
objectivement. En fin de dire, on va préférer les gros frameworks.
Oui, bien sûr. Voilà, ce n'est pas la peine d'embarquer tout l'arsenal.
Ok. D'ailleurs, tu as parlé de PSR. On peut expliquer un peu vite faire rapidement ce que
c'est les PSR, tout ça ? Oui, bien sûr. C'est les recommandations PHP pour garantir la conformité
des frameworks entre eux. L'interopérabilité, je crois, c'est le terme scientifique.
On est censé, enfin, pas moi personnellement, mais ceux qui décident de développer les
frameworks, ils sont censés les respecter au mieux. Il y a des exemples comme le PSR4 pour le
démonstrer. C'est des conventions, c'est des conventions d'écriture de code pour que tout le monde
écrive de la même façon et que ce soit en sorte. C'est ça. J'ai envie de faire communiquer
mon framework avec des requêtes, des réponses HTTP. Je dois suivre certaines interfaces,
je dois faire certaines choses d'une certaine façon, comme ça, tous les frameworks auront fait la
même chose de la même manière. Là, c'est un peu technique, mais sinon, ça va aussi sur
des PSR qui traitent du nommage. Comment je nomme mon interface, comment je nomme mon trait,
est-ce que je mets du passcanalise ? En tant que je suis développeur débutant,
enfin, j'ai un petit niveau en PHP, est-ce que pour moi, par exemple, enfin, je ne parle pas de
moi, je parle d'un développeur lambda, est-ce que la ravelle est difficile à prendre en main,
ou est-ce que c'est facile à prendre en main, est-ce que je m'en sors facilement, même si je
n'ai pas un gros bug as technique PHP derrière ? Alors oui, très clairement, même pour faire des,
même si je conseille quand même d'avoir des basants SQL et PHP, mais pour prendre l'exemple
de requêtes SQL, on a notre RM, Eloquent, alors lui, c'est assez simple. La requête SQL a moins,
bien sûr, de faire quelque chose d'un peu poussé, qui par un peu dans tous les sens,
qui a priori ne devrait pas trop être le cas, mais bon, on n'est jamais l'abri d'un besoin un peu
bizarre. C'est vraiment, on lit la requête SQL faite avec Eloquent, on la lit, on lit le code qu'on
a écrit, comme on l'irait la phrase en anglais, c'est un peu à la piton, c'est vraiment,
c'est vraiment plaisant. Du coup, ça décourage pas du tout les développeurs débutants. Après,
il y a toujours cette espèce de débat, est-ce que je dois maîtriser les compétences inhérentes
comme ça à la Ravel, c'est-à-dire l'ORM, Eloquent, etc. Mais où est-ce que je dois en amont,
maîtriser ce qu'il y a sous le capot, alors pas le code directement, et par exemple pour l'ORM
Eloquent, est-ce que je dois être quand même un king sur SQL ? Je dirais que ça a fait un petit
débat sur Twitter la dernière fois. Je dirais que un petit peu quand même, parce que c'est toujours
le même souci, au début ça va, mais même si on arrive à facilement, j'allais dire, complexifier
les choses, le jour où il y a une petite erreur, quand même, il faut savoir ce que ça veut dire.
Comme d'habitude, les fondamentaux, c'est-à-dire au départ, c'est super bien de faire de la magie,
on crée des classes très rapidement, on a un crew de très rapidement, on a un ORM qui fait tout
seul pour nous. Par contre, évidemment, quand on commence à faire des joins dans tous les sens,
pour optimiser les requêtes, ou faire des agrégations de données, c'est un petit
peu plus complexe, et on pêchera en fait sur les fondamentaux. Et moi, ce que je vois,
c'est que je pense que ça doit être exactement pareil sur la Ravel, mais tu vas me dire,
il peut être critiqué, comme les aussi Rubien Riles, parce qu'il y a trop de magies,
et il y a plein de gens qui disent, mais c'est trop facile, c'est trop magique,
on ne comprend pas tout, parce que ce n'est pas verbeux, il y a beaucoup de choses qui sont faits
de manière implicite, et donc, c'est le danger de la magie, comme toujours, on le dit souvent sur le
podcast, mais il faut comprendre la magie. Si tu ne comprends pas la magie, à un moment donné,
c'est super difficile, et ce que je comprends, c'est que la Ravel utilise beaucoup ça, non ?
La Ravel utilise ça, ça cause des petits soucis. Alors, c'est vrai que ça encourage les développeurs,
parce que tout est assez explicite, tout est assez éloquente, tout est assez élégant,
mais on peut avoir pas mal de magies, par exemple, pour essayer de comparer avec Symfony, on va avoir
beaucoup de gaiteurs, beaucoup de seteurs, on arrive dans le contrôleur de la Ravel depuis la
requête, on va essayer d'attraper quelque chose qui nous a été envoyé depuis la requête HTTP,
on fait un request flash name, bon bah voilà, on fait un flash name, on fait pas un flash get name,
on n'a pas de méthode dessus, c'est la Ravel qui va le faire derrière, ça peut poser des problèmes
quand on fait de l'analyse statique aussi, parce que forcément l'analyse statique, il va avoir un
flash name sur l'objet request, il va se dire bah non, il n'y a pas ça, j'ai dit flash name,
mais j'aurais pu dire n'importe quoi d'autre, donc ça fait partie de la magie, pareil pour les
interfaces, pour les façades, pardon, je confonds, pareil pour les façades, les façades ça a été
beaucoup décrité, parce que on est là, on est content, on a notre façade, comme pour prendre
l'exemple de tout à l'heure, l'authentification, ma façade hot, ok, je suis un petit peu curieux,
je vais voir le code qui se cache derrière, je fais un contrôle, clique gauche dessus, bam,
je me retrouve dans une classe en fait qui retourne une string, et qu'est ce qu'on fait maintenant,
je vais où, on est dans le vendor et on ne sait pas trop, bon, ça, après ça fait partie d'un
design paterne particulier, mais il faut savoir ce que c'est un design paterne, il faut avoir eu peut-être,
voilà, il faut être passé dessus, ça cache du code, alors c'est vrai que c'est pas quelque chose
qui est top, j'ai pas dit que c'était génial, mais ça peut un peu chocer, mais il y a pas mal de magies,
notamment on le voit, dans la communauté, ils ont été obligés, Nuno Maduro qui est un
développeur très très très très actif, déjà pour le framework la ravelle et puis pour plein de
choses super qui l'a développé, il a été obligé de développer, on va dire une petite surcouche
qu'on installe qui s'appelle la rastane pour que l'analyse statique, donc ce qui va lire le code avant
qu'on l'exécute le code PHP pour nous dire qu'il y a des erreurs, il n'y a pas des erreurs,
pour pas qu'il pète un câble, parce que sinon PHP Stan, il va relever beaucoup trop d'erreurs,
comme ça, nativement sur la ravelle, donc ça demande, moi qui fais toujours mon
analyse statique, c'est obligé, j'ai obligé d'installer la rastane avec pour qu'il fasse ce
travail, ça fait partie des inconvénients, c'est vrai que c'est un peu pénible, mais bon, c'est
un prix à payer, si on arrive à maîtriser quand même un minimum, un minimum sans sujet, ça va,
ça finit par aller avec le temps quand même, c'est pas la fin du monde. Ok, je continue,
je développe pour les 8 ans, j'arrive sur la Homme de la ravelle et quand je descends en fait sur
la Homme de la ravelle, tu peux nous faire voir, c'est Alex, la Homme, quand je descends sur la Homme
de la ravelle, en fait, d'un coup, j'arrive, là, pas, mais là, j'ai eu plein d'outils, alors tu as déjà
parlé de brises, après derrière, je vois qu'il y a plein d'outils, Octane, Nova, Sail, Pint, enfin tout ça,
qu'est-ce que c'est en fait, enfin, qu'est-ce que c'est de tous ces outils disponibles comme ça,
avec la ravelle ? Alors je ne sais pas tout s'utiliser, mais c'est ce qu'on appelle un peu l'écosystème
de la ravelle, là, c'est l'ensemble des librairies qu'on va pouvoir installer, qu'on va habituellement
installer assez souvent, alors pas tout en même temps, mais beaucoup qui sont très très très aidantes,
on va les installer avec le framework et ça va nous aider pour plein de choses. Voilà, alors il y a des
packages, on va dire, plus ou moins non officiels qui fonctionnent très bien, mais il y a aussi, voilà,
il y a tout cet écosystème là, alors d'ailleurs ce n'est pas que des packages, on voit par exemple
qu'on a Forge pour le déploiement, on voit qu'on a aussi Valet, alors moi je suis sous Linux, donc
Valet à la base pour Mac, moi j'ai mon Valet Linux, c'est l'équivalent, ça va être pour, voilà,
pour avoir son environnement, son environnement, il va créer le, en local, voilà, en local pour
avoir, pour développer aisément sur la ravelle ou sur du PHP d'ailleurs sans soucis, après il y a plein d'autres
librairies quoi qu'ils font partie de l'écosystème. Oui, donc en fait ces packages ils sont à la fois
pour soit étendre les fonctionnalités natives de la ravelle ou aussi pour faciliter la vie du
développeur pour le cas de Valet, c'est un peu ça quoi, tout est organisé et est-ce
que toutes tes dépendances, par exemple si moi j'ai codé ou mon collègue a codé une petite librairie
en PHP, je peux l'intégrer directement dans la ravelle ou je suis obligé en fait de la bindé un peu à la
convention la ravelle ou quelque chose qui a été écrit en PHP, je peux l'importer directement si
vous avez bien respecté les guidelines ? Ça dépend de ce que fait le package, là comme ça je
ne saurais pas trop dire, moi quand j'avais créé un petit package mais c'est vrai que j'étais parti
d'un squelette qui était prévu pour la ravelle, après on peut évidemment venir greffer une librairie
PHP, on est quand même sur le même langage mais je ne saurais pas trop dire si ça va forcément
créer des petits conflits ou pas. Après c'est toujours comme un JS avec Composeur qui est l'équivalent
de nos NPM pour PHP, tu peux toujours installer une librairie PHP et l'utiliser dans ton code
ou après tu fais un module spécifique à la ravelle qui va utiliser la pays la ravelle.
Oui, ça s'associe absolument. Normalement il n'y a pas de soucis.
Et est-ce que tu penses qu'il y a des projets qui s'y prêtent mieux ? Toi avec l'expérience que tu as,
tu vois qu'il y a des projets qui s'y prêtent vraiment, on va dire non mais ça il faut qu'on
fasse ça avec la ravelle, on va gagner vraiment du temps ou à l'inverse des projets où tu dis
non mais là faut surtout pas faire ça avec la ravelle. En clair, quelles seraient les pro et les
applis qui sont vraiment propices à mettre du la ravelle et d'autres pas du tout ?
Alors je dirais dans 95% des cas, on peut facilement aller avec la ravelle. On a une application web,
développer une API, il n'y a pas de soucis. Les 5% ça sera plutôt pour,
alors comme on a dit tout à l'heure si c'est quelque chose de très minimaliste, très simpliste,
je ne sais pas, juste faire une petite logique métier, faire quelques appels,
HTTP je pense c'est tout. Peut-être que ce n'est pas la peine d'installer tout le framework
la ravelle. A la différence, si on a beaucoup d'attentes sur les performances,
mais vraiment quelque chose à nos secondes prêts ou alors une personnalisation extrême,
comme je l'ai dit la ravelle ça vient quand même avec une richesse de fonctionnalité,
si on essaye vraiment d'avoir la main sur absolument tout, il y a beaucoup de couches
d'abstraction, ça va peut-être bloquer un moment. Mais ça c'est les 95% de la ravelle.
Je pense honnêtement, on peut aller avec le framework, c'est quand même, il y a un gantant,
on évite de réinventer la roue pour plein de choses, il y a beaucoup, la communauté est incroyable,
c'est évidemment mis à jour très régulièrement, des fois peut-être trop régulièrement,
ça avance à une allure. Donc après on n'est pas obligé de se tenir informé,
de faire une veille vraiment journalière, de voir chaque petit point qu'il était ajouté,
mais ce que je veux dire par là c'est que dans la plupart des cas, la ravelle c'est une bonne
option. Tu dis il y a beaucoup d'évolution, il rajoute des features très régulièrement,
toutes les deux semaines il y a un nouveau truc qui est disponible.
C'est pas rare que ce soit dans cette période, on le voit très facilement sur Twitter,
à chaque fois qu'il y a une update, je vais le dire une update mineure du coup,
donc on ne change pas vraiment de version, un gros changement de version 11, version 12,
version 13, des petites choses comme ça, c'est très régulier, c'est vraiment pas,
c'est pas assez open, enfin par contre on finit toujours par avoir les mêmes gens qui vont
faire les requêtes, enfin les poules request qui vont être acceptées, ça va être merge,
il n'y a pas de problème, parfois il y a des personnes qui n'ont rien à voir avec l'écosystème,
qui vont avoir une idée assez innovante, ça va être intégré, mais tout ça c'est autant de
features qui vont être implementées dans le framework assez régulièrement et il y a toujours
quelque chose, après parce que ça touche aussi beaucoup de dimensions, ils vont penser,
parce que la ravelle va embarquer aussi le système de test, on va penser au test,
on va penser, dès qu'on va penser à une méthode en particulier, on va penser à créer un helper
ou quelque chose pour être tranquille quand on va vouloir tester les choses, donc c'est vraiment,
c'est vraiment très régulier et très riche. Ok, et tu parles, je rebondis parce que tu parles de test.
Donc tu dis il y a un outil de test qui est inclus dans la ravelle, comment ça marche ?
C'est incroyable, mais il rajoute sa couche, ce qui fait qu'on a déjà pas mal de helper pour
faciliter la vie, mais en plus de ça, et ça je crois que c'est une option qu'on peut mettre à l'installation
avec Composeur de nouveaux projets de la ravelle, on peut lui mettre test, alors bon c'est sûr,
je défends un peu ma paroisse parce que j'aime énormément test, d'ailleurs j'ai même une
de mes vidéos qui est sur la documentation officielle de Pest, mais c'est vraiment génial.
Et Pest, ça fait quoi ? Et Pest, qu'est-ce que ça fait ? Déjà ça va apporter une touche,
déjà une touche minimaliste, dans le sens où on écrit nos tests de façon très simple,
on peut s'organiser comme on veut, genre je ne vais pas avoir besoin de me créer une classe,
je vais inventer un truc genre project test ou post test, machin, je peux directement mettre
ma closure comme ça, je fais ma fonction, je fais mon test, il est inclus, je lance mes tests pour
voir si ça passe ou pas, j'ai pas un million d'informations, si ça passe, j'ai juste mes
petits carrés verts, voilà je suis content, je sais combien de temps ça a mis et le nom du test,
éventuellement si on a passé des données, des data sets au test, je vois le nom du data set qui
est passé, si ça ne marche pas, on n'a pas tout un gros tas comme ça informe, ça marche pas,
on a directement, ok ce test là ne va pas passer, voilà et si c'est un peu trop gros,
c'est tronqué, déjà ça c'est pour le fichage au niveau du CLI, c'est très minimaliste et puis
tout simplement il y a des plugins avec, parce que Pest on peut l'installer avec un projet PHP,
pas obligé de l'installer avec un projet, forcément la Ravel, il y a un plugin la Ravel,
ça fait, en fait ça devient vraiment très satisfaisant et ça c'est un point important
parce que le fait que ce soit agréable pour tester, ça permet de mettre le pied à l'étrier
pour les développeurs qui ont un peu peur de ça, parce que on va passer le cachet,
c'est quand même une compétence à développer, on a appris à coder en PHP, on a appris ce que
c'était une classe etc, mais il arrive un moment où on entend parler des tests et on esquive ça
parce que on ne sait pas, on n'a pas le temps et clairement et à juste titre c'est une compétence,
c'est une compétence à développer donc ça ça peut aider et ça c'est vraiment important.
Carrément, de toute façon c'est clair, si c'est simple, ça t'engage à faire des tests,
après le fait de ne pas faire des tests c'est général.
Et le fait d'être sur un framework MVC, tu vas pouvoir tester quoi, tu vas tester tes requêtes,
tu vas tester l'affichage de tes vues, on va dire une fonction de test vraiment end-to-end où on
vient tester toute la feature sur sa globalité où tu es plutôt en clair à quelle de
gré dans la pyramide de test tu es, est-ce que tu es plus sur des tests unitaires fonctionnels
de requêtes ou d'intégration même ? On peut aller assez loin, si par exemple dans mon fichier
blade ma vue blade quoi, j'ai du blade, je suis resté avec du blade, j'ai pas intégré par exemple
des composants vues, vues yes, je peux aller tester ce rendu là par exemple, je peux aller tester
mes requêtes HTTP, je peux moquer mes classes, par exemple je donne un exemple, j'ai une classe qui
génère des PDF, bon à ce moment là je n'ai pas envie de générer des PDF pendant mon test donc
je vais la moquer, ça va stocker un peu toutes les non instantiation de classes, ça va les
stocker dans un tableau et à la fin il va me dire ok ça s'est bien passé, ok non ça s'est pas bien
passé, tout ce qui vient avec la ravelle, déclenchement d'event, dispatcher des events,
j'ai plus tout en tête l'authentification, tout ça, il y a des méthodes très simples, à la fin est-ce
que la requête s'est bien passé, est-ce que ça a renvoyé un status 200, un status 404, est-ce
que je suis bien connecté, est-ce qu'à la fin de mon test, je prends l'exemple d'un test
fonctionnel, je suis toujours connecté ou est-ce que je ne suis pas connecté, tout est prévu, c'est
juste incroyable, on peut après faire un test unitaire, un test isolé, tester une petite
portion de code sans soucis et pour les tests un petit peu plus conséquents qui vont tester les
routes, qui vont tester les routes, les requêtes, le rendu, toute la logique métier, l'envoi de mail
aussi, voilà tout est... Il y a plus d'excuse pour ne pas faire de test en fait, sur la ravelle,
le mec qui fait pas de test c'est volontaire, c'est très clairement et très objectivement de la
mauvaise foire. C'est clair, de pouvoir moquer facilement tout ça, c'est vraiment un plaisir
après tu fais des tests, en fait ça devient un plaisir d'écrire les tests. Après on cherche le
100% de coverage à tout prix. Comme j'ai dit au début, on a un podcast plutôt orienté front,
en tout cas c'est comme ça qu'on nous qualifie, je sais pas si t'en penses à l'ex...
Moi je suis pas d'accord, mais je suis pas d'accord.
Mais on va quand même parler de la ravelle côté front aussi, je sais que Blade est super
performant en termes de template, il y a beaucoup de fonctionnalités, on peut faire des composants,
j'ai vu quelques trucs comme ça. Est-ce que c'est facile en fait d'intégrer,
si c'est un projet de la ravelle, je voudrais intégrer du vu, je voudrais intégrer du react,
est-ce que c'est facile de brancher, d'ajouter un paquet, d'y accéder par le front,
est-ce que les outils sont dispos facilement ? C'est facile, c'est très facile. Récemment il y a
une fois le framework a tout configuré pour nous, je prends l'exemple de vue, j'ai envie d'utiliser
des composants vus par exemple dans mes vus Blade, dynamiser un peu tout ça, je vais dans mon
vit.config.js, juste au début j'installe le vu quand même, il ne va pas tout faire,
mais je grève le plugin vu dans l'arrêt plugin, je mets vu, en gros c'est presque bon,
je vais dans la pp.js, je fais mes composants, je grève mon instance vu, c'est terminé,
et on peut l'utiliser, on l'utilise déjà, vraiment très simple.
Par contre, comment tu viens injecter tes données dans ton composant, c'est ton composant qui faire
un appel à une API ou en fait c'est dans ton contrôleur tu viens lui injecter du JSON ?
On peut faire les deux, ça dépend si on part sur des petits composants vus, on peut faire appel à
sa propre API ou passer vu comme tu as dit des infos du contrôleur qui sont dans la vue et dans
les props du composant vu par exemple, parce que j'ai pris cet exemple, mais on peut le faire,
c'est tout à fait possible. Est-ce qu'on a des recommandations ou des best practices qui émergeraient
de la communauté ? C'est à partir de telle state, il vaut mieux passer par une API et on va utiliser
la ravelle que pour l'API, ça va générer toute l'API et toute la business logic et tout ça,
et tout notre vue, enfin tout le visuel en fait va être géré directement depuis vu ou
next ou next ou je sais pas. Est-ce que ça c'est une bonne pratique ou au final on perd quand même
beaucoup de possibilités de la ravelle ? On se prive en fait d'un confort que la ravelle pourrait
nous apporter ? Alors je me souviens plus exactement de la date, mais ils ont
même si ce que je dis c'est toujours possible, j'ai rarement vu, enfin je ne suis pas non plus
tout puissant, je n'ai pas tout vu, je ne sais pas tout, mais j'ai rarement vu du next.
Ce qu'ils ont fait, c'est qu'ils ont créé un espèce d'adaptateur vu qui s'appelle Inertia et en gros
ça va sauter l'étape d'API et ça va vraiment tout se coacher un peu, c'est à dire que le contrôleur,
au lieu de renvoyer une vue blade, il va renvoyer une vue js quoi direct.
Donc ça c'est pas nécessairement la meilleure façon de faire, mais ça fait partie des
alternatifs que la ravelle va proposer. Après je pense que bon si c'est vraiment un petit
peu du dynamisme importé par la, on voit très souvent ça les SFC, les single file component
utilisés avec vue, moins réacte même s'ils ont fait l'effort de mettre en avant sur la
homepage qu'ils ont sorti récemment, la ravelle.com, ils se veulent un framework où
en fait on n'a pas trop d'opinion, vous faites ce que vous voulez sur le front,
il y a la solution Inertia, il y a LiveWire, alors LiveWire c'est vraiment pour ceux qui ne veulent
vraiment faire du js, mais ne écrivent pas de js, tout votre js,
c'est du PHP.
Ok, mais par contre est-ce qu'on va garder cette réactivité,
en clair est-ce que je vais être obligé de recharger ma page à chaque mouvement,
à chaque requête de mon formulaire ou en fait je vais avoir un peu le meilleur des mondes,
c'est-à-dire garder cette réactivité dans ma page et je ne vais pas être obligé de recharger
Non, on garde la réactivité.
Et là pour l'exemple de Inertia par exemple, c'est comme si c'était sur quelque chose de réactif,
il n'y a pas besoin de recharger au niveau du routeur, si on n'impact tout dans la même
application, au niveau du routeur de la ravelle, on ne va pas mettre qu'une vue qui accepte tout
et après on peut venir greffer son routeur, faire ses composants vus et tout faire,
vraiment faire ça SPA, mais avec la ravelle quoi.
Il y a plusieurs niveaux de possibilités, mais quand on utilise, soit comme j'ai dit,
vu soit les alternatives proposées, on ne perd pas de réactivité.
En Inertia ça a l'air assez prometteur, depuis que j'ai vu la sortie,
je crois que c'est version 1, ça fait deux semaines que j'ai envie de tester,
j'ai pas eu le temps encore, mais ça a l'air super prometteur.
C'est un bon compromis, ça fait un petit moment que c'est là, on ne s'est pas non plus très
très vieux et on a ajouté assez récemment, peut-être il y a un peu moins d'un mois,
le support TypeScript, comme ça, tout le monde est content.
Livewire comme tu disais, ça a amené de rubis à la base,
où il y a Hotwire, ça a peu près le même concept, où ça te transforme ton application
PHP en application JavaScript et il se charge tout seul d'aller charger les modèles,
les bootcodes, tout ça, qui va remettre dans la page.
C'est ça, pas une seule ligne de JS en fait, que du PHP,
avec forcément des méthodes, des classes, ou si vous voulez une petite guideline,
mais au final, pas une seule ligne de JS.
Top.
Pour ceux qui n'aiment pas le JS, ça c'est parfait.
Il y en a qui ne jouent que par ça.
Après, on gagne vachement de temps, mais de toute façon, après, c'est comme tout.
Une fois qu'on a construit son paradigme, on a l'habitude de faire ça, on a construit
autour de ça et on voit le temps qu'on gagne.
On fait son choix.
Très bien.
Ça a l'air super puissant.
Ça a l'air super puissant et rapide sur l'implémentation.
Au début du podcast, ça parlait de communauté.
Est-ce que la communauté est importante sur la ravelle et est-ce que c'est facile
d'avoir de l'aide ? Est-ce qu'il y a des slack, du discord, des trucs comme ça ?
La communauté est vraiment incroyable.
Juste avec Twitter, déjà, beaucoup de tips, beaucoup de snippets de code
qui sont échangés, même des télégrammes qui sont mis en place, notamment, je pense,
à Pest, PHP, il y a le télégramme officiel de Pest où tout le monde a rejoint d'un coup
et tout le monde peut discuter, s'entraider.
Quand on arrive sur du stack overflow, qu'on est un petit peu perdu, on va sur Google,
on en trouve toujours la solution.
Ça n'est jamais arrivé de ne pas trouver la solution sur un truc et c'est pas parce
que je suis fort, c'est juste parce que c'est très populaire et que ça a fini.
On est quasiment toujours dans un cas où le souci qu'on a eu, quand même qu'un d'autre l'a eu
et qu'un d'autre a répondu surtout.
C'est aussi parce que tu sais bien chercher, parce qu'un bon développeur, c'est quelqu'un
qui s'est bien tapé sur Google.
Ça aussi, c'est une compétence.
On va finir l'épisode, on va parler un petit peu de comment tu...
Déjà, il y a ta chaîne qui permet de s'informer sur la Ravel.
On rappelle le nom.
C'est la Ravel Jutsu qui est une chaîne YouTube où tu as pas mal de vidéos,
de bonnes qualités.
Mais après, où est-ce qu'on peut encore s'informer ?
Déjà, il y a la doc, la Ravel, j'imagine.
Il y a la doc, la doc est très bien faite.
Les discussions sur GitHub vraiment très, très, très, très, très open sur les différentes
librairies.
Après, pour les choses un peu plus réseaux sociaux, Twitter, Twitter, il y a toute la
communauté Twitter dessus.
Et ça suffit franchement d'aller faire un petit tour, un jour sur deux ou une fois
dans la semaine.
Ça suffit largement pour capter toutes les nouveautés.
Côté français, bon, il y a ma chaîne.
J'essaye de construire des petites vidéos quand je trouve qu'un truc est intéressant
ou quand je me suis heurté à une problématique et que pour trouver la réponse, ça m'a semblé
assez pertinent pour en faire une vidéo, assez long pour en faire une vidéo.
Je le fais.
On a la Ravel France aussi qui donne quelques articles sympas.
Globalement, après, pas mal de choses qu'on découvre sur Twitter.
En vrai, c'est ma seule veille technologique si on peut appeler ça comme ça.
J'avais vu aussi une série sur la Ravel qui était assez intéressante pour apprendre
la Ravel.
Absolument.
La dernière, la formation qu'il avait sur la Ravel qui date un petit peu.
Et là, il a fait vraiment de A, Z, de l'installation via Composeur jusqu'au déploiement.
Ok.
Parfait.
Il y a de quoi faire.
Il y a matière à travailler là.
Ok, parfait.
Cool.
Ecoute, un grand merci pour ce moment, pour ces échanges.
On a une idée un petit peu plus claire de ce que c'est, on va dire, la Ravel, comment
l'utiliser et comment approfondir son paradigme et comment on peut l'utiliser.
Un grand merci à toi Ludovic.
Merci à tout le monde d'être resté jusqu'au bout de l'épisode.
Pensez à mettre un petit pouce à discuter du collègue, ça fait toujours plaisir.
Et de parler du podcast avec vos collègues.
Et on vous dit à bientôt sur un autre épisode.
Ciao ciao.
Ciao.
Merci à vous.