Edge computing, le serverless à la sauce CDN

Durée: 42m52s

Date de sortie: 13/07/2022

Dans cet épisode nous allons vous expliquer les grands principes du Edge Computing, son fonctionnement et son utilisation. Retrouvez toutes les notes et les liens de l'épisode sur cette page : https://double-slash.dev/podcasts/edge-computing/

Bonjour à tous, bienvenue sur ce nouvel épisode de Double Slash, je suis Patrick et comme
d'habitude nous sommes avec Alex. Salut Alex !
Salut Patrick, salut tout le monde !
Donc aujourd'hui, épisode spécial, on va parler de Edge Computing. Donc qu'est-ce
que c'est le Edge Computing ? Alex tu vas nous en parler parce que tu es un peu plus
spécialiste que moi, tu as plus étudié la question. Donc je te laisse commencer, explique
nous ce que c'est le Edge Computing. Le Edge Computing, alors c'est le mot buzzword
qu'on voit un petit peu partout, tous les gros opérateurs commencent à l'utiliser.
Et en fait pour comprendre qu'est-ce que c'est le Edge, il faut comprendre l'évolution
du serveur less. Pour comprendre le serveur less, il faut remonter un tout petit peu avant,
alors je ne vais pas faire tout l'historique du web, mais on est passé en fait des deux
sites totalement statiques en mode 98.5, qui étaient directement dans notre navigateur,
qui était rendu par un serveur, la plupart un serveur fichier. Et l'évolution a fait
qu'on a toujours déplacé la complexité du serveur vers le navigateur, puis après
du navigateur vers le serveur. Et en fait, il s'est fait une sorte de spirale, en fait,
où chaque problème a été résolu en fait. Et donc le Edge Computing revient en fait
de solutionner un problème qu'on a maintenant, parce que l'évolution de la techno. En clair,
serveur monolithique, appli monolithique, tout est centralisé, on vient faire de plus en plus
de lib de front, donc là, ça rebasculent en fait dans le navigateur, ce mode de rendu.
Oui, sauf qu'on a un problème, il nous faut du SEO, donc il faut construire en fait ces pages HTML.
Du rendu serveur. Oui, il faut avoir du rendu serveur, donc on revient sur du serveur.
On revient en arrière. Oui, alors on revient en arrière où en fait on vient à apporter une
sorte d'évolution. Et donc le rendu serveur est passé d'un truc monolithique, après on a
eu les microservices, on a toujours des microservices, on a des infrastructures qui scale,
avec les dockers, les Kubernetes et tout ça. Très bien. Par contre, il y a une tendance qui
est sortie aussi, c'est du serveur less. Alors le serveur less, ce n'est pas qu'il n'y a pas
de serveur, mais c'est qu'on va uniquement exécuter une fonction, une simple fonction dans le serveur.
Sauf que ça a créé un nouveau problème, ce nouveau problème que ça a créé. Tout simplement,
moi je suis dans mon appui front, qui est distribué sur un CDN classique et je veux
faire un appel à ma fonction et cette fonction à ce service, elle va être exécutée quelque part.
La plupart des CDN sont géorépliqués. Donc on va avoir partout en fait, les mêmes données
vont être répliquées un peu partout sur le globe ou sur le CDN. Quand ma serveur less
fonctionne, elle va être toujours géocalisée par exemple. Elle est basée en Europe. Un exemple
typique, j'ai un compte gratuit chez Amazon, sauf que le compte gratuit ou chez un autre
provider, le compte gratuit n'est que aux États-Unis, sauf que nous on habite en Europe.
Donc ma serveur less fonction, elle va aller en Europe, elle va aller depuis l'Europe vers les
États-Unis, elle va revenir en Europe. Donc en fait, ça c'est déjà un problème,
en fait on va avoir une certaine latence en fait, dû juste au fait que géographiquement,
les serveurs ne sont pas au même endroit. Après on a un autre problème aussi sur le
serveur less, c'est que même si les opérateurs avec les grosses infrastructures font de mieux
en mieux, on va toujours avoir ce cold, ce qu'ils appellent le cold start ou la première
fois que tu vas stimuler cette fonction, il faut que tout se mette en branle on va dire.
Et donc ça peut amener un certain ralentissement. Donc si tu rajoutes à ça le fait que, ben
database, elle est aussi à un autre endroit, on vient rajouter autant de latence en fait et de
l'enterre. Donc tu veux dire, tu veux dire en gros qu'on a des sites qui sont rapides avec le
CDN parce que c'est répliqué et machin tout ça, sauf qu'à un moment donné quand tu appelles tes
fonctions qui vont aller chercher les data, quoi que ce soit, ben là, il y a du temps qui est pris
parce que forcément tu as pris un serveur Amazon à Francfort, ton visiteur il est aux États-Unis,
donc le temps que ça revienne, machin. Donc en fait, on a un CDN qui est rapide,
mais derrière les fonctions, elles sont l'emploi. C'est un problème.
Exactement ça. Et donc, autre problème aussi, c'est que ta serveur less function,
elle ne peut pas te rendre autre chose que du texte.
Oui, du JSON ou ce comme ça. Et donc ça, ça pose aussi un problème sur
qu'est-ce que je veux délivrer à mon utilisateur. Donc je suis obligé de passer par un autre
backend où en fait je ne peux pas tout faire en serverless, je vais avoir quelques contraintes.
C'est là où le edge commence à pointer le bout de son nez. C'est que justement,
on va déplacer ce serveur less. Au lieu de le mettre dans un data center classique,
on va le mettre au plus proche en fait de l'utilisateur. C'est pour ça qu'on appelle ça
sur le edge. Le edge, c'est vraiment le bord. Au lieu d'avoir, si on a un CDN en Asie,
en fait, c'est edge function, elles ne vont pas remonter en Europe pour redescendre en Asie,
elles vont rester en Asie, elles vont s'exécuter dans le runtime en Asie,
elles vont être exécutées et elles vont être rendues. Donc en clair, on va avoir un gros gain
de performance parce que ça va aller beaucoup plus vite et donc si ça va plus vite,
l'expérience utilisateur, on sera bien meilleur. En clair, si on veut simplifier et caricaturer,
le edge, les edge function, en clair, c'est du serverless au plus proche de l'utilisateur.
C'est un verre-less CDN en gros. En fait, j'ai ou répliqué et au plus proche de l'utilisateur.
Donc on va gagner de la vitesse et de la latence. Après, on pourrait aussi voir ça comme une sorte
de middleware au niveau de l'infrastructure. Et donc de l'infrastructure, ma requête va entrer
où va sortir, elle va passer par ces edge functions et donc je vais pouvoir faire exécuter des
informations et exécuter cette fonction-là au plus proche de l'utilisateur.
Parce que ça géolocalise en fonction de la ICA et en fait à l'appel, toi tu es en Asie,
alors je vais utiliser le server en gros. Exactement.
Qui est en Asie et pas celui qui est en Europe.
Exactement. Et en fait, qui aujourd'hui donne accès à ces edge functions ? C'est les mêmes
acteurs qui ont déjà du serverless et de la géoréplication. Et donc en clair, c'est les
mecs qui ont des CDN et donc c'est Versel, c'est Netlify qui sont vachement en avance là-dessus.
Cloudflare.
Parce qu'ils ont déjà une infrastructure géorépliquée, ils ont déjà des data centers
avec des CDN partout et donc qui leur annexe en fait ce petit runtime sur ces serveurs qui
sont déjà géorépliqués et comme ça l'utilisateur, en tout cas nous en développeur, on va pouvoir
déployer là-dessus et donc c'est expliqué géographiquement.
Parce que si je dis pas de conneries, Amazon, donc quand tu prends un truc Amazon, des serveurs
less, Amazon, enfin un système serverless, tu choisis une localisation. Parce qu'Amazon
fonctionne, en gros tu réserves une partie d'une machine en gros avec Amazon. Donc tu choisis
d'être localisé à tel endroit et en fait ce que font Versel tout ça, c'est qu'eux,
ils ont des machines qui sont réservées chez Amazon puisque derrière c'est Amazon forcément
AWS et donc grâce à toutes ces machines qui ont réservé un peu partout dans le monde,
ils arrivent à répliquer en fait tes fonctions dans les machines que eux, ils ont déjà.
Ce que je ne peux pas faire Amazon finalement. Amazon ne propose pas si je dis pas de conneries
de Edge en fait.
Mais après toi tu pourrais le faire.
Oui tu pourrais le faire.
En fait tu prends plein de serveurs et après t'amener en fait.
Mais faut faire un front qui va gérer la géolocalisation des gens.
C'est trop compliqué de le faire soi-même.
Si, si, si, ça se fait mais c'est beaucoup plus compliqué et c'est en ça où tout à
l'heure justement j'expliquais que le problème c'est toujours déplacer du navigateur à
l'infrastructure puis de l'infrastructure à la névigateur et à chaque fois. Je pense
par exemple au pub et tout ça, ils trouvaient des moyens pour de géolocaliser avec des
requêtes et tout ça pour t'afficher en fait des données qui étaient spécifiques.
Et aujourd'hui en fait c'est revenu côté infrastructure par ce biais des Edge.
Et donc en pratique au pratique, comment ça va s'exécuter ? En fait on va avoir
accès à un runtime.
Donc sur Netlify ils ont fait le choix d'utiliser Deno qu'on a présenté sur un épisode.
On a parlé aussi dans l'épisode sur les news. Et donc là on va avoir accès en fait.
On va pouvoir exécuter du code sur le runtime. Et chez Vercel c'est V8 avec ECMAScript et Web
Assemblis. Donc on a accès à toutes ces API qui sont...
On est sur les runtime JavaScript mais qui sont peut-être plus efficaces au call start en fait.
C'est ça ?
En fait t'as pas de call start parce que tu es au plus proche.
Non mais je veux dire parce que Node par exemple quand tu vas, c'est pas du Node ou quoi t'as pas
lancé ta fonction, c'est exécuter un JavaScript direct et ça renvoyer.
Oui absolument.
Et donc ça va nous donner accès en fait. Selon les opérateurs ça va prendre un nom
différent mais un contexte en fait. Et ce contexte là va nous donner accès à la
géolocalisation. Donc en fait on va pouvoir accéder quand la requête part. Elle va sur notre edge
et on va pouvoir déconstruire le contexte et on va pouvoir isoler la géographie.
Par exemple la ville, le pays et donc une fois qu'on a ces informations là on va pouvoir peut-être
rediriger ou lui afficher en fait des informations différentes selon l'opérateur,
selon la ville. Par exemple s'il est en France on va faire une redirection vers le site français.
Si il est en Thaïlande on va refaire la redirection vers le site Thaïlandais et ainsi de suite.
Donc en fait on vient déplacer cette logique qui était plutôt serveur. On la déplace sur
au plus proche de l'utilisateur. En tout cas on va avoir accès à cet API de géolocalisation.
On va pouvoir faire la même chose avec des cookies. Au moment où ça part on vient
injecter et utiliser des cookies. On va pouvoir aussi mettre surcharger les headers.
Par exemple donc ça c'est intéressant. On va pouvoir aussi utiliser en termes de proxy.
Par exemple on veut cacher des variables d'environnement ou des choses comme ça qu'on ne
veut pas exposer côté front. Ca va passer par ce runtime là sur le edge et c'est à ce moment
là qu'on va injecter les données comme ça en fait le client lui voit rien du tout.
C'est totalement transparent pour lui mais au moins nous on vient injecter des données pour
surcharger la requête. Pareil on va pouvoir faire de la redirection instantanée. Par exemple
ce que j'ai évoqué sur la géolocalisation ça bascule automatiquement.
Un truc qui pourrait être aussi super cool c'est faire du custom CSS ou en fait baser sur la
géologue ou sur un cookie. On a eu dans un premier cas où on pourrait injecter du CSS
différentier. On sait que les chinois aiment plutôt bien ça en termes de style. Les français
aiment plutôt ce type de couleur là. Donc en fait on vient injecter un CSS différentier selon
notre utilisateur. Ça peut être super intéressant pour ça.
Et une autre possibilité aussi que je vois c'est sur la validation. Par exemple un exemple
typique ou même si c'est mieux de faire de la validation côté front si pour X raison en fait
on ne peut pas le faire ou que sais-je au lieu d'appeler le serveur en fait ça passe d'abord
par cette edge fonction qui valide en fait qui valide toute qui fait une validation et qui
retourne si c'est pas bon si c'est pas correct cette validation serait fait beaucoup beaucoup plus
rapidement pour l'utilisateur et on vient taper le formulaire en fait serait exécuté la requête
à partir et au serveur uniquement les elles sont totalement full full valide ce qui nous permettrait
en fait d'avoir un serveur centralisé qui on vient minimiser la charge parce que en fait la
validation c'est fait sur sur le edge et au plus proche de l'utilisateur pour éviter pour éviter
de pas de de un de réduire la vitesse et de de surcharger ok donc il y avait une hox d'en
fait qui avait une somme fin dès le début ils sont partis dans un process de edge computing en
fait parce que je me souviens je me sais compilé avec comment s'appelle déjà le nitro qui te fait
un package en fait pour ton application hyper léger et que tu peux mettre sur clout flair sur
un sur du edge en fait donc exactement ça peut faire tourner aussi une application complète en fait
exactement et et c'est là où ça commence à être assez assez puissant c'est que tous les frameworks
mais même next aujourd'hui utilisent oui mais en fait peut utiliser ses edges ces edge
function ou justement soit on va le mettre en middleware et là c'est un middleware logicelle
mais qui va être déployé sur un middleware infrastructure on pourrait dire ouais en fait
quand tu déploie enfin je te coupe quand tu déploie une application next sur versel en
fait on a un fichier underscore middleware qu'on va mettre dans avec ton application et en fait ce
fichier middleware utiliser edge function et dans ce fichier middleware tu as accès justement à
ces données de géolocalisation tout ça en fait qui te permet de l'utiliser en mode proxy et donc
de pouvoir éventuellement rediriger les langues etc de en fonction de la géolocalisation et ça
c'est vraiment indiqué en edge function pour l'instant il me semble qu'il n'y a que ça qui
fonctionne il n'y a que le middleware qui utilise et je pense sur le fait de versel versel
la page ça explique un peu tout ça et donc comme j'expliquais c'est hyper hyper tributaire des
providers donc des versels des netlify après les frameworks deviennent justement essaye d'être
le plus agnostique possible sur justement sur leur sur leur rendu et là on voit ouais justement
netlify en fait ils ont leur ipi en fait et totalement ouverte et respecte en fait des
standards qu'ont été qu'ont été établies avec ben request, response et des trucs un peu
classiques justement sur lesquels on va pouvoir nous interagir et utiliser ce qu'on veut et ce qui
permet en fait de pour le coup de nukst 3 de toute la partie server elle est elle peut être déployée
automatiquement et ce en fait sans config le fameux configuration over non de convention
over configuration justement où on respecte on respecte la charte et on déploie automatiquement
sur netlify et tout tout ce qui est dans le serveur va être interprété en tant que serveur
less function ou edge function pour justement en fait gagner en efficacité et en performance je
reviens sur netlify parce que tu étais sur l'onglet alors ceux qui nous écoutent on est aussi
sur youtube en même temps et on a l'onglet netlify qui explique les edge function est-ce que netlify
en fait toutes les fonctions que tu utilises sur ton projet c'est passé sur du edge ou c'est où
faut spécifier que c'est du edge ou quoi non alors il est pour le coup il faut que tu le spécifie parce
que en fait sur ton edge tu vas avoir ta request et ton contexte mais si tu veux c'est pas tout à
fait la même API parce que les edge functions sont construites en dénaut et donc c'est pas tout à
fait la même parce que après je vois en dessous là ils ont le streaming edge rendering alors les
réactes serveurs component c'est un truc qui va arriver sur react 18 qui va permettre de rendre des
components directement via le serveur et donc là le edge function prend ça en compte c'est plutôt
pas mal ça veut dire que tu vas recevoir des components via une edge function que tu vas appeler
et ça va être à jour ton application et après il y a pas encore après moi ce que je vois
surtout c'est tout ce qui est SSR ou en fait au lieu d'avoir un gros serveur qui tourne enfin
un serveur qui tourne pour rendre une page l'exécution et ce rendu serveur en fait il va pouvoir être
au plus proche de l'utilisateur et l'expérience utilisateur est beaucoup plus rapide et surtout
aussi la développeur expérience parce que en fait tu n'as pas besoin tu as très peu de config à
faire et ça marche alors bien sûr que la magie c'est bien magie c'est bien de comprendre la magie
mais en fait ça nous évite vraiment beaucoup beaucoup beaucoup de complexité à gérer ça et
donc c'est beaucoup plus facile pour nous et tout le monde y gagne le dev y gagne et les personnes
enfin les utilisateurs en fait ils gagnent aussi ouais on voit sur là je reviens encore sur les
différents pages on voit effectivement dans le piscier de config là qui était un peu plus haut
dans la page d'avant comment il s'appelle déjà le tomeul là on voit edge underscore
function pour spécifier vraiment les edges exactement en fait tu vas tu vas être tu vas
typiquement déclarer ça je veux que ça soit interprété en tant que serveur les fonctionnes ça
je veux que ça soit interprété en tant que edge fonctionne ce qui parce que ça va pas répondre
vraiment aux mêmes besoins par exemple mettre sur du edge un appel de données à une base de données
en fait ça n'a pas de sens fin techniquement tu pourrais mais en fait pourquoi pourquoi faire ça
ce n'est pas fait pour ça ce ce n'est vraiment pas du tout fait pour ça et c'est là en fait
où on voit tous les exemples pour le coup qui sont chez chez netlify où on va répondre un simple
texte on va répondre à un gson qu'on a préformaté ou et c'est là c'est ce qu'on pouvait pas faire
avant en fait on va retourner une une image ouais et clairement si par exemple si dans notre contexte
en fait on est je sais pas stil en france on va envoyer le petit drapeau français et si on est
en au japon on va renvoyer le drapeau japonais quoi ça c'est genre de choses qu'on peut faire
directement sur sur le edge et on revient avec une image c'est à dire on c'est la fonction qui
délivre l'image chose qu'on ne peut pas faire sur sur du serveur les classiques en plus en termes de
en termes de vitesse ce que j'ai déjà vu des tableaux comparatifs de entre des différents
serveurs enfin fermes de serveur amazon en fonction des endroits et en fonction doutes appels la
fonction et ta vraiment des énormes différences en fait de réponse en millisecond c'est du simple
double ou même au triple donc mais en fait c'est pour ça que c'est toujours en fait ta première
solution donc on a résolu le problème des serveurs les où aujourd'hui on avait la jamstack
tout ça oui mais on a besoin d'avoir du rendu très bien il nous faut du rendu on va mettre sur
des serveurs les ok mais ça nous amène un autre problème en fait on a déplacé le problème et
même en même temps ça c'est c'est j'ai envie de dire c'est la vie du web quoi c'est on vient
déplacer le problème quoi on a plein de solutions mais au fur et à mesure en fait on on vient
se solutionner un problème qui nous amène à un autre problème et en fait on ne fait que déplacer
le problème et on trouve des et on trouve des des solutions pour résoudre bon après il y a aussi une
une je vais pas dire une hype commercial mais voilà ça fait ça fait nous ça nourrit tout l'écosystème
il y a cette aussi c'est besoin de de nouveautés où tous les développeurs sont plutôt friands de ce
type de tas et c'est un nouveau truc ça va révolutionner ou après les grandes révolutions
j'y crois pas trop voilà c'est c'est des changements de paradigme ça se programme sur beaucoup
beaucoup de temps mine de rien on fait quand même du code comme on faisait du code avant c'est
juste les outils les librairies qu'on échange et qu'on évoluait mais les fondamentaux en fait ça
reste quasiment toujours les mêmes par contre ce que moi ce que je vois c'est que c'est des outils
qui nous nous en tout cas nous facilite la vie et sont beaucoup plus rapide et juste le fait de pouvoir
déployer alors je pour ceux qui ne savent pas je suis pro vu et pro nukst mais dans la version 3
comme tu disais tout à l'heure le serveur nitro j'ai pouvoir déployer mon framework
back end en fait moi pour moi il est il est il est il est totalement full full back end enfin c'est
à dire que je vais pouvoir le déployer sur un cdn qui est normalement un multi plutôt front et là
il va être automatiquement interprété en tant que serverless ou et je fonctionne et pour moi j'ai
même pas besoin de configurer et donc c'est il s'est optimisé en fait par nature parce que les
mecs ont codé ça ils ont déjà optimisé ils ont fait le boulot de me faciliter et que l'expérience
soit la plus fluide pour moi la plus facile et la plus fluide pour les développeurs et en même
temps bah pour l'utilisateur parce que c'est l'utilisateur qui va avoir ce gain en fait de
performance ouais ouais mais ça pour ça pour ça nukst ils ont été très très fort c'est ouf
mais c'est ouf ouais ils ont été vraiment visionnaires à ce niveau là parce que c'est vrai
que quand ils ont commencé à parler de nitro tout ça c'est pas chien choupe un tout ça il parlait
de nitro et tout parce que moi j'étais plutôt dans le dans le mode classique statique etc.
régénération machin tout ce qu'on a sur nex et tout un peu compliqué et ils ont pris partie de
nitro en fait de pas 4g de bilder de pas 4g est en application et en fait ils enlèvent le
nôtre module sous ça donc ça tourne pas sur notre c'est du javascript et en fait ça c'est
capable de tourner en fait juste avec du javascript donc sur du edge ça n'a pas besoin d'un server
note ça pas besoin de tout ça et c'est hyper optimisé et c'est minifié aussi et en fait
l'application nukst elle est incroyablement petite et tu peux la mettre ou tu veux en fait ils ont
été très très bons là dessus en fait et surtout il là où moi je trouve oui c'est un important
c'est que verselle en fait et next on une implication très très forte parce que bah
il y a un qui finance l'autre donc et puis fin c'est assumé là où pour moi c'est intéressant
sur sur nukst justement c'est qu'ils vont être totalement plateforme agnostique ou à dire tu
veux déployer sur verselle bah tu déploies sur verselle tu veux déployer sur netify tu déploies
sur netify sur cloptère tu déploies sur cloptère sur stormkit voilà et et c'est là où c'est encore
plus puissant parce que il nous on va dire qu'il nous tordent pas le coup en disant ok là il va
falloir que tu utilises tel techno tel provider et c'est là où pour moi c'est c'est assez fort et
là où et là où c'est encore plus fort c'est que moi j'en ai parlé dans un épisode dernièrement
mais next par exemple tu peux pas le déployer ou tu veux il y a des spécificités qui font que le
provider il doit prendre en charge next machin la version 12 etc ce que t'as pas du tout là
nukst avec le nitro nitro tu le mets ça tourne donc pour ça excellent beau travail de l'équipe
et carrément carrément et est-ce que parce que là j'ai l'impression que netlify est un peu plus
en avance sur le edge computing que les autres ou après chez les deux voilà après je pense que
les deux netlify et verselles sont sont très très très très très bons communicants ils savent très
bien faire pour comment communiquer là dessus donc même s'ils me semblent que c'était claug flare les
premiers à vraiment c'est possible après tout l'écosystème de chez claug flare a bien bien
bien évolué donc c'est clairement clairement mais savoir lequel est le plus performant le
je sais strictement rien par contre de comprendre le concept en tout cas sur netlify ils ont une
des exemples qui sont assez assez parlant justement pour mettre en place des cookies des
une sorte de géologue ou même d'écrire un un log voilà on va pouvoir écrire vu que tout passe
par ce middleware les logs là tu peux faire l'exemple s'il te plaît et tout simplement en
fait au lieu de faire un console log on va faire un contexte log mais moi ce que je vois aussi
c'est que tu peux tu peux peut-être aussi utiliser pour forward donc tu tu tu continues tu
pousses en fait la requête là où tu veux mais tu viens enregistrer ta tu viens logger ta requête
avec toutes les informations que tu as et elle est automatiquement géolocalisée je pense sur
des analytiques par exemple ça peut être super intéressant ou tout passe par ces etes fonction
ce qui permet en fait d'extraire le contexte et la géologue de devenir logger ce que tu as besoin
de logger mais bah le plus proche en fait de l'utilisateur et surtout que ça ne freine pas
son son expérience de navigation quoi donc ça c'est c'est vraiment hyper hyper intéressant il
s'en servent aussi à faire des abe testing et oui pour justement baser sur sur des sur des abe
testing soit de géologue soit avec des cookies soit avec avec plein de choses mais intéressant
pour tu vas tu vois au walk là ça met un nom dans un coup par exemple un nom de bucket dans un cookie
et en fonction du cookie il va rediriger sur a ou b en fait a priori c'est ça quoi donc ça te fait
une sorte de proxy tu passes par là et détermine si toi tu vas sur le a ou sur le b en fait donc c'est
du vrai c'est du vrai proxy où tu peux pour le coup tu peux même rediriger vers une url que tu
veux pas en fait que tu veux cacher bah là pour le coup tu tu réécris en fait la oui tu peux
imaginer une application qui est disponible que pour une certaine ip et d'entreprise
quand tu vérifie que l'ip correspond si ça correspond pas tu rediries sur un erreur ou sur
la bonne application exactement et exactement après en fait ce qu'il faut comprendre c'est que ça
vient pas tout solutionner il y a toujours moyen de faire ça autrement tu vois toutes ces c'est
cette validation ce proxy tu pouvais le faire côté serveur bon bah ok pourquoi le faire aujourd'hui
sur sur le edge moi je pense que le plus un le plus intéressant c'est ça reste la performance
et l'utilisateur final où on est en fait au plus proche de lui donc on vient réduire ce temps de
cette latence et cette latence et aujourd'hui tout le monde tout le monde est d'accord pour dire que
la performance c'est important et donc ne pas se concentrer sur sur la performance c'est c'est
je pense une grave erreur après tu es après dans le cas où tu es vraiment un site internet
franco français ou ta queue des visiteurs français bon est ce qu'il y a vraiment l'intérêt d'aller
sur du edge je suis pas sûr mais après c'était une visée internationale là il y a vraiment
l'intérêt d'être sur du edge et d'être vraiment au plus près ouais pour répondre aux fonctions
ouais après moi j'ai j'ai je reste toujours sur sur cette idée qu'un developer de front
en fait parfois il n'a pas envie de se fader un bac pour des toutes petites actions néanmoins il va
quand même avoir besoin de son rendu d'avoir un runtime à un moment donné un exemple typique
c'est envoyer un email bon je vais utiliser une serverless function c'est quand même super pratique
et là je vais pouvoir le faire directement depuis netlify j'ai pas besoin de développer tout mon
backend avec la structure le build le payer le serveur qui tourne à 24 pour envoyer trois
mails quoi donc donc moi je vois ça quand même ça ouvre en fait c'est comme tout c'est un outil
est ce que ça fit avec tous les projets je ne pense pas en tout cas des personnes qui utilisent
serverless function et qui veulent justement faire de la validation de la géologue et de
répondre au plus rapide à leur utilisateur je pense que les edge fonctions prennent vraiment
leur place pour moi l'usage parfait c'est le rendu serveur voilà c'est c'est c'est le truc parfait
ou justement bah tous nos frameworks ont évolué de frontes
où on fait du client site rendering après il nous faut du server side rendering et bah là on
va faire du server side rendering sans serveur et au plus proche de l'utilisateur donc c'est top
quoi enfin moi je vois vraiment je vois vraiment ça comme un gros gros gain pour l'utilisateur et pour
le y a avec nukst et aussi je sais qu'il y a un truc il y a une libre pour next qui existe qui
permet de faire ça en fait qui compile sans les dépendances nobles et tout qui compile tout en
package je sais plus comment ça s'appelle mais c'est disposé et après objectivement tu peux tu
peux aussi construire directement ton html dans ton fonction qui répond à html carrément dans ton
html et donc en fait bah tu tu tu tu supprimes ton build ton build de ton application quoi parce
que ton build il est composé il est il est exécuté directement sur sur switch fonctionne quoi ouais
si tu veux faire une simple page bon après des fois est ce qu'il y a vraiment besoin bon bref on va
par entrer là-bas ouais après c'est comme tout est-ce qu'on est sur une high il faut foncer tête
bc en mode il faut tout faire comme ça je pense que ça sur certains projets ça mène une réelle
plus value sur d'autres ça n'a pas de sens quoi c'est une fois de plus ce n'est qu'un outil
et niveau niveau tarif est-ce que c'est beaucoup plus cher ou pas non ce n'est pas plus cher et
je crois exactement je crois que je vais aller regarder ça on est sur des de nombre des séctions
beaucoup beaucoup beaucoup plus élevés que les serveurs les fonctionnes en fait sur sur netlify
par mois on est à 128000 exécutions de serveurs les fonctionnes alors que sur le edge on est à
3 millions 3 m ça va donc pour le coup en fait je pense que ouais moi faire du du du du
SSR on n'a plus besoin de passer par autre chose quoi alors après attention attention dit moi alors
déjà attention parce que en fait le pour avoir utilisé le middleware de next il faut comprendre
que chaque requête passe par le middleware c'est à dire que chaque image chaque le fabicon etc
chaque requête passe par donc ça va vite ça fait vite du chiffre en fait je vais les croquer je vais
les croquer après sur le mois combien ça fait d'appel mais ça fait 3 millions ça peut sembler
beaucoup mais attention parce que sur une visite par exemple tu peux vite avoir 150 requêtes rien que
pour afficher une page donc ok donc après le fait d'en avoir 3 millions ça veut aussi dire par
rapport au serveur de la fonction dans la 525 mille ça veut dire que le edge fonction est beaucoup
moins gourmand en ressources écoute beaucoup moins cher aussi peut-être je sais pas je sais pas après
ça c'est leur calcul et j'ai pas assez d'historique ils sont généreux sur des providers exactement ils
sont généreux après est ce que ils incitent est ce que c'est incité à passer sur des nouveaux
et des nouveaux builds ou des nouvelles manières de faire est ce que c'est justement parce que tu
vas tout croquer et tu vas croquer beaucoup qu'ils sont généreux je sais pas du tout on pourrait
regarder chez versel pour voir ce compliqué tu as réussi versel je te prie ça devient complexe
il y a pas de réfondes ils ont tous tous tous tous tous des des des des des questions un peu plus haut
qui deviennent un peu plus bas alors oui on va 500 mille par jour à 100 mille et 500 mille par jour
ouais 100 mille sur du sur du hobby le hobby c'est pas gratuit c'est pas gratuit mais quasi
c'est après ouais parce que c'est un peu de versel tu as pas de compte gratuit comme netlify
tu as un compte qui coûte pas cher mais écoute écoute un petit peu mais tu payes mais en même temps je
pense intimement qu'on fin je reste convaincu que la culture du tout gratuit ça c'est limit ça
aussi c'est limite exactement et on en parlait déjà sur sur du support ou en fait quand tu
payes pas tu comment tu peux avoir du support enfin je veux dire c'est normal tu payes pas donc tu
peux pas être gratuit c'est bien pour les comme il marque les hobbies voilà les projets pour s'amuser
tout ça mais dès que les projets sérieux faut bien considérer qu'un moment donné faut payer parce
que c'est comme ça quoi puis de façon tu fais le business donc toi si tu rentres de l'argent il faut
payer derrière ton infrastructure et puis et puis et puis enfin et puis ouais mais surtout c'est qu'il
y a une infrastructure de derrière il ya des il ya des vrais services et ce que je vois que
versel et netlify propose ça vient se solutionner et faciliter et fluidifier le travail d'un dev front
mais de ma boule et alors je sais pas la première fois que je le dis mais frontise de new back avec
avec tous ces nouveaux frameworks verset next ou next la la frontière entre les deux et le
déploiement entre les deux devient encore plus facile quoi donc j'ai besoin d'avoir un petit
serveur qui tourne bah je vais le déployer sur versel ou sur netlify grâce à ces frameworks
là qui sont full stack maintenant c'est facile quoi et donc non ça mène une grande grande grande
plus-value indéniable quoi indéniable carrément ok ouais super et ouais donc maintenant il faut
plus qu'il nous reste plus qu'à utiliser les les etes fonctionne et pour tester tout ça et utiliser
noks bien sûr évidemment et bien écoute merci patrick merci à tous d'être resté jusqu'au bout
de l'épisode pensez à mettre le petit like mes commentaires et venez ouais venez nous dire
ce que vous en pensez de déage fonctionne si on est dans une hype ou à quoi vous avez à quoi vous
pensez pouvoir l'utiliser un grand merci à tous ciao ciao de la base retrouver double slash sur
la forme de podcast préféré et sur le site internet du podcast 3w point slash tiré podcast
et faire sur le site vous allez retrouver tous les liens d'épisode les références évoquées durant
l'émission

Les infos glanées

Je suis une fonctionnalité encore en dévelopement

Signaler une erreur

DoubleSlashPodcast

Double Slash, un podcast sur le développement web. Retrouvez-nous régulièrement pour parler de sujets variés tels que la JAMStack, l’accessibilité, l’écoconception, React.js, Vue.js, Next.js, Nuxt.js, le CSS et des retours d’expériences sur des implémentations.
Tags
Card title

Lien du podcast

[{'term': 'Technology', 'label': None, 'scheme': None}, {'term': 'Technology', 'label': None, 'scheme': 'http://www.itunes.com/'}]

Go somewhere