• FR
  • EN
  • PourParler


    Beaucoup d’applications sont construites avec un tier gratuit et un tier payant mais parfois, même le tier payant n’est pas suffisant. Par exemple, lorsque l’on travaille avec du streaming vidéo, la bande passante et la puissance de traitement requise sont très élevées, donc la plupart des entreprises limitent la qualité de la bande passante et de la fréquence d’images, ce qui résulte en une qualité de vidéo très faible qui est très loin de ce que nous devrions obtenir de nos jours.

    Prenons un exemple, Twitch est un plateforme populaire pour diffuser des vidéos en direct. C’est l’unique but de cette plateforme et pourtant, elle a une limite de 6.000 kbps et 60 fps pour le flux vidéo. Les Macbook Pros ont des écrans à 120hz, les smartphones récents avec des écrans à 90hz et les moniteurs “gaming” ont également des écrans à plus de 144hz. Être limité à 60 images par seconde devrait être une limite matérielle et non une contrainte imposée par les entreprises.

    Me et mes amis utilisent Discord pour partager nos écrans, donc nous pouvons regarder chacun d’entre nous jouer en direct, mais même avec un tier payant, la qualité est encore très faible. Donc, j’ai décidé de construire ma propre plateforme de communication. Pas seulement pour améliorer la qualité de la vidéo, mais aussi pour la confidentialité, l’intégration avec d’autres services et plus encore.

    Ce fut également une bonne occasion de tester NextJS 15, React 19, TailwindCSS et WebRTC.

    Objectifs principaux

    • Streaming de vidéos haute qualité
    • Streaming de vidéos à haute fréquence d’images
    • Messages (envoi, modification, suppression)
    • Rendu du Markdown dans les messages
    • Connexion via un compte Discord

    Authentification

    J’ai décidé de tester Clerk pour gérer l’authentification. Clerk donne accès à beaucoup de fournisseurs d’authentification et de composants React pour gérer l’authentification des utilisateurs. J’avais envoie de l’oauth pour que les utilisateurs puissent facilement se connecter avec leur compte Discord. Comme ça, je n’aurai pas besoin de gérer la mise en ligne d’images et la gestion des comptes. Je n’aurai pas non plus accès aux informations personnelles de l’utilisateur.

    La seule chose dont j’avais besoin était un ID, un nom d’utilisateur et une photo de profil. Je n’avais pas besoin d’un adresse mail ou d’autres informations personnelles. C’est pourquoi j’ai arrêté d’utiliser Clerk. Le provider fournis par Clerk requiert deux scopes différents. Le premier est le “identify” qui donne accès aux données de l’utilisateur. Le second est le “email” qui ajoute l’adresse email aux données de l’utilisateur sur l’endpoint /me.

    Ce scope est optionnel et le fait que Clerk l’utilise rend le provider sans intérêt pour mon cas d’utilisation. Sur le papier, on peut créer un flow custom pour Clerk mais à ce stade, autant déployer l’authentification soit même. Ce qui est très facile avec Lucia.

    Le problème avec l’App Router

    Utiliser NextJS pour ce projet était en fait une mauvaise idée.

    L’App Router fonctionne en faisant un rendu des pages sur le serveur afin qu’elles puissent être servies plus rapidement au client. C’est génial pour le SEO et les performances lorsque les pages peuvent être principalement statiques mais ce système s’effondre lorsque vous avez besoin de construire une SPA.

    Puisque chaque page est chargée depuis le serveur, cela signifie que chaque changement de route doit renvoyer une requête au serveur. En utilisant la fonction de préchargement de Next, vous pouvez précharger chaque page d’un channel afin que le délai pour le changement soit minimal mais cela peut toujours être perceptible voir long pour des pages lourdes.

    La solution est d’utiliser un routeur côté client. Le contenu devrait être dynamique, mais les routes devraient être statiques pour le client. Une route dynamique devrait pouvoir être générée par le client en utilisant le contenu. Dans une SPA, la plupart du contexte de l’application est stocké et conservé entre les changements de route. Avant de migrer complètement vers React-Router, je vais essayer de changer les composants Link pour seulement pousser la route à l’historique.

    Tâches

    Pour le moment, voilà ce qui a été implémenté :

    • Authentification
    • Rendu Markdown
    • Création de canaux
    • Messages (envoi, édition, suppression)
    • Websockets (pour les mises à jour en temps réel)

    Image

    Je n’ai pas encore fait :

    • Modification des channels
    • Channels Vocaux
    • Streaming vidéo
    • Mise en ligne d’images
    • Emojis personnalisés

    Source

    https://www.github.com/oery/pourparler-web-client