ZEP-24 : Refonte et enrichissement des notifications

OK mon message n'était pas clair. Désolé.

En fait j'ai cité SockJS parce que c'est un protocole, pas une lib client. Je ne suis pas en train d'opposer implémentation client et serveur là, juste de prendre les deux en considération, et pas m'arrêter à "c'est plus facile côté serveur".

Le truc, c'est que les websockets (et le HTML 5 Socket-Send-Events) ne sont malheureusement pas encore supportés par tous les clients. Notamment Android Browser et IE <= 9.

D'où la nécessité de pouvoir dégrader le fonctionnement du push proprement sur des navigateurs qui ne les supportent pas. Et attention, j'ai pas mis Cordova / PhoneGap dans l'équation parce que je connais pas leur support sur ces technos mais faut y faire gaffe aussi, on a fait une API principalement pour les mobiles, les notifs ça me paraît aussi être très intéressant pour les clients mobiles.

SockJS permet de dégrader proprement les websockets (notamment en utilisant du "long polling" HTTP classique) et ce, sans que tu n'aies à toucher une seule ligne de code dans le client ou le serveur.

En ce qui concerne les SSE, je ne les ai jamais utilisées pour une bonne et simple raison : j'ai toujours besoin que le client envoie des données au serveur, ne serait-ce qu'un jeton d'authentification (client mobile, extension Chrome, bref des problématiques qu'on a aussi sur ZdS) pour que je sache qui il est. J'ai jamais essayé mais j'imagine que dans le cas où la page est servie côté serveur ça doit être contournable, mais dans le cas d'une app mobile, si le client ne peut pas pusher au moins son jeton je vois pas comment ça peut fonctionner.

Voilà, j'ai parlé de SockJS et de websockets parce que je les utilise quotidiennement en production, je sais que ça fonctionne, que c'est performant, et que ça correspond aux besoins de ZdS. J'ai absolument rien contre un POC sur plein de technos différentes, mais si j'ai pas parlé de SSE c'est parce que je comprends pas comment ça pourrait convenir à dire "Hello, envoie mes MPs stp, je suis M. XXX, ah, et puis envoie moi aussi les tutos aussi, mais pas les notifs sur les cours ça m'intéresse pas", bref du pub/sub classique, qui nécessite que le client envoie une liste de topics auquels il souscrit.

Et si j'ai parlé de SockJS, c'est aussi parce qu'il me semble que ça provient du monde Python à la base et que ça me semblait "classique" de plugger ça sur Django (y'a une autre implémentation mais je vois pas ce que Redis vient faire là-dedans…) et qu'on n'était pas les premiers à le faire.

Mais encore une fois, je ne suis pas attaché à une techno particulière, si t'as un POC qui fonctionne avec les SSE vas-y, ça m'intéresse vachement !

Ha non moi j'ai aucun poc pour zds. Juste j'ai dut faire ça hier et j'ai fais des requetes "à la Ajax" pour envoyer des données depuis le client et j'ai utilisé SSE pour recevoir des données. C'est donc simplement un test simple que j'ai fais et qui marchait bien a moindre coup (coté serveur c'est uniquement une route HTTP/GET classique, coté client c'est 3 lignes de JS).

Je proposait juste cette solution parce qu'elle n'avait jamais été mentionné et du coup j'étais étonné. Encore une fois je ne suis pas dev web, pas du tout même, donc c'est aussi par curiosité. Les Websocket me semblent beaucoup plus lourdes mais il y a probablement des raisons si la majorité utilisent ça.

NB qui n'est pas directement lié : Pour moi le push des notifs sur page web n'est pas forcément un must-have, entre autre sur mobile qui pourraient plutot avoir des appli dédié. Pour moi, quelque soit la techno, si le navigo ne supporte pas le push, tanpis ça n'empeche pas d'utiliser le site. C'est le genre de fonctionnalité utile surtout pour les habitués qui ont tous probablement des navigateurs à jour.

et j'ai utilisé SSE pour recevoir des données

La question c'est comment, côté serveur, tu sais à qui tu push ces données. C'est le nerf de la guerre là.

En l'occurrence moi je n'ai pas ce soucis mais chaque client souscrit à un flux avec un GET http. Du coup à ce moment là tu peux savoir qui est l'utilisateur.

Pour les websockets, peut-être la stack WAMP/Crossbar.io/Autobahn serait-elle utile. Avec possibilité de push : http://sametmax.com/un-petit-dashboard-de-monitoring-avec-django-et-wamp/.

N.B. : très peu expérience en la matière. J'espère ne pas proférer d'ignobles bêtises.

Je pense que ce débat devrait avoir lieu dans un autre sujet.

Hello,

La seule question qui reste en suspens est donc à propos des websockets. De mon côté, j'ai commencé un POC et je commence à avoir quelque chose de sympa, même si je me pose pas mal de question sur l'implémentation que j'ai choisie.

Je pense passer cette ZEP au statut "acceptée". Andr0 a proposé de m'aider à développer tout ça, je pense qu'on verra plus tard pour rajouter un mécanisme de push (j'y connais absolument rien aux websockets et j'ai pas l'impression qu'il soit indispensable de prendre ça en compte directement). Si quelqu'un a une objection, qu'il se manifeste maintenant, ou se taise à jamais ^^.

Si quelqu'un d'autre veut aider au dev, qu'il me le dise, on discutera par MP pour mettre tout ça en place

Je veux bien aider pour cette ZEP ! Je sais pas si je coderai beaucoup mais je ferai au moins de la revue de code

Si tu peux repousser le push, fait le. C'est pas indispensable et les fondements de cette zep sont plus important.

Comme je l'avais dit au début du topic, dans tous les cas il faut une API, même si à terme il y aura du push.

En première approche, les clients peuvent faire du polling pour faire du "presque" temps réel.

Une remarque par contre sur le code. Il faudrait juste prendre en compte le fait qu'à terme il pourrait y avoir une seconde façon de notifier les clients. Et du coup, de raisonner POA en disant : "tel endroit dans le code déclenche l'envoi d'une notification de tel type". Et qu'on puisse greffer par la suite plusieurs implémentations (greffons) sur un même point d'interception. (D'abord : insertion d'une ligne dans une base Sql, puis : push dans une socket, …).

Mais qu'en gros l'implementation du système de notification ne soit pas "en dur" (en gros assez découplée).

Il me semble qu'avec python on fait ça avec des décorateurs, et je crois que Luthaf avait parlé de "middleware" dans le monde Django. Sans garantie mais je crois que c'était ça.

Django semble proposer des signaux, je pense que ce serait le genre de chose auquel tu pense, non ?

Ouep, ça a l'air d'être ça

Très sincèrement, aujourd'hui, les notifications sont presque inexistantes du côté technique. Il n'y a même pas un module consacré à ça, il n'y a qu'une pauvre méthode statique utilitaire qui s'occupe de créer un objet pour représenter une notification. Le développement de la ZEP va donc partir de très loin puisqu'il y a tout à faire.

Oui, le push est une fonctionnalité intéressante que j'aimerais bien voir intégrer au projet mais je pense que c'est très prématuré, voire même qu'une ZEP entière devrait y être consacré. Aujourd'hui, dans le développement de cette ZEP, nous embarquons Taguan qui est jeune contributrice du côté technique de Zeste de Savoir, Situphen qui veut s'essayer au côté back-end qu'il ne connait donc pas du tout et moi qui ne maitrise pas plus que ça Python, encore moins Django.

Je pense donc qu'il faut calmer les ardeurs sur le push et en discuter sur un sujet dédié pour éviter de surcharger les jeunes contributeurs de cette ZEP.

Bien, j'ai passé la ZEP en "Accepté", contacté Situphen et Andr0 par MP et démarré le développement. On va essayer de faire ça bien Stay tuned !

Salut tout le monde,

Ca fait un moment qu'il n'y a plus de nouvelles sur cette ZEP. Taguan ne disposant pas de beaucoup de temps pour faire du feedback en ce moment, c'est avec plaisir que je viens vous donner des nouvelles. Et les choses avancent plutôt très bien !

Taguan a d'abord déblayée le terrain : Elle s'est documentée et à tester des choses. Chose qui a permit d'avoir rapidement un proto fonctionnel pour les forums et qui a permit de rédiger tout un tas d'issues sur son dépôt GitHub que nous utilisons comme bugtracker.

Après une légère mais première contribution de ma part via cette PR, Taguan s'est lancée dans une bonne grosse refonte que j'ai encadré via cette PR. Elle nous aura pris 15 jours a être mergée mais elle revoit l'ensemble du POC que Taguan avait développée pour quelque chose qui commence à avoir de la gueule.

Sans rentrer trop dans la technique : Nous avons tout un tas de modèles génériques pour les souscriptions, un modèle générique pour les notifications et, la plus grande nouveauté, tout un tas de signaux qui peuvent se comparer à des bus d'évènements. C'est à dire que dans les autres modules, nous ne faisons plus que envoyer des signaux (nous les envoyons nous même ou nous écoutons des signaux de Django) pour après les intercepter dans le module des notifications et enregistrer les souscriptions et les notifications souhaitées. C'est vraiment très sympa et, à mon humble avis, tout à fait adapté pour notre cas présent. Donc, un tout grand bravo à Taguan pour ce travail colossal !

Sinon, j'ai passé ma soirée à rebase la branche de la ZEP qui n'a pas été simple suite au récent merge du refactoring des vues du module des forums. Donc en plus d'avoir une première implémentation sympa, nous sommes mergeable par rapport au dépôt officiel (sur une de mes branches pour l'instant mais elle sera bientôt mergée au dépôt de Taguan).

Voilà pour les retours, j'espère que vous apprécierez !

Bonsoir tout le monde,

La ZEP avance toujours. On commence à stabiliser la partie forum avec les souscriptions à un forum, un tag et à un sujet par e-mail ou non. C'est plutôt sympa mais je ne viens pas pour vous tenir au courant cette fois. En fait, Taguan et moi nous nous sommes posé une question sur un point très précis.

Avant tout, un léger rappel de comment ça fonctionne actuellement et de comment ça fonctionnera avec la ZEP-24. Ca risque d'être un poil technique, je m'en excuse d'avance. Donc aujourd'hui, nous avons un modèle appelé TopicFollowed qui sauvegarde tous les sujets que nous suivons. Les notifications sont donc calculées en fonction des messages non lues pour chacune de ces sujets suivis et ça fait nos notifications. C'est un poil étrange et ça amène à des situations où vous pouvez retirer ou ajouter des items dans la liste de toutes vos notifications en suivant ou non un sujet.

Qu'est ce que nous proposons comme solution ? Et bien, nous gardons ce principe de "suivre" un contenu, que nous appelons les souscriptions et nous générons de réelles notifications à chaque évènement aux souscriptions auxquelles nous nous sommes enregistrés.

Alors, j'en viens à ma question :

Actuellement, il n'existe pas réellement de notifications. Nous suivons des sujets et lorsque nous ne voulons plus le suivre, nous supprimons cette information de la base de données. Par contre, dans l'état actuel de la ZEP, nous ne supprimons jamais rien. Nous gardons un historique des souscriptions et des notifications. Nous ne supprimons donc rien et nous aimerions votre avis pour savoir si vous pensez que c'est une bonne idée ou non ?

De notre côté, nous sommes d'avis de laisser les choses ainsi et, si nous devions constater une masse trop importantes de notifications, par après, proposer une solution qui consisterait à supprimer les notifications d'abonnements inactifs et on rajoute la suppression des notifications lors de la désactivation d'une souscription. Que pensez-vous de cette idée ?

Merci d'avance d'avoir pris la peine de me lire et encore plus de donner votre avis sur la question !

Ça signifie que je recevrais les notifications d'un sujet qui ne m'intéresse plus ?

Je ne pense que ce soit une bonne idée..

Non je pense plutôt que l'info de souscription à un topic n'est plus supprimée, mais désactivée.

Tu ne recevras pas les notifications marquées comme "inactives" j'imagine.

Fonctionnellement ça ne change rien pour l'utilisateur par contre techniquement l'implémentation est différente.

Mais c'est vrai que c'est pas clair du tout :\ Désolé Andr0.

Nous gardons un historique des souscriptions et des notifications.

Concrètement ? J'ai du mal à comprendre l'historique des notifications.

Le Pub/Sub est une bonne idée, je pense que c'est la bonne implémentation d'un système de notification. Mais j'ai du mal à voir ce que ça va donner en pratique et du coup évaluer le volume de données "inutiles" (puisque j'ai l'impression que c'est là-dessus que tu demandes un avis).

Hello,

Donc, on a des souscriptions (ou abonnements). Par exemple, on peut s'abonner à un sujet du forum pour recevoir des notifications à chaque réponse. Si on ne veut plus recevoir les notifications, on se désabonne. L'abonnement est alors désactivé, mais existe toujours dans la base de données.

D'autre part, lorsqu'une notification a été lue, elle n'est pas non plus supprimée, elle est simplement notée comme lue, et ne fait donc plus une alerte dans le header.

En conservant toutes les notifications, ça permettrait d'avoir une page "Mes notifications" qui reprend toutes les notifications qu'on a reçues. Qu'elles soient lues ou pas, qu'on suive encore le sujet (ou le tuto ou autre) à propos duquel elles ont été envoyées, ou pas.

En conservant tous les abonnements, même une fois désactivés, ça permettrait d'avoir une page "Mes abonnements", permettant de réactiver ou désactiver facilement des abonnements.

Le problème (mais peut-être que ça n'en est pas un, c'est toute la question), c'est que chaque membre peut avoir tout plein de souscriptions, et que chaque souscription peut générer l'envoi de tout plein de notifications.

Donc, est-ce qu'on garde effectivement tout ou est-ce qu'on fait un nettoyage régulier. Par exemple, on vire les notifications des abonnements inactifs. Notez que ça pourrait être aussi : tous les premier du mois, on vire les souscriptions qui ne sont pas active depuis au moins un mois (ainsi que leurs notifications).

Mais … ça semblait clair dans ma tête à 1h du matin ! :')

Merci Taguan pour le meilleur résumé.

Garder un historique n'est pas une mauvaise idée je trouve, cependant pour éviter d'alourdir la base de données effectivement une purge a intervalle régulier est nécessaire.
D'ailleurs pensez également aux comptes sur lesquels les utilisateurs ne se sont pas connecté depuis xx mois. Sa ne sert à rien de conserver une notification vieille de plusieurs mois, si l'utilisateur se reconnecte il en aura 35 et n'ira de toute façon pas les lire.

Par contre, on est bien d'accord, s'il y a un ou 35 nouvelles réponses dans un sujet suivit, on aura bien qu'une seule notif ?