Du temps réel sur ZdS

Bonjour bonjour !

Problématique

La ZEP-14 a soulevé la question du temps réel mais a rebroussé chemin au moment d'opter pour une technologie. De son côté, la ZEP-24 nécessitera à terme l'emploi de telles technologies, des notifications en temps réel étant fort appréciables.

J'ai donc commencé à recenser les technologies à notre disposition et ai fait part de mes réfléxions à Javier, lequel m'a judicieusement fait remarquer que je prenais les choses par le mauvais bout : plutôt que de réfléchir à une technologie, penchons-nous sur ce que nous souhaitons faire.

C'est donc l'objectif de ce sujet. Vous êtes invité à partager ici toutes vos idées d'évolutions pour le site faisant intervenir le temps réel. Alors, une fois que nous aurons un aperçu de ce que nous souhaitons globalement faire, nous pourrons opter pour la technologie adéquate.

Du temps réel ? Oui, mais où ça ?

Aperçu du message rédigé en temps réel (ZEP-14)

• Le client envoie son Markdown au serveur
• Le serveur le reçoit
• Le serveur convertit le Markdown en HTML
• Le serveur retourne le HTML au client
• Le client reçoit le HTML
• Le client affiche le HTML

Le tout sans recharger la page. C'est notamment ce que permet de faire AJAX : on parle de Remote Procedure Call (RPC).

Réception des notifications en temps réel (ZEP-24)

Cela implique d'indiquer en temps réel dans l'UI qu'un MP a été reçu, qu'un message a été posté dans un sujet suivi et autres joyeusetés prises en compte par la ZEP-24.

• Un client poste un message
• Le serveur reçoit la requête
• Le serveur stocke le message en base
• Le serveur enregistre les notifications générées
• Le serveur envoie une notification aux membres connectés
• Ces derniers reçoivent la notification, sans recharger la page

Cela implique pour le serveur de pouvoir faire du push, c'est-à-dire de pouvoir contacter certains clients de son plein gré (là où, dans le cas d'AJAX par exemple, il se contente de répondre à une requête). Il faut également identifier les clients en ligne concernés par cette notification.

Affichage des nouveaux messages lors de la lecture d'un sujet

Quand on envoie un message, on est parfois alerté qu'une personne a posté entre temps. Il pourrait être intéressant de l'être en temps réel, même si on ne rédige pas.

• Un client poste un message
• Le serveur reçoit la requête
• Le serveur stocke le message en base
• Le serveur indique à ceux consultant la page où le message va paraître que ce message est paru
• Le message est ajouté à la page consultée par ces personnes

Cela implique pour le serveur de pouvoir faire du push et d'identifier les personnes en train de consulter la page où sera ajouté le message.

De manière plus générale, le temps réel serait apprécié à chaque fois qu'il y a un phénomène de publication : nouveaux messages, nouveaux sujets, nouveaux contenus, etc.

Une application smartphone pour recevoir les notifications

A l'instar des notifications sur le site, on pourrait imaginer une application sur smartphone pour recevoir nos notifications en temps réel.

• Un client poste un message
• Le serveur reçoit la requête
• Le serveur stocke le message en base
• Le serveur enregistre les notifications générées
• Le serveur envoie une notification aux membres connectés
• Ces derniers reçoivent automatiquement la notification sur leur smartphone

Cela implique pour le serveur de pouvoir pousser de son plein gré une information vers une application autre que Web : Android, mais aussi de bureau par exemple.

À vous !

Ce ne sont que deux exemples d'évolutions faisant intervenir le temps réel. Je compte sur vous pour en proposer d'autres. Ne vous souciez pas de l'aspect technique : l'objectif est justement de le déterminer à partir des besoins que vous aurez exprimés.

Merci à vous et notamment à Javier pour ses retours sur ce message !

• Lorsque je lis un topic, ou pendant que je suis en train de rédiger une réponse a un topic, si quelqu'un poste un message avant que je n’envoie le mien, j'aimerai que le message s'affiche tout seul avec un marqueur (une cadre d'une certaine couleur) qui m'indique qu'il s'agit d'un message qui vient d’être posté.

C'est vrai que ça pourrait être hyper cool comme fonctionnalité ça ! Et bien pratique à la longue !

Le premier point fait en fait doublon avec la ZEP-24 mentionnée dans l'OP.

Pour le second, c'est une fort bonne idée. Je mets à jour le premier message.

Sur le même principe, on peut mettre à jour en temps réel le dernier message d'un forum quand on est sur la page des forums ou sur celle d'un forum en particulier. Mettre à jour en temps réel le style d'un sujet passé en résolu.

Mais aussi mettre à jour la PA en temps réel lors de la mise en ligne d'un contenu.

Premier message mis à jour.

Merci.

Bonjour à tous,

Je plussoie! Clairement ce genre de feature est très pratique, surtout sur les sujets d'aide qui nécessitent de longues réponses!

Pour la partie aperçu Markdown temps réel j'ai tické, est-il vraiment nécessaire de passer par le serveur, il y a plein de libs JS pour du Markdown aujourd'hui. Ou peut-être que le transpiler Markdown ZDS est spécifique et ne peut être utilisé que coté serveur?

Sinon pour ma part c'est vraiment les notifications sans recharger la page que j'apprécie, en début de journée j'ouvre mes quelques onglets (github et cie) et ensuite j'y vais que si j'ai des notifs. Ce qu'il serait bien de faire:

• Avoir un élément dans le titre de la page qui signale une notification, comme sur GMail par exemple. Slack si vous connaissez fait un boulot parfait la dessus avec des changements de titre et de favicon en fonction de l'importance de la notification. Si un message vous est adressé personnellement alors le fait que vous ayez des nouvelles notifs sera plus visible que si c'est un message dans un chan général
• Proposer (en opt-out) d'utiliser les notifications du browser ou de l'OS
• (Bonus): pouvoir choisir pourquoi et sur quel medium (push mail, application ZDS) je suis notifié. Exemple de cas "quand on m'envoie un message privé", "quand on répond à un thread que j'ai suivi", "quand on répond à un thread auquel j'ai participé", "quand on me cite dans un thread", ect.

Voilà ma whish-list au père noël

Ou peut-être que le transpiler Markdown ZDS est spécifique et ne peut être utilisé que coté serveur?

C'est surtout que le markdown utilisé par ZdS est "flavored". C'est un markdown un peu adapté aux besoins de ZdS.

Alors oui, c'est possible de faire un parseur JS, mais là c'est moi qui ça fait tiquer… Pourquoi dupliquer la logique ? Maintenir la même fonctionnalité à deux endroits différents pour des raisons purement techniques ? Quel est l'intérêt de la chose ?

Je n'y vois que des inconvénients. On voit déjà à quel point les évolutions dans le markdown sont pénibles à gérer, c'est Kje qui s'en occupe depuis le début, et (merci à lui) fait du bon boulot quand il a le temps. Depuis le début il espère que quelqu'un le rejoindra pour ne pas être seul à connaître cette partie du code de ZdS, et pourtant il est bel et bien seul sur une partir assez critique du site.

Et c'est cette partie (critique, délicate en terme d'implémentation et de perfs, fastidieuse à maintenir) qu'il faudrait dupliquer en JS ?

Euh, thanks but no thanks

En effet si le Markdown est flavored, alors ça serait dupliquer les efforts que de créer un parseur JS. La ou ça me fait ticker c'est que parser et compiler du Markdown est un traitement assez lourd, CPU-Heavy, et les aperçus temps réel vont générer un grand nombre de requêtes. La suggestion c'était pour éviter d'impacter trop négativement les performances du serveur.

Si le Markdown était non-flavoured, vous auriez pu utiliser l'une des nombreuse librairie OS en JS maintenue par un contributeur indépendant, ça vous aurait épargné la charge coté serveur et aurait été p-e plus simple à gérer coté client avec une API synchrone.

Même avec un Markdown flavoured, rien ne vous empêche de développer un parseur cross-environnement en Javascript. Coté serveur vous appelez votre parseur via Node.js et coté client vous utilisez le parseur comme une librairie JS lambda. Bon cette solution nécessite du temps, de revoir l'architecture, ect. En d'autres termes elle dépasse le cadre de ce simple thread mais c'est possible!

Voilà c'était juste une remarque dans le vent comme ça je me doute bien qu'il y a des contraintes dont je ne suis pas conscient et qui structurent les choix fait par l'équipe de dev' qui fait un très bon taf en passent

EDIT: si votre parseur est écrit en python et que la logique est assez isolée, vous pouvez aussi tenter d'utiliser un transpiler Python2JS il y en a une bonne liste ici

Nan mais des solutions y'en a plein, clairement. On peut aussi tout réécrire en utilisant la JVM qui permet de faire tourner à la fois du JS et du Python.

Mais là n'est pas la question.

Même avec un Markdown flavoured, rien ne vous empêche de développer un parseur cross-environnement en Javascript.

Si malheureusmeent, le temps et les ressources que ça prendrait, sans parler que le Javascript s'adapte assez mal à ce genre de trucs (là où Python, voire encore mieux : Haskell et consorts sont nettement plus intéressants).

On va se retrouver avec toute la stack en Python, le front en JS, et une partie du cœur du site en JS aussi, un langage où les contributeurs font défaut (contrairement à Python).

Pour moi ce n'est pas un choix raisonnable.

le Javascript s'adapte assez mal à ce genre de trucs (là où Python, voire encore mieux : Haskell et consorts sont nettement plus intéressants).

Ça c'est toi qui le dit, il y a un paquet de transpilers dans l'écosystème Web qui sont écrits en JS, dont l'excellente lib marked que j'utilise sur mes projets et qui est justement compatible browser et node. Mais on s'écarte du sujet

Pour le reste je comprends bien la décision que vous avez prise et au vu des arguments que tu as remonté elle est tout à fait logique. En tant que devs on est tous perfectionnistes et évangélistes les technos qu'on aime, d'ou mon "tickage" initial

C'est dommage pour votre manque de contributeurs en JS. J'ai vraiment envie de contribuer au ZDS et justement je suis très au point sur les sujets temps réel en JS (j'ai pas mal de notion de WebRTC et je bouffe du Websocket en masse, d'ou mon passage sur ce thread). Après comme tu le dis le temps est une ressource précieuse et nous en manquons tous quand il s'agit des projets bénévoles :/