Bonjour à tous et bienvenue sur ce nouvel épisode de Double Slash, le podcast indépendant
qui parle de développement web et d'IA.
Comme d'habitude, nous sommes avec Alex.
Salut Patrick, salut tout le monde.
Nous sommes encore au mois d'août et pour certains, vous êtes encore en vacances, donc
c'est cool pour vous.
J'espère que vous profitez.
On fait un petit épisode, on va parler de real time, c'est-à-dire que, tant en temps,
on a besoin d'afficher des data avec des rafraîchissements automatiques.
Je peux vous donner un exemple, par exemple, Uber, si vous êtes déjà dans un restaurant
retiré une commande, vous avez pu voir la tablette où s'affichent les commandes automatiquement.
Donc la personne ne va pas rafraîchir à chaque fois, etc.
Donc c'est ce qu'on appelle le rafraîchissement automatique en temps réel au fur et à mesure
que les commandes arrivent.
Donc on va parler de ça dans cet épisode et avec Alex on va parler de toutes les solutions
techniques qui existent.
Comment ça peut s'implémenter et les avantages et les inconvénients.
Ça te va ?
Oui, moi ça me va.
Je trouve ça super intéressant et j'ai pu implémenter ce système-là sur une vraie
application en production et je trouve que c'est super intéressant.
C'est vrai que c'est des protocoles qui existent depuis longtemps.
On connaît ce système-là, mais le fait que ta page bouge sans avoir à rafraîchir ta
page ou à faire une action quelconque de cliquer sur un bouton refresh, ça bouge tout seul.
Et c'est hyper intéressant et ça amène beaucoup de valeur pour le client.
Donc oui tu parles de l'exemple du restaurant, mais il y a plein de solutions aussi sur
les chats, des informations sur le trading, sur les informations qui sont mises à jour
toutes les secondes, toutes les minutes, sur le score en sport.
Par exemple toutes les actions ont été mises, on récupère un feed d'actualité au fur et
à mesure, mais aussi tout simplement la petite présence.
Est-ce que je suis connecté ? Est-ce que je suis présent sur les applis de chats ?
Et puis après on a aussi toute la partie de collaboration.
Aujourd'hui qu'on soit sur Notion ou sur Google Docs ou les choses comme ça, on voit le curseur
de l'autre et toutes les informations sont implémentées en collaboration.
Et donc en fait tous ces outils-là utilisent des fonctionnalités de real time et de temps
réel, de mise à jour en temps réel et c'est ce qu'on va essayer de découper pour bien
comprendre les tenants, les aboutissants, comment c'est fait techniquement.
Et donc c'est là où ça peut être super intéressant.
Après je te propose qu'on attaque tout de suite.
Je pense qu'on fait tous du GS même qu'on soit développeur, n'importe quel développeur
sur le web connaît ce système de d'event où il y a quelque part dans l'application
GS, il y a un événement qui est émis.
Donc c'est quelqu'un qui vient émettre un événement et de l'autre côté il y a un composant
ou une fonction qui va écouter cet événement.
Et donc en fait ce pattern là c'est la clé.
C'est vraiment la base de la base et c'est comme ça que tout le temps réel va se faire.
Sauf que dans le GS on n'est que dans le scope de notre page.
Donc la portée de notre événement qu'on va émettre va être vachement limitée et
c'est pour ça que tu connais mon amour pour Redis.
Je connais ton amour pour les bases de données.
Le mec ça devient une obsession.
Tous les deux jours il m'envoira j'ai trouvé cette base de données.
Ah j'ai trouvé ça.
Ouais mais en fait sur Redis c'est un protocole qui est en place depuis assez longtemps.
Et en fait l'idée c'est d'utiliser du pop sub en fait et à travers Redis.
Donc chaque client va se connecter au Redis et en fait tous les événements qui sont émis sur ce
channel là vont être envoyés à toutes les personnes qui se sont abonnés.
Donc en fait il faut voir ça.
Moi j'ai mis à utiliser le terme de channel dans beaucoup de librairies.
Ils utilisent d'autres termes genre des rooms.
Voilà en fait l'idée c'est vraiment de voir un tuyau quoi.
Il y a un tuyau qu'on va spécifier et toutes les personnes qui écoutent en fait ce tuyau là
vont récupérer tous les événements.
L'avantage de Redis c'est que ça va nous permettre d'être le fil conducteur entre deux applis.
Et donc en fait on vient mettre un tiers au milieu, un qui va émettre et toutes les personnes qui écoutent
vont recevoir cet événement là quoi.
Donc on va dire c'est le protocole le plus simple et le plus basique.
Par contre ça amène quand même assez plein de problèmes.
Parce qu'en fait il faut être sûr que si on aimait un événement il faut être sûr que les autres
l'ont bien reçu ou écoutent bien et qu'on ne perte pas la connexion ou ce genre de problème.
Donc c'est assez touchy et donc le gros problème du real time de toute façon
c'est être sûr de gérer la connexion c'est hyper hyper hyper important.
La perte de connexion c'est vraiment le point clé parce que c'est vrai qu'à un moment donné
si le client perd la connexion il n'y a plus de mises à jour et donc la seule solution c'est de
rafraîchir la page pour se reconnecter.
Oui mais si par exemple il y a un événement qui a été envoyé pendant le moment où
t'as pu être connecté.
Bah en fait exactement et en fait le protocole pub sub ok c'est super bien ça marche par
compte si il y a d'une business logic hyper importante et vraiment crucial ou tu ne peux
pas perdre cet événement là il va falloir que tu gères ton système autrement quoi parce que si ton
événement il est envoyé et personne l'a écouté il est perdu il n'y a pas de système de ritra
ou des choses comme ça au sein de Redis au sein de ce protocole là on peut pas faire ça donc
c'est vraiment je jette une bouteille à la mer en espérant qu'il y a des gens qui écoutent
vraiment donc c'est ça qu'il faut garder en tête.
Ouais après on peut imaginer que si imaginons une liste de news qui va se mettre à jour
automatiquement via le pub sub si jamais tu rafraîchis ta page parce que tu as plus de mises
à jour bah tu effectues une requête dans tous les cas donc tu auras les dernières news qui vont
s'afficher donc oui t'as perdu l'événement mais tu vas récupérer non ?
Oui, sous couvert en fait que tu as enregistré tes données dans une base de données et que ton
système en fait d'émission il est là-bas en fait sur la base de données.
Une fois que je l'ai enregistré en base de données là j'envoie les informations mais si par exemple
un petit malin se dit bah non mais moi je vais directement envoyer tous les événements bah en
historique. Et donc en fait il faut bien comprendre ce paradigme là pour en fait mettre plein de
sécurité et plein de... En tout cas le protocole pub sub ne se suffit pas à lui-même on est obligé
de construire autre chose par dessus pour pouvoir en fait avancer.
Comprène bien donc tu as la base Redis qui est au milieu là toi par exemple avec ton
bac tu vas envoyer des informations au Redis sur ce channel et donc ceux qui sont connectés vont
recevoir automatiquement les nouvelles informations au niveau du front c'est quoi y a une librairie
comment ça marche où c'est du code JS, custom. Alors en fait tu...
Ouais après si tu utilises en fait ton client Redis la plupart des clients Redis vont avoir
en fait une fonctionnalité en fait qui va gérer le pub sub donc ils vont pouvoir à la fois émettre
et recevoir donc par contre ça va être à toi en fait d'implémenter ce système là un peu à la
manneau quoi tu vois tu vas utiliser Redis et il va falloir que tu construis ta business logic
t'es tout autour de ce protocole là donc ouais et c'est pour ça en fait que potentiellement
ça peut être super intéressant de passer sur du server side event alors du serve du
lacronyme c'est SSE c'est ce qu'on va voir souvent en fait SSE toujours même délire c'est
unidirectionnel c'est à dire que le serveur va émettre des événements donc toutes les
personnes tous les clients qui ont voulu s'abonner sur sur sur ce sur ce serveur là vont pouvoir
s'abonner on va automatiquement enregistrer en fait toutes les personnes qui se sont
subscribes et à chaque fois que le serveur va émettre un événement il va envoyer cet événement
à toutes les personnes qui sont qui sont abonnés ça aujourd'hui il y a des il y a des choses
qui nous permettent de faire ça quasiment nativement en fait avec avec les dernières versions de
de nod à partir de jeu c'est plus combien mais les les events source en fait on va pouvoir
gérer gérer ça toujours même concept un serveur autant de clients possible et imaginable et donc
un exemple typique de de de business logique ou bah à chaque fois qu'il y a une nouvelle commande
par exemple la commande on la traite en base de données on l'enregistre et on envoie en fait les
informations à toutes les personnes qui sont connectées et qui écoutent le le channel en question
donc souvent en fait le client va on va on va faire un end point qu'on va appeler par convention
mais subscribes et après si on veut mettre une paramètre par exemple bah je vais subscribes à
les au magasin ou au restaurant x par exemple et donc bah cette fois ci quand il y a une nouvelle
commande qui va arriver je vais émettre un événement sur ce channel de ce restaurant là
le restaurant x et donc je vais envoyer une une information toujours garder en tête serveur
side event c'est du 1 l'heure n c'est le tout est centralisé sur le serveur donc autant de
clients possible et mais toujours un pour n quoi donc ça c'est du serveur side event et ça on
peut le faire aujourd'hui quasiment nativement en fait avec avec avec les dernières versions
de la douée et surtout alors c'est alors et c'est ce je vais pas trop regarder ce que
comment ça fonctionnait j'ai regardé un peu hier c'est le protocole htp htp donc c'est du natif
c'est exactement et c'est natif dans les navigateurs tout est la plupart tous les navigateurs le
prennent en charge donc c'est quelque chose qui est natif dans le navigateur que tu peux pas besoin
de librairie dans le navigateur exactement et donc là en fait tu peux facilement textraire en
fait de de redis parce que ce système là en fait et nativement fait par contre le comportement de
ton navigateur va être va vraiment être différent sur des reconnections automatiques sur des
connexions ou si ta table en fait elle est pas active et ben ils vont pas toujours écouter de la
même manière donc là pour le coup c'est c'est vraiment à nous de faire attention et de faire
des tests sur les dernières versions et de bien configurer les tous les paramètres de la connexion
htp justement dans les aideurs pour qu'en fait on garde la connexion active et qu'elles
se qu'en fait on crée un tuyau par contre si le navigateur coupe le tuyau ben clairement il
y a plus d'informations qui passe quoi donc donc le gros avantage c'est que on n'est pas obligé
d'installer un truc à part tout est natif par contre il faut quand même tester et bien valider le
fait que tout soit bien paramétré et il y a très très vite un côté un peu wow effect ça
marche tout c'est trop bien par contre quand on va dans les spécificités quand on commence à tester
des choses on se rend compte que ouais il y a plein de petites ajustements à faire pour vraiment
avoir un système hyper résilient et qui marche tout le temps quoi ouais alors dans la page mdn
qui explique un peu le le serveur sentiment il ya un exemple de code un php et en niveau du
header il met cache contrôle no cache et content type text slash évén d'stream tu vois donc
j'ai hâte il faut mettre des contente type particuliers je pense ça joue beaucoup là dessus
c'est le navigateur comprenne que c'est un stream et pas j'ai vachement intéressant exactement de
toute façon on mettra la la page dans les liens de l'épisode évidemment mais ouais ça c'est
ça c'est super cool nativement ça marche bien par contre faut bien bien bien bien bien tout paramétré
quoi sauf que alors c'est dis moi ouais pardon je trouve que c'est un protocole alors c'est un
protocole qui est natif tout ça comme on disait et surtout ça peut être pratique pour faire
le temps quand t'as pas forcément un hébergement qui te permet d'avoir un serveur socket ou des
choses comme ça ou tu es un peu limité tu vois exactement voilà donc ça c'est vraiment un protocole
intéressant le sse où tu as juste besoin de rafraîchir une liste de news ou d'infos ou de
trucs comme ça vraiment vraiment de commande même ça peut fonctionner mais mais après enfin
tu vois aujourd'hui on utilise beaucoup beaucoup des les lm et en fait souvent en fait les data
vont nous arriver au fur et à mesure ouais en string exactement et donc en fait bah ils vont
utiliser ce système là en fait du serveur site event pour dire ok j'ouvre une connexion sur
ces là sur ton prompt ton prompt j'ouvre une connexion dès que j'ai des infos je te les balance
bam bam bam bam bam je te les balance et à la fin en fait de où j'étais où le serveur a donné
toutes les réponses du llm je vais coup la connexion et donc et donc en fait c'est clairement à
chaque fois qu'on fait du chat gpt ou du ou en tout cas qu'on utilise un prompt clairement il y a du
event source il y a du sse en fait donc en fait on pourrait dire qu'on fait du qu'on utilise du sse
sans même le savoir parfois ouais sûrement c'est pas mal on a dit pop sub redis en premier sse
en deuxième ouais et après sauf que bah en fait ce qui est ce qui est ce qui est limitant en
fait sur du sse c'est que il n'y a qu'une seule source qui va émettre qui va émettre des informations
tout est centralisé sur sur le serveur donc ça marche par exemple quand je passe une commande ou
quand la formation quand l'information en tout cas est centralisé à un seul endroit sauf que quand
je veux faire de la collaboration ou de la détection de présence est ce que la personne est connectée
l'information en fait elle n'est pas émise par le serveur elle est émise par le client et donc là
en fait il y a un problème il nous manque des informations et donc c'est là en fait où le
websocket en fait un autre protocole vient pour pour nous aider et le websocket c'est du bidirectionnel
c'est à dire que chaque personne on va émettre on va créer un tuyau et chaque personne qui
s'est connectée à ce tuyau va écouter et va pouvoir émettre alors après on pourra mettre des
restrictions est ce que j'ai le droit de me connecter à ce channel là ou sur ce tuyau là est ce
que j'ai le droit d'émettre est ce que j'ai le droit d'écouter voilà il ya tout une un protocole
après par dessus qu'on va mettre d'autorisation mais on va dire nativement et et de manière très très
candid ce protocole nous permet en fait de faire du bidirectionnel c'est à dire que chaque client
en fait va pouvoir émettre et recevoir et c'est là la grosse différence avec le server side event
ou server side event 1 vers n en client et là le websocket c'est du n client vers un serveur
vers n client et on aurait tendance attention à ne pas mélanger avec des connexions en pierre
tout pierre c'est à dire une connexion entre moi et toi patrick là le websocket il ya bien une
identité centrale au milieu qui est le serveur websocket qui lui en fait va centraliser dès
qu'il reçoit des informations d'un client il va les envoyer à tous les autres clients donc c'est
ce qu'on utilise pour la collaboration sur sur google doc par exemple ou des choses comme ça
où la présence ou quand on bouge la souris là sur figma quand on travaille à plusieurs c'est
exactement ce ce protocole là ouais c'est alors bidirectionnel aussi tu peux aussi envoyer des
évènements du du bac aussi par exemple tu y a une action qui est faite un enregistrement et via le
contrôleur enfin si tu es sur du la ravelle c'est un contrôleur tu vas envoyer un évènement au
socket qui va renvoyer une info au client et en fait ton bac est considéré comme un client à part
entière ouais c'est vraiment l'avantage en fait c'est que tu peux envoyer des évènements
d'où tu veux en fait exactement la source peut être soit centralisé sur le serveur soit sur
sur n'importe quel client et c'est pour ça que ça marche dans tous les sens c'est pour ça qu'on
dit bidirectionnel quoi donc donc ça c'est plutôt bien par contre ça c'est pas natif on est même
si on est obligé d'utiliser des librairies pour gérer ce type de protocole là et de bien avoir
aussi un serveur en fait qui va gérer ça et qui va orchestrer tous ces évènements qui sont
émis par tous les clients et il va les dispatcher à toutes les personnes à qui de droit et donc ça
c'est c'est toujours voilà c'est faut bien comprendre que c'est pas natif il va falloir faire
mettre en place quelque chose il faut déjà pouvoir lancer un serveur quoi ouais bien j'ai
la possibilité de lancer un serveur bien sûr bien sûr et donc après la majorité des serveurs
aujourd'hui ont intégré ce protocole là donc ils ont des petites librairies qui par extension
en fait vont gérer ce protocole là et on va pouvoir passer des informations je pense on a
parlé tout à l'heure sur GraphQL en fait GraphQL toutes les toutes les actions en fait sont sur un
protocole HTTP les query et les mutations par contre dès qu'on va faire on va passer sur des
subscribes sur des subscriptions là en fait on va passer sur un protocole websocket donc donc
c'est là où on vient changer en fait de dimension et on parlait tout à l'heure de de de petites
librairies ou en tout cas que le serveur en fait doit être configuré pour ça et c'est vrai que
les petits serveurs nod avec une librairie qu'on connaît qui est très très connue qui s'appelle
socket.io qui est justement en fait le but de ça c'est de centraliser toutes ces informations là
et de les dispatcher à qui de droit quoi et en plus on peut mettre en place un serveur c'est assez
assez léger et assez facile à mettre en place quoi ouais ouais surtout que la librairie ouais ça
marche côté front et côté back donc c'est vraiment pratique c'est pas mal et ouais ce que
j'utilisais c'est que socket.io à la base c'était Guillermo Roche Roche Roche Roche Roche ouais
qui a créé une simple cellule qui a créé cette librairie donc Guillermo qui est CEO de Versel
aujourd'hui et c'est comme ça qui s'est fait connaître en 2014 puisque il y avait un article
blog qui dit voilà j'ai lancé la version 1.0 en 2014 juste après nod en fait finalement
top parce que là en fait c'est pas une surcouche qu'on vient installer sur un serveur c'est
vraiment un serveur socket.io qui utilise en fait le runtime.js pour voilà c'est vraiment mais hyper
hyper simple sur ok je viens émettre des événements sur le côté back et côté client je viens
écouter ces événements là et je réagis et je fais ce que j'ai à faire donc c'est une
implementation assez basique et assez rapide par contre on est dans l'univers js alors je connais
beaucoup moins l'univers PHP mais la ravelle a sorti une solution un peu tout un. Entre autres
tu peux le faire assez facilement sur la ravelle donc la ravelle reverb qui est un serveur web socket
que tu vas lancer à côté de ton application PHP et donc via ce serveur socket tu vas communiquer
envoyer des événements de ton application PHP la ravelle du bac du front tout ce que tu veux et
lui va gérer ça voilà et en front tu vas mettre la librairie echo.js je crois que ça
pète et qui va communiquer avec ce serveur voilà donc c'est hyper simple enfin en tout cas sur
la ravelle c'est plutôt simple à mettre en place et c'est assez puissant ouais t'as toutes des
fonctionnalités pour t'as des fonctions pour voilà envoyer des bounte tout ça pour la gestion alors
on n'a peut-être pas parlé encore mais la gestion des gens qui sont connectés parce que forcément
il faut envoyer des événements quand c'est des trucs qui concernent un utilisateur par exemple
des données bancaires ou quoi que ce soit tu dois cibler un seul utilisateur donc voilà il y a
ça aussi à gérer donc en tout cas ça se fait facilement sur la ravelle et tout ça on va en parler
dans l'univers de ruby en real c'est en fait il y a que ce qui s'appelle action cable qui est le même
concept en fait qui est de passer toutes ces toutes ces informations via du web socket et donc même
des liers de consommation après voilà chaque librairie va avoir son vocabulaire spécifique mais
c'est toujours un peu toujours la même chose on va diller la connexion on va diller les les
les consumers ceux qui vont consommer les les évents qui ont reçu des infos des informations
via des channels et on va avoir des émetteurs et voilà et on va envoyer des informations via
tout via les du pub sub pour pour pour la plupart donc c'est c'est toujours toujours le le même
système néanmoins en fait très vite quand on voit alors peut-être que la ravelle éco et je
connais pas ce cette librairie par contre on va très vite arriver sur des des problèmes à gérer
et un des plus gros problèmes et on l'a déjà évoqué c'est que le client doit se connecter
et doit garder cette connexion ouverte si pour x raison il a perdu en fait sa connexion
avec avec le serveur web socket il faut qu'il puisse se reconnecter quel est la latence de cette
reconnection tout ça c'est voilà ça doit être géré et c'est pas facile alors on l'a dit on peut
mettre des petits mots dans les aider qui vont bien le bon paramétrage des aider vont aider
énormément néanmoins c'est quand même pas super facile à faire mais il y a aussi comme tu l'as
dit de le séquençage des des des évents en fait pour pas envoyer trop d'évents plus que
nécessaire en fait pour être sûr que l'évente n'est envoyé qu'une seule fois sur une personne par
exemple si la personne est connectée sur son ordinateur est ce qu'on lui envoie sur son ordinateur
sur son ipad sur son téléphone sur sa montre tout ça voilà plein de choses comme ça qui pourrait
dire bah là en fait on l'a envoyé qu'une seule fois à le client qui est déjà connecté et les
autres qui sont en attente bah voilà ou en tout cas peut-être le l'ordinateur ou son appareil sur
lequel il est connecté il est établi la dernière connexion voilà toute cette genre de logique en
fait ou quand on commence à creuser on se rend compte que ouah c'est pas si facile que ça à
mettre en place et par exemple pour tout ce qui est trading par exemple ok on vient les on vient
enregistrer toutes les données par contre et au moment où il se reconnecte est ce que je lui
réenvoie toutes les informations est ce que ça vient de la base de données comme tu disais tu vois
c'est ok au moment où il se reconnecte je refais une connexion à la base de données et à partir de
maintenant la source c'est le websocket voilà toute cette business logique en fait de de de de
d'informations bah c'est à nous de la gérer quoi et parfois ça va engendrer des problèmes
techniques quand même assez assez rapidement d'autant plus par exemple sur des conflits d'état
par exemple sur google toi tu es sur la cellule à deux tu viens modifier à deux mais moi je suis
aussi sur la sur la cellule à deux bah en fait qui a la priorité tu vois qui gère qui gère ça et
donc est ce que c'est au protocole de au protocole d'informations de gérer ça est ce qu'on
vient séquencer les événements c'est à dire toi tu fais une modification on l'enregistre puis la
mienne est passe et on l'enregistre comme ça on peut revenir en arrière où est ce qu'on a perdu
ces informations enfin tout ça c'est des choses qui font que ouais dès qu'on creuse c'est pas si simple
en fait c'est pas si simple ah bah ça après le live comme on a sur comment ça s'appelle les
applications tu vas gérer faire des dessins en même temps tout ça machin là ça devient hyper
complexe ouais en fait t'as très très vite le côté wow effect tu vois miro oui c'est miro
cherchez miro miro exactement et c'est t'as très vite quand tu fais ton propre système t'as très vite
les faits ouah ça marche trop bien c'est trop stylé il y a les deux souris qui bougent tu vois
à estraël par contre quand tu te confrontes à la dimension business ou à une fiabilité à une
reconnection à l'historique des dates à des choses comme ça tu te rends compte que en fait ouais
c'est bien plus complexe que le bon new even source terminé tu vois c'est un petit peu plus un
petit peu plus poussé et c'est pour ça en fait qu'il ya des boîtes et du business qui se sont
mis sur ce créneau là pour justement en fait pouvoir proposer des solutions un petit peu out of
the box sans pour autant passer par la ravelle riverb ou socket point y'a où là en fait on va
avoir à gérer alors plus ou moins je connais pas l'univers la ravelle mais toi tu me dis qu'il y a
un peu plus de temps que c'est plutôt c'est plutôt top néanmoins en fait peut-être que je suis sur
du dotnet et il n'y a pas la librairie qui fait qui fait ça donc c'est dommage déjà tu es sur
les dottes net mais en tout cas il ya du il ya des services en fait qui des services tiers qui vont
gérer ça et qui vont faire lieu de justement de ce serveur en fait pour gérer les connexions
de temps réel et donc un des plus connus c'est poucher et ils ont même développé leurs propres
protocoles et tu verras et en fait on avait vu tout à l'heure que en fait que riverb en fait
utilise le protocole poucher donc c'est un protocole qui est alors est ce qu'il y a open source je ne
sais pas en tout cas il est il est plutôt ouvert et c'est toujours le même pattern et donc ça c'est
plutôt plutôt facile et on verra après pourquoi c'est super intéressant donc là c'est assez assez
simple à mettre en place on va choisir soit en PHP soit du nod et clairement on va ouvrir
un on va ouvrir une connexion on va se connecter un channel et on va émettre un événement voilà
et dans dans cet événement on va mettre le pélode qu'on veut et de l'autre côté en fait on va
s'abonner à ce channel et à chaque fois on va réagir à cet événement là donc assez assez
facile à mettre en place assez rapide et assez vite gratifiant parce que on va assez très très
vite avoir de la de l'un de un retour en fait assez immédiat évidemment c'est quoi les prises
le pricing donc ça c'est channel le pricing en fait on peut aller jusqu'à 200 000 messages par
jour sur la partie sandbox oui et non en fait et c'est le premier c'est le tuas le premier la
première réaction que j'ai eu c'est comme là c'est exactement pareil que toi c'est je me dis
ouais c'est pas si cher en fait c'est gratos on peut 200 000 messages c'est beaucoup sauf que
si tu fais une fonctionnalité ou quand tu bouges ta souris ah oui mais là c'est autre chose tu
vas à bain non je parlais des trucs de un fil de news un truc comme ça c'est un truc qui se
mêle jour tout seul et exactement en fait ça va dépendre de ta business logique tu vois et de ton
niveau de réactivité et donc pour certaines applications 200 000 ça va être juste énorme
et pour d'autres tu vas te dire ah ouais mais en fait non c'est pas si énorme que ça donc ce qui va
vraiment être limité en par contre c'est ton nombre de connexion c'est à dire combien de personnes
vont pouvoir s'inscrire s'abonner à tous les événements et donc là on est limité à 100
connexions c'est à dire il y a 100 personnes qui peuvent se connecter en même temps sur ce serveur là
dispatcher sur autant de channels que tu veux mais le facteur limitant pour moi il est plus
là sur leur sur leur fritière après si c'est une sorte d'un trinette tout ça que tu as 10 personnes
qui se connectent ça va tu peux aller à la centre exactement exactement et on est complètement d'accord
et donc ça c'est ça va dépendre en fait de ta business logique au final donc c'est cher et c'est
pas cher tu vois c'est après ça pique un peu quand même après tu passes de suite à 50 50 balles
mais tu as un million 500 après 100 balles ça va vite quand même les tarifs par contre exactement
500 là le scale coûte très très très très très très très très cher mais très cher un autre
un autre protocole non pardon un autre service qui va gérer aussi le un peu dans la même veine
qui s'appelle abhi et là en fait on eux ils nous introduisent en fait sur leur techno
vraiment avec des use case particuliers quoi donc du pop-up du chat de ce qu'ils appellent
le space donc c'est la collaboration le asset tracking voilà j'ai mon livreur amazon qui est
localisant en réel j'ai des actions à faire sur de la data voilà donc c'est une
implementation vraiment par par business logique de toute façon ils ont déjà intégré tous les
SDK côté clients les tous les SDK côté côté bac et donc voilà même des liens on est sur
sur du pricing ou au départ c'est pas cher par contre très vite à scale à scale ça coûte
très très cher là on est à 500 sur un peu ouais si tu remontes un peu je crois qu'il y a une offre
aussi t'allais package où tu peux payer au million de messages au volume tu vois par exemple je sais
pas t'as une application qui fait de l'événement de l'événementiel en fait tu vas tu vas pas payer
par mois en fait bah ta meilleure tende d'acheter un package de d'event et pendant deux jours tu vas
te faire déglinguer la tête et puis après bah il se passe plus rien tu vois et donc ce type de service
là en fait va permettre de mettre en place des choses comme ça donc voilà soit tu payes par
utilisateurs soit tu payes par autant en fait voilà après c'est à vous de regarder la plupart du
temps c'est quand même des solutions qui sont out of the box assez simple à mettre en place assez
rapide pas cher au départ par contre à scale qui vont très très vite coûter très cher à voir la
maturité et et le besoin je me devais quand même de parler d'open source ou en fait comme je l'ai
dit tout à l'heure le protocole push art est ouvert et donc il y a des personnes qui ont développé
en fait une un service en fait qui vient orchestrer ses applis et tous ces channels là directement
depuis depuis notre backend qu'on a déployé via un petit docker hyper simple pour ceux qui
utilisent qualifier il y a ces one click install donc au top et en plus ils y font même l'arrogance de
mettre le le le prix avec tous les deux pushers et deux ablis et combien ça coûterait quoi parce
que eux ils disent clairement on met ça sur un vps à cinq balles avant que avant que ça soit
limité et qu'on arrive à la limite technique de la saturation de la machine clairement il faut
y aller quoi donc à scale je pense que c'est une configuration qui peut être bien plus intéressante
et le gros avantage c'est qu'ils utilisent le protocole push art et comme la librairie de côté
fronte en fait de push art et open source et utilisable en fait bah t'utilise leur librairie qui va
gérer la reconnection et tout tout tout le package qui est intéressant et tu vas juste
substituer ton backend là où ils font de la tune quoi donc plutôt intéressant
complètement complètement parce que d'ailleurs le stop paying for expensive all time tout est dit
ça c'est les deux services qu'on a dit avant c'est après certaines entreprises ça va pas les
gênés de payer parce que voilà c'est normal mais c'est pas donné quand même alors là c'est vrai
qu'avec un vps même à cinq ou dix balles c'est arrivé à faire tourner un serveur websocket
pour ça ouais absolument mais en revanche je suis intéressant bien sûr mais on revient toujours
sur sur le même délire c'est qui orchestre ces serveurs là il faut les maintenir il faut les
sécuriser il faut les monitorer il faut tu vois donc c'est est ce que est ce que moi je préfère payer
et je ne fais pas chier tu vois et où je le gère moi même c'est toujours le même c'est ça c'est
si t'as ça dépend les compétences qu'on t'a un interne si t'as des des gars qui sont capables de
gérer un serveur oui si t'en as pas bah tu vas payer à blitz tout ça évidemment c'est clair
mais si tu sais gérer un serveur que t'as coup l'ifah et tu le mets en inclic et puis c'est fait
c'est ça non parlons pas de qualifier parce qu'il ya beaucoup d'attente sur
qualifier et on va le faire on va le faire patrick on va le faire ce workshop il ya beaucoup
d'attente là dessus et c'est super cool par contre si on veut faire quelque chose de bien
ça prend du temps et le temps et nous était compté autant toi que moi en tout cas moi
c'est clair c'était très compliqué j'arrive à réduire un peu ma charge de travail et donc c'est
parfait c'est parfait yes est ce que tu veux rajouter quelque chose sur ce réel time event
podcast sur le temps réel non c'est intéressant puis d'autant que moi le ssa je ne connaissais pas
trop j'ai du coup ça m'a forcé à m'intéresser à ça et c'est vrai que c'est plutôt assez puissant
pour un truc qui est natif donc c'est permettre de faire des choses assez simples rapidement
non après on a donc il y aura les notes avec plus de liens on n'a pas parlé de nitro si nitro
prend le websocket oui absolument et on peut on peut gérer ça sur sur un petit serveur nitro
attention par contre quand on vient héberger le nitro si on va dire par habitude vous avez
l'habitude de déployer vos applications sur versel ou sur netlify ou chose comme ça gardez
bien en tête que c'est du serveur less et que le serveur less la connexion n'est pas permanente
donc clairement le temps d'exception à un moment donné il va être coupé et donc et donc voilà
bien faire attention à ça je sais et j'ai lu que claude flair en fait gérer ce protocole là et
utiliser un système qui leur est propre pour gérer ce ce websocket donc si vous si vous
avez prévu en tout cas de faire du de l'event source donc du du sse ou du websocket et que vous
avez pas envie de payer des vps ou des serveurs spécifiques vous voulez utiliser le pricing de
claude flair qui est très agressif et que ça coûte quasiment que dalle c'est pas cher regardez
ça allez expérimenter et aller tester parce que je pense que c'est il y a peut-être moyen de faire
des pocs pas chers enfin voir gratos même sur la petite volumétrie et donc en fait on garde le
bénéfice du serveur less sans agérer toute l'infrastructure du du et et on a le bénéfice
du websocket et de l'instantanéité de la réponse donc ça peut être ça peut être super sympa
aller tester à les mettre en place ok yes top et bah écoute merci patrick pour cet épisode
on remercie aussi tout tout les personnes qui sont restées jusqu'au bout de l'épisode tous les
tous les personnes qui nous soutiennent financièrement à travers le github sponsor ou tout simplement à
travers les likes les commentaires les pouces et le partage des épisodes on vous remercie et
on revient très très très vite ciao ciao à plus ciao