Bonjour et bienvenue à tous, un épisode un peu particulier, ce qu'on va parler de
toujours de Jamstack, mais avec un retour d'expérience où pour le coup on entend souvent
dire que la Jamstack c'est rapide, c'est performant, on en a parlé dans l'épisode
précédent et aujourd'hui en fait on va discuter peut-être des limites de la Jamstack
et on va le faire avec Patrick. Salut Patrick ! Salut Alex, comment ça va ? La forme ?
Bah écoute ! Ouais au top ! Alors ça commence à data un petit peu mais t'as écrit un article en
fait au mois de mars, début mars sur les limites un peu de la Jamstack. Le postulat en fait c'était
est-ce que faire un site statique avec 10, 11, 12 000 pages ? Est-ce que c'est possible et
quel problème t'as rencontré ? Et comment t'as réussi à trouver une solution viable à
tout ça ? Donc on va parler de Jamstack, de performance et surtout de build. C'est ça ?
Exactement, oui oui. Donc oui c'est suite à une expérience que j'ai eu avec un client qui
sur lequel on a fait un POC. En fait l'idée c'était de tester ce qui était possible de
faire avec du statique puisque on y reviendra pas sur le contexte mais voilà on voulait vraiment
tester ce qui était possible et les blocages qu'on pouvait rencontrer et suite à ça j'ai fait
un article sur le, j'ai écrit un article pour le fantastic site jamstack.fr et merci à
Franck de m'avoir aidé aussi et puis voilà donc on mettra le lien de l'article dans les notes
pour si vous voulez lire l'article mais c'était super intéressant. Et en fait c'était vraiment
benchmarker et aller trouver la limite du système ou pas ? Ouais c'est totalement ça en fait on
arrête pas même sur le podcast de dire jamstack c'est le top, le statique c'est le top,
faut faire du statique c'est l'idéal et tout ça machin mais en réalité voilà il y a certains
il y a certains cas de figure on n'a pas forcément enfin on n'a pas le loisir de pouvoir tester un
grand nombre de pages à générer parce qu'on fait des sites classiques avec je sais pas moi
200, 300 pages enfin des trucs comme ça et là dans ce cas là il n'y a pas de problème mais
est-ce qu'un site de média avec beaucoup beaucoup de contenus est capable de se faire en en en
en statique bah voilà c'était ça le but ouais de voir les limites. Ok et donc tu peux nous donner
un peu le contexte de base comment vous avez c'est quoi votre postulate base ? Le postulate
base c'est alors c'est un client qui est sur ANSI qui fait des articles pas mal de textes légaux
tout ça sur le droit du travail etc je vais pas donner le nom de la société mais elle a assez
connu elle est sur le parc d'Eglésin sur ANSI pour les gens qui connaissent et le logo il est bleu
voilà après ils m'ont autorisé à dire le nom mais je vais dégarer. On s'abseindra. Ok donc l'idée
c'est que c'est une société qui existe depuis longtemps qui faisait des papiers depuis des années
des fin des décennies je sais pas depuis quand ils existent après ils sont passé au web donc maintenant
tu peux consulter sur le web il y a des sites il y a des PDF tout ça enfin tout tout tout tout ce qui
peut aider un DRH tout ça à gérer les salariés tout ça et donc ils ont beaucoup beaucoup de contenus
ils ont au fil des années ils ont utilisé beaucoup de techno parce que forcément quand tu existes
depuis longtemps bah le web évolue et bah tu passes d'une techno à une autre ils ont utilisé plein
de choses du PHP du symphonie ils ont fait de l'angular ils ont fait vraiment beaucoup de choses et
c'est hyper fragmenté en fait ils ont plein de sites mais ils sont tous fragmentés ce qui fait
aujourd'hui quand ils veulent faire évoluer par exemple un bout du site par exemple le header
il s'objet de refaire le header de plusieurs sites en même temps tu vois c'est pas un seul site en gros
ça devient compliqué en fait de faire évoluer ils ont une grosse dette technique et l'idée en fait
il y a quelqu'un chez eux qui est qui est super parce qu'il veut tester en fait des nouvelles
technos il est très ouvert sur la jam stack et donc il a envie de tester et son idée c'est de
de cliner tout ça et de repartir sur une base propre avec un système statique jam stack voilà en
gros mais avant de faire ça il est prêt à investir un peu pour benchmarker et tester tester les
limites du système avant de mettre tous ses pions et de faire ce pari technologique
il est obligé de tester et de prouver via des chiffres parce qu'il a des gens quand tu es dans
une société que tu as des gens à qui tu présentes en disant bah écoutez on va tout refaire mais on
va faire comme ça ok mais prouve nous que ça marche et que c'est viable sur le long terme parce
que c'est aussi ça c'est de partir sur des technos qui seront viables sur les années là donc tu
peux pas dire sur un coup de tête aller on refait tout avec tel site avec tel techno et on verra
bien après non il faut réfléchir il faut voir si ça marche il y a aussi un contexte aussi de
personnes qui vont gérer le contenu donc il faut que que ça soit agréable pour elle aussi de pouvoir
gérer le contenu rajouter du nouveau contenu tout ça donc c'est tous ces paramètres à prendre
en compte aussi il y a tout aussi un paramètre marketing aussi puisque il faut qu'il y a une
de l'argent aussi donc ça fonctionne et que ça fasse de la conversion enfin voilà donc beaucoup
de paramètres à prendre en compte business classique quoi intéressant et pour le coup si
on vient découpler parce que la gem stack au final c'est pas une stack c'est moi je dirais que c'est
une philosophie de technologie après c'est totalement agnostique dans le dans le langage
on peut faire du php on peut faire du gs du go du qui n'importe mais tu peux pas tout tester tu
peux pas tout benchmarker et à la limite sur côté front et côté back qu'elles ont été tes choix
et qu'est ce qui fait la connexion entre les deux parce que tu pouvais pas tout tester
non on peut pas tout tester non on peut pas tout tester puis après tu as des en fait les
choix sont fait par rapport à des besoins en gros donc par exemple ok on part sur du
headless et de la gem stack enfin des statiques pardon mais il faut par exemple que la personne
qui va rentrer le contenu puisse avoir un mode de preview au moment où elle va rentrer le contenu
pour voir qu'est ce que ça rend sur la page en public avant de valider et de rebuilder le site
et de republier ça donc voilà c'est des confort d'utilisation en oublier de dire un truc c'est
que on parle tout le temps de gem stack et il y a vraiment un secteur pour lequel la gem stack
enfin en tout cas le statique les sites statiques sont vraiment la solution idéale c'est tout ce
qui est média en fait donc tout ce qui est journal média etc puisqu'en fait il faut savoir que la
plupart du temps ils écrivent des articles donc ils écrivent beaucoup d'articles ils en écrivent
plusieurs par jour mais une fois qu'ils sont écrits ces articles ils ne bougent plus il y a peut-être
des petites corrections de temps en temps mais c'est très rare et la plupart du temps en fait une
fois qu'ils sont écrits ils ne bougent plus donc effectivement le statique pour ce genre de site
ce genre de média c'est l'idéal puisque en fait le contenu il bouge plus donc pas besoin de
régénérer à chaque fois d'avoir PHP qui génère un site ou enfin une page ou quoi que ce soit donc
parfait le le statique pour ça donc ça c'est important et donc après voilà je choisis des
techno c'était vraiment par rapport à des besoins on a réfléchi l'idée c'est quand même de partir
sur alors on va dans le statique il y a deux types de générateur ça c'est important aussi de savoir
parce que après suite à l'article aussi il y a une discussion par rapport à Hugo tout ça donc il
y a deux types d'articles de générateur il y a le générateur qui va te sortir un site statique
mais pure statique on va prendre Hugo les ventilles tout ça donc ils vont vraiment te sortir que du
html et là on n'a pas déjà pas script ils vont générer du html ils vont cracher du html et là il
n'y a pas de javascript tout ça c'est juste du html donc on a des pages et de page en page ça
recharge la page c'est un site classique sauf qu'on a du fichier html il n'y a pas de serveur derrière
qui tourne et ensuite il y a des générateurs d'app statique donc là on parle de tout ce qui est
nextjs, next, gatsby et j'en oublie d'autres mais voilà là c'est un petit peu différent c'est que ça
va faire du html évidemment comme les autres sauf qu'en rendu dans le navigateur on va avoir une
web application et là ça change le c'est un petit peu différent puisque ça change complètement
le paradigm mais surtout l'expérience du visiteur en fait c'est quand même enfin je ne sais pas ce
que t'en penses mais c'est quand même différent quand t'es dans une web app tu cliques sur un lien c'est
instantané tu changes de page sans recharger la page enfin c'est quand même enfin je trouve que c'est
quand même plus agréable en tant que visiteur d'être sur une web app que sur un site statique
alors après ça se débat je sens déjà des gens qui sont en train de dire non je ne suis pas d'accord
mais bon voilà après c'est ouais après c'est ces deux visions qui sont bah différentes sur sur
l'approche par contre bah est-ce que vous avez dû choisir ou t'as dû benchmarker les deux non
le choix était déjà arrêté sur du sur du générateur de web app en en a eu alors c'était
c'était simple c'était trois il y avait gatsby soit gatsby soit next djs soit next en fait il
avait trois on était trois sur trois générateurs on a écart alors il faut savoir qu'on a écarté
gatsby assez rapidement et pourtant c'était vraiment le le choix du début sur le papier
plusieurs mois on en avait parlé c'était plutôt orienté sur gatsby puisque bah gatsby a quand
même le vent en poube ils font beaucoup de communication tout ça et et suite à un article
je sais pas si tu te souviens il ya un article qui est sorti sur comparaison comparaison des
générateurs et le gars en fait en fait c'était comparaison de temps de compilation de générateurs
de sites statiques qui avait été traduit par franc sur le site gem statique et le gars en
fait comparé next gatsby tout ça Hugo et tout ça et bah évidemment gatsby est le plus lent de
tous en fait donc c'était sur le temps de billes on était vraiment sur temps de build
performance pure quoi style tu test un voilà tu test vraiment à bien différencier avec la
performance du rendu c'est à dire la fichage du site c'est pas la performance du build de la
création du vraiment pure bill de pure chiffre donc suite à cet article en fait on a
dit ok gatsby on met de côté et puis next en fait dans l'article avait eu des bons échos en
disant bah next c'est un très bon générateur des très rapides etc etc donc du coup on est resté
sur next et next de techno vu réact moi j'aime bien next j'aime bien next j'aime les deux donc
je vois évident et ensuite côté cms alors on a choisi un cms qui est peu connu et s'appelle
craft cms par contre voilà il n'est pas très connu en france cms qui est américain qui fait
par une boîte américaine qui est payant donc on n'a pas l'habitude de payer des cms la plupart des
gens pas d'habitude mais ça se paye des fois c'est pas hyper cher en fait par rapport aux services
rendus par contre en termes de cms headless enfin pour moi c'est le meilleur cms headless parce que
d'origine il a tout en fait il est déjà prévu pour le headless il a graph ql il a les web
book il a un système de preview il est vraiment très très très bien fait donc voilà par contre
il est il est pas open source est il est pas open source donc c'est propriétaire c'est plus ou
propriétaire il est payant donc je disais après c'est 300 dollars l'année c'est pas non plus fin je
veux dire quand tu fin tu connais le prix de taux horaires d'un indépendant c'est 300 dollars ça
va quoi c'est pas non plus le bout du monde et enfin il y a plein de choses qui gère par défaut
il gère le multilangue il gère plein de choses donc très honnêtement quand tu calcules avec un
astu-prenware presse que tu veux rajouter le multilangue etc t'es vite au même tarif quand tu
commence à payer des plugins donc après ça se discute quoi ok ça se discute en tout cas c'est
le choix en prenant en compte on va dire toutes les contraintes vous avez mis graph
graphuelle on utilise graphuelle et surtout le mode preview dans craft cms qui est vraiment top qui est
prévu pour le headless donc tu peux avoir du preview sur un headless statique directement dans
l'éditeur donc c'est vraiment vraiment bien fait facile donc la stack front pardon la stack back
était plus ou moins fixe et du coup les benchmarks étaient sur le côté sur le côté front avec
next et exactement ok alors qu'est ce que ça dit alors alors j'ai commencé par next en fait
j'ai commencé à faire le premier poc avec next à savoir que j'utilisais aussi taïwine normal
et puis donc du coup ça faisait un mélange assez sympa taïwine permet aussi de coder plus vite
quand tu quand tu fais du poc clairement une fois que tu connais les classes ça va vraiment plus vite
ouais même si en ce moment il ya il ya un taïwine je sais pas tout le monde se déchaîne contre taïwine
c'est satan qui rentrait dans taïwine à lire certains tweets mais on aime on aime ça discute
c'est suite à un article c'est vraiment hater le mec enfin son article enfin bon perso je trouve
que l'article est bidon et tu sens que le mec a pas testé taïwine alors il ya des défauts évidemment
sur taïwine mais bref ouais de toute façon c'est classique mais de toute façon dans le milieu du
dev c'est il ya limite de la religion et du dogme donc testez essayez vous aimez pas et
bah vous utilisez pas vous aimez et puis voilà mais ok donc toi pour le coup t'avais mis ton ton
ton design enfin tout ton css en taïwine et t'as commencé par next et le but en fait c'était
vraiment de d'utiliser next et next en statique vraiment en full statique donc en export html
voilà ok on veut du statique web app mes statiques puisque next permet de faire du rendu serveur du
ssr permet de faire de la de la de l'aspa classique et permet aussi de faire du statique fait les
trois modes tout comme next qui permet de faire les trois trois modes donc c'est deux frais morts qui
sont vraiment très très proches sauf qu'il y en a qui en réacte et qui a un vu quoi
exactement voilà ok donc jusqu'à tout va bien et en fait donc comme comme on l'a dit les tous les
articles la plupart des articles sont vraiment sur le temps de build tout le temps en fait en fait
c'est en gros on est un peu vraiment sur ils sont en fait je sais pas ce qui se passe mais les gens
sont bloqués dans le statique par rapport au temps de build il faut que le build soit le plus rapide
possible a ego il déchire tout parce qu'il est rapide et tout ça ok ok regardez ça de côté
donc premier premier problème déjà sur entrer sur un bloc et sur un problème que franchement
je n'avais pas du tout évalué alors oui le temps de build est important mais le problème c'est que le
problème que j'ai eu c'est bon alors la pays n'a pas été enfin craft cms n'avait pas été du tout
optimisé tout ça le cache etc mais on l'a vraiment mis il était brut quasiment mais j'ai eu des
problèmes en fait au niveau de la bain en fait les appels à la pays la pays avait du mal à suivre
en fait en gros quand tu vas faire tes 11 000 pages ça veut dire à peu près 11 000 appels simultané
presque très rapide en fait et mon appai avait vraiment du mal à tenir à répondre en fait à ces
11 000 appels qui se font en quelques minutes en fait en s'en fait ça se fait d'un coup donc c'est
j'ai dû faire un système de cache donc en gros je faisais un système de cache quand je faisais
ma première appel de faire la liste d'articles et après j'utilise ce cache pour faire les
articles les pages d'articles seul et là ça ça marche plutôt pas mal j'étais entre 5 et 8 minutes
pour faire les 11 000 pages donc ce qui reste à peu près correct on va me dire que Hugo fait ça
en une minute mais bon je connais déjà les commentaires mais sachant que alors petit détail
parce qu'on parle toujours d'hugo en niveau de générateur hyper rapide j'ai appris par la suite
que Hugo je vais encore éricer des poils Hugo gère très mal quand tu vas quand t'appelles une API
externe en fait Hugo marche très bien avec des fissiers markdown statiques mais par contre il a
du mal apparemment ça marche pas forcément très bien avec une API externe à noter puisque là nous
on parle vraiment d'appeler une API externe ok ensuite donc premier blocage c'était ça les
cache le cache et ensuite j'ai eu je suis tombé sur un gros souci et ça vraiment c'est la surprise
vraiment du impossible puisque personne n'en parle en fait première la grosse surprise c'est que quand
tu fais tes 11 000 pages tu te retrouves avec beaucoup de fichiers en gros tu as 11 000 fichiers alors sur
sur next il fait deux fichiers normalement il fait le fichier html et il fait un fichier json avec
les data pour réhydrater etc et en fait 11 000 pages c'est ça faisait un projet enfin un projet
buildé de 400 à 500 méga bits ça commence à faire ok ça c'est le truc qui pense pas en fait
il dit ok j'ai géré des statiques mais ah oui mais c'est vrai c'est des fichiers et tu penses pas du
tout en fait c'est 500 méga bits mec c'est un demi giga quoi donc et oui et du coup après tout ça il
faut l'auploder et voilà et ça il faut l'auploder sur le serveur parce que quand tu que tu le fasses
en local ou que tu le fasses sur netlify netlify va va va builder ton site et après il va le ploder
sur le cdn et ben le truc c'est là où ça j'ai halluciné en fait c'est que il fallait 39 minutes
pour uploader tout le site enfin toutes les pages les 11 000 pages et c'est long alors c'est très très
long et au début j'ai halluciné en fait je dis mais c'est en fait je pensais en fait c'est vraiment
j'y pensais pas du tout et je me dis mais ça blague en fait ce coulo d'étanglement c'est pas aussi le
fait que sur netlify tout est géorépliqué sur différents et je suis différent cdn ou des choses
pas du tout parce que j'ai testé moi j'avais la fibre voilà je l'ai plu mais j'avais la fibre
et j'ai testé de mettre pour mettre sur un ftp j'essaie de mettre sur un ftp voilà upload classique et
ça venait ça m'était à peu près le même temps et j'avais la fibre donc non ça ne vient pas de
netlify ça vient en fait c'est le nombre de ces nombres de fichiers et le et le poids cumulé de
tous ces fichiers qui fait que c'est extrêmement long en fait et là en fait tu bah au début comme je
dis je pensais que c'était un bug je me dis j'ai dû louper un truc j'ai un réglage je sais pas
qu'est ce que j'ai fait comme pourquoi tu vois le truc en déploy il m'était upload je crois je sais
plus et tu n'est pas sur rien pendant 30 minutes en fait je dis mais ça déconne en fait la première
fois je l'arrête en fait je dis mais ça déconne je vais relancer en fait et non toujours pareil et
ça repart du point autour et là j'ai halluciné et c'est vraiment le truc personne n'en parle et
personne ne fait un seul truc qui attend pas et là gros problème tu dis bah en fait ça ne
marche pas en fait en gros le le full statique sur un grand nombre de pages bah en fait ça
ça marche pas en fait tout simplement donc c'est un petit peu embêté et du coup la solution c'est
donc là ouais donc j'arrive à ce niveau là et là je suis un petit peu coincé je me dis
bah comment on fait là comment je vais dire à mon client que en fait ça marche pas en fait
je suis un peu embêté bah nux ok on va tester avec nux mais c'est le même problème puisque nux
qui va générer des fichiers statiques on a en retour à peu près au même même problème j'ai quand
même fait le poc quasiment le la même taille de bundle avec le même de fichiers tu auras la
même chose avec elle est ventille peut-être un peu moins parce qu'il va pas faire de
fichiers de j-mc paris donc il n'y aura qu'un seul fichier par page mais on a toujours un très
grand nombre de fichiers et puis du point important et d'autant que là c'était le poc mais le but
c'est de plus tard de faire 20 000 voire 30 000 pages en fait donc c'était vraiment bah ça ça
ne fit pas du tout on est ça marche pas là c'est pas utilisable en prode clairement et en fait
donc j'étais quand même au bout du poc j'ai fait la version nux aussi donc pareil même problème
etc sachant quand même qu'il y a une petite subtilité il me semble alors sur nux tu as un
paramètre déjà par rapport aux appels à la pays sur nux il y a un paramètre qui permet de régler
le nombre d'appels simultané à la pays etc donc tu peux éventuellement jouer avec ça pour le
système le problème de cache que j'avais par contre sur nix je suis pas sûr que ça existe en
fait il me semble que ça existe pas sur nix alors donc la solution il se trouve que next pour l'instant
ils ont un système un petit peu unique qui s'appelle la régénération incrementale donc
ouais c'est un terme super texte c'est la régénération incrementale c'est un peu
obscure quand tu sais pas trop ce que c'est alors certains diront c'est pas du vrai statique c'est
pas faux j'ai envie de dire puisque avec ce mode t'es obligé d'avoir un serveur node qui tourne
quand même derrière donc versel te permet d'utiliser ça sans problème il faut savoir que ce n'est
pas lié à versel tu peux utiliser next avec ce mode là sur n'importe quel serveur node il n'y a pas
de la réaction incrementale il y a des solutions qui se passent donc c'est un peu une solution
hybride parce que dans tous les cas ça va te renvoyer un fichier html donc on est quand même
sur le statique il va c'est pas le serveur qui va générer la page et te la renvoyer comme un php
ou un serveur node ou quoi que ce soit c'est vraiment un fichier html qui est renvoyé en fait
ce qui se passe c'est que au moment de builder ton site tu ne vas pas générer toutes les pages
en gros en fait tu peux générer ce que tu veux si tu veux générer que les mille ou deux mille
dernières articles parce que tu te dis bah ceux là ils vont être visités donc je vais les générer
comme ça ça sera déjà prêt tu peux si tu veux rien générer tu peux aussi tu génères aucune page
et en fait ce qui se passe c'est que c'est au moment où la personne va visiter la page que le
fichier est généré là je parle bien de fichier je parle pas de serveurs qui renvoient du html en
fait le next va générer le fichier de la page en html et il va te la renvoyer et après derrière
ce sera toujours ce fichier là qui sera renvoyé ok donc si donc si je comprends bien au pire des
cas je mets je génère aucun fichier et au fur et à mesure que que les clis que mes visiteurs viennent
sur mon site on va dire la personne arrive sur l'article 1 le fichier est généré après il y a une
autre personne qui arrive sur article 1 lui il bénéficie en fait du fichier parce que il a déjà
été au fur à mesure en fait ils sont créés à la volée mais non pas déterminé par moi en tant
que développeur pas dans ma fonction de mon build mais en fait il est donné à la demande de l'utilisateur
exactement c'est exactement ça et donc c'est c'est la solution pour l'instant la seule que j'ai
trouvé aujourd'hui pour faire fonctionner un site avec un très grand nombre de pages parce que ça
permet justement de pouvoir builder un site qui a énormément de pages et de générer les sites au
moment de la visite enfin de générer les fichiers au moment de la visite ça veut dire aussi qu'il y a
potentiellement des articles qui ne seront jamais générés imaginons un vieil article qui date de
5 6 ans peut-être que personne ne va jamais le visiter en fait donc il sera jamais généré
mais par contre est-ce que ça ça marche aussi pour le le le sio par exemple les petits crawlers
des des de google et bing et tout ça là quand ils viennent sur le site si la page elle est pas
générée qu'est ce que les crawlers voient alors là c'est on va rentrer dans le technique de next
donc je vais essayer d'être compréhensible en fait quand tu c'est une fonction qui qui
gère en fait cette face cette fallback en fait en fait il ya une fonction dans les pages que tu
qui s'appelle des get static pass et il ya un mode fallback que tu vas définir qui va faire ou pas
le fait que ça génère la page ou pas et il ya deux modes il ya le mode en true et le mode en
blocking entre où en fait il va alors entre pour bien comprendre la personne qui va venir visiter
la page si c'est en true elle va être généré en fait ça va renvoyer un fichier html mais qui
est vide et ça va être généré juste après en gros dans le browser ok d'accord et ensuite le mode
de blocking si tu mets le fallback en blocking il va la personne vient visiter la page et là par
contre il ya une sorte de disons qu'il n'y a pas de il renvoie automatiquement le html complet tu
vois la différence ok donc si mais en fait c'est hyper rapide franchement c'est c'est
ouais ouais mais en fait ma question est sur sur sur sur les croleurs justement c'est ça
ils vont en fait si tu mets le fallback en true si t'as un robot qui vient visiter ton site pour les
cio et que t'as mis tout en true et ben en fait ce qui va se passer c'est qu'il va avoir des pages
vide alors que si tu mets en blocking il va se retrouver avec des pages généré et en fait le
temps du temps de réponse est tellement fin il ya quand même une petite différence on va pas dire
contraire mais c'est quand même signifiant c'est c'est très rapide puisque après ça dépend
de la taille de la page aussi mais c'est très rapide du coup il est dans l'idéal il faut utiliser le
mode blocking pour que justement pour le si on d'accord bah si une page capa était généré que
le robot de google vient visiter il puisse avoir le contenu complet ok donc je vais quand même pouvoir
exposer mon site map complet avec mes 12 000 pages même si au final elles sont pas tout à fait
généré sur mon serveur avec avec cette fonction un peu fin de fallback elle sera généré à la
volée mais ça va pas me bloquer et me mettre des pénalités ou avoir des effets bloquants c'est
pour ça que je te parlais de après une stratégie à adopter si je suis ainsi de
média je peux générer les 2000 dernières articles par exemple donc ceux qui seront
potentiellement hésité par google etc tu vois donc après c'est tout une stratégie
et mettre en place ceux qui sont plus ouais bien sûr et pour pour augmenter ouais pour pour
augmenter ton fin non justement pour ne pas augmenter ton temps de build et à avoir des
trucs en frais quoi ouais vrai et frais dispo rapide optimisé sur et à l'inverse on pourrait
aussi dire qu'on pourrait supprimer des fichiers qui sont potentiellement en statique si ils sont
trop vieux par exemple des archives ou des choses comme ça on les on croit que non en fait si ils sont
ils sont ils sont déjà généré ils sont déjà généré après après c'est des techniques
et si ou après moi je suis pas spécialiste et si ou mais c'est vrai qu'après il y a il y a souvent
une méthode qui consiste à dégager les vieux trucs qui t'impacte plus négativement que
positivement quand c'est trop vieux etc mais bon après ça moi je suis pas spécialiste tu mets
après je voulais juste finir sur ce mode régénération inclementale il y a un deuxième
effet qui se coule pour ceux qui connaissent ok boomer il ya un par en fait il ya avec le next il
y a un paramètre aussi qui s'appelle revalidate donc qui te permet de définir un temps donné
pour que la page soit re généré c'est pour ça d'ailleurs que s'appelle la régénération inclementale
en gros si t'as généré un fichier statique en avec une visite ou via le build tu vas lui dire
tous les 300 tous les x temps en seconde tu me régénère la page tu vois ce qui fait que tu
peux avoir des rafraîchissements de contenu dans ton site statique automatiquement par contre
c'est c'est déclenché uniquement par une visite voilà ça ça ok après il faut le savoir que ce
truc est déclenché et tri en fait uniquement sur sur une visite en fait c'est assez hop c'est assez
au début on comprend pas trop comment ça fonctionne ça fonctionne mais le réveil en
fait la la régénération c'est à dire toi tu vas visiter la page t'auras le contenu le même
toujours mais en background il va générer une nouvelle page et c'est le visiteur suivant qui
aura le nouveau contenu parce que comme par contre si je fais refresh deux fois j'ai l'aura mais
comme il y a en fait il faut partir du principe que next retourne toujours du fichier statique
voilà c'est pas il va pas faire tourner notre pour générer l'html c'est vraiment il génère
des fichiers statiques et il retourne toujours des fichiers statiques donc c'est ça en fait c'est un
c'est un mix dans entre le statique et le dynamique c'est vraiment mais voilà c'est la solution idéale
en fait en tout cas pour notre cas de figure en fait c'était la solution quoi c'est
et du coup avec cette technique là est-ce que tu as pu baisser ton nombre de build enfin
ton temps de build est ce que tu as pu le réduire à manière significative en fait tu
en fait tu choisis en fonction de ce que tu vas générer comme page etc tu ton bid est
extrêmement rapide il peut en une minute même pas quoi en deux minutes je crois j'ai marqué dans
un article il ya une copie d'écran j'avais en deux minutes tu faisais le déploiement complet du
site avec 10 990 articles disponibles donc voilà tu réduis complètement et en plus avec la
régénération incrementale on peut même considérer que t'as même plus besoin de faire des builds en
fait puisque ça va générer automatiquement mais par contre est-ce que utiliser des techniques
comme ça comme comme next avec justement cette feature de régénération incrementale il faut
aussi que ton hébergeur le supporte du coup est-ce que tu viens pas réduire un peu ton scope
de potentiel hébergeur parce que là pour le coup tu est ce que c'est quelque chose que tu peux
implémenter de fois même sur sur ton propre serveur et ta propre stack où il pour le coup il te faut
une technique un peu particulière que tu vas trouver chez versel parce que c'est next derrière
enfin c'est next non non pas besoin en fait c'est juste un serveur de en fait il faut juste un
serveur de c'est la seule chose qu'il faut après sinon il n'y a rien de c'est comme je te dis et je
disais avant c'est vraiment pas du tout lié à versel après versel dit que bah leur service est
forcément optimisé pour next parce que c'est eux qui sont derrière mais je te dis ça tourne sur
si tu as un serveur nod tu le mets dessus ça marche donc ouais par contre tu perds alors c'est du
c'est du statique par contre c'est pas sur des cdn parce que tu as quand même une machine qui tourne
h24 pour générer ça donc ouais c'est du je suis d'accord que c'est pas du 100% statique comme on
peut le voir mais en tout cas aujourd'hui je pense que c'est la seule solution pour en tout cas moi
j'estime que c'est la seule solution après il y a eu des discussions ainsi que tel article voilà des
avec ugo etc voilà des gens qui sont plutôt ugo je respecte totalement l'outil et pas de soucis
après dans le cas de notre besoin là spécifique pour ce client une web app statique etc c'était
voilà pour moi c'est la seule solution aujourd'hui et tu penses que ça va encore évoluer ça ou
ou c'est ou enfin en clair à ma question c'est est-ce que on est encore en mode un peu expérimental
chez eux où c'est où la techno est suffisamment mature solide pourrait être implémenté sur des
sites de production enfin sur des sites en production avec des gros acteurs voilà des qui
ont une grosse pignante sur eux ou qui ont des contraintes de haute disponibilité tu vois je pense
à des gros médias principaux quoi je vois je vois pas enfin là la solution elle est totalement
mature parce que ça date maintenant ça fait un petit moment qu'elle ont sorti sur next et je vois
pas ce qui pourrait empêcher aujourd'hui quelqu'un de créer un gros site de médias avec ça quoi
je vois pas le frein c'est totalement viable c'est ça marche enfin c'est il n'y a pas de raisons
après tu vois next on attend toujours la version 3 qui sortira quand la quand vu 3 sera officielle
ouais puis après j'ai l'impression qu'ils sont quand même beaucoup beaucoup de travail alors
ils nous ont fait découvrir le moteur nitro on sait on sait pas encore totalement tous les détails
mais d'après ce que j'ai compris il y aurait un mode hybride équivalent à next qui pourrait
fonctionner sur next donc à suivre mais ouais à mon avis ça va beaucoup évoluer clairement et puis
ouais c'est enfin voilà ouais ça va vraiment vraiment encore évoluer en éco début clairement et
ah oui c'est ça que je voulais dire par exemple tu as l'équipe l'équipe le site c'est une web app en
temps il faisait tourner du réact avec du rendu serveur et là ils sont passé sur next il n'y a pas
longtemps il y a un an je crois et pour l'instant eux leur choix c'est le c'est le rendu serveur et
ils ont mis un système de cache devant justement pour éviter les trop de gros grosses les grosses
demandes sur le serveur parce qu'ils génèrent beaucoup de visites mais tu vois ils ont un genre
je pense que peut-être qu'un jour ils passeront si nuk se sort un système viable de statiques comme
comme next c'est pas impossible qu'il passe sur un truc comme ça quoi clairement bien sûr parce que
ça leur supprimerait toute la complexité du casque c'est tout ce travail d'optimisation de cache
quoi clairement yes bien complet cet article et ce petit retour d'expérience donc intéressant après
une fois de plus la techno c'est bien mais il faut bien comprendre les limites et trouver la techno
qui fit vraiment au plus près des besoins quoi et il n'y a pas de solution miracle ok cool
bah écoute un grand merci patrick pour ce retour d'expérience sur la génération des 11 pages on
peut retrouver l'article sur gemstatics.fr c'est un article qui date d'une 9 mars et là pour le
coup il ya toutes les stats les chiffres et tu viens tout tout expliquer donc super intéressant
merci patrick à bientôt ciao ciao
pas trouvé l'oubslash sur le plateforme de podcast préféré et sur le site internet
du podcast www.flash-podcast.fr sur le site vous allez retrouver tous les liens
d'épisode des références évoquées durant l'émission