PWA

[azmeuk]

Bonjour à tous,
J'ouvre ce ticket pour faire le suivi du développement du mode PWA et des push notifications pour esup-pod, par Yaal Coop.

Le premier sujet qu'on aimerait aborder c'est les bibliothèques sur lesquelles on peut se baser. Après avoir fait quelques tests on se rends compte que deux bibliothèques semblent pertinentes pour la mission. On voulait valider que c'est OK de les utiliser. À défaut il faudra qu'on redéveloppe certaines choses à la main.

• django-pwa automatise la création du manifest.json, du service worker et apporte à peu de coût l'aspect « installable ». Les métadonnées de l'application sont éditables dans la conf django. Le projet est petit (<100 commits) mais la dernière release date du mois dernier, et selon github environ 1000 projets utilisent cette bibliothèque.
• django-push-notifications automatise la configuration et la communication avec les différents push services (google, apple, microsoft et webpush). La dernière release date d'il y a un an et demi mais le projet semble mature et il est porté par jazzband, qui est un collectif qui développe et maintient beaucoup de plugins django.

cc @ptitloup @LoanR

[LoicBonavent]

Bonjour,

Les deux bibliothèques proposées semblent correspondre parfaitement à nos besoins, mais nous avons quelques remarques, à savoir :

• pour django-pwa : nous validons son utilisation.

• django-push-notifications semble aussi être complet, malgré le fait que sa dernière release date de février 2022. Le collectif Jazzband semble actif sur un grand nombre de bibliothèques. Une de leurs dernière release date d'hier (pip-tools). Et d'un autre côté, nous avons des bibliothèques comme django-admin2 qui n'ont pas eu de nouvelle release depuis janvier 2017.
  Cependant, quand nous regardons ses issues sur GitHub (https://github.com/jazzband/django-push-notifications/issues), nous voyons qu'un grand nombre d'entre elles restent sans réponse... Sur le long terme, est-ce que le choix de django-push-notifications est le bon ? Quelles sont les autres possibilités ?

Merci,

Loïc & Aymeric du comité technique d'Esup-Pod

[azmeuk]

Concernant django-push-notifications, notre interprétation de la situation est que le projet est en mode de maintenance minimale. À savoir que les problèmes liés à la compatibilité et aux montées de version (de python, django) sont traîtés (par exemple ce problème lié à python 3.10), mais pas les demandes de fonctionnalités ou les dysfonctionnements mineurs.
Le fait que les dernières contributions proposées restent sans réponse peut être en effet plus problématique sur le long terme.

Les options que nous envisageons, dans le désordre :

1. Tenter de contacter les mainteneurs de django-push-notifications pour connaître mieux l'état de la maintenance, éventuellement les relancer sur les tickets qui semblent critiques. Cela permettrait de se rassurer ou bien d'écarter le projet avec plus d'assurances. La prise de contact peut fonctionner ou rester lettre morte. Cela peut aussi avoir comme issue d'être invité à participer à la maintenance (parfois il suffit de demander les clés pour les obtenir).
2. Utiliser une bibliothèque différente pour les navigateurs compatibles avec le protocole webpush, comme django-webpush. Le projet semble plus petit (~350 LOC) et ne se concentre pas sur les protocoles natifs (FCM/GCM/APNS/WNS), ce qui est positif : il est donc plus facile à maintenir. La dernière publication date de mars dernier et le dernier commit du mois dernier. Il semble n'y avoir qu'un seul développeur derrière. De notre point de vue ça n'est pas un grave problème, la majorité des bibliothèques libres sont portés par un unique mainteneur. La bibliothèque amène une autre dépendance pywebpush dont la dernière activité date de 2021. Là encore ça n'est pas une inquiétude à nos yeux : le projet semble être mûr, et ne fait que ~500 LOC.
   Cette approche a l'inconvénient que, si le support pour webpush est assez répandu, dans l'écosystème Apple il semble être récent, et par conséquent que l'on peut anticiper un mauvais support des vieux appareils Apple. J'imagine qu'il faudrait trouver des outils complémentaires pour assurer la compatibilité APNS comme PyAPNs2. Il y aurait sans doute les même fonctionnement à développer deux fois plutôt qu'une seule (pour webpush et pour Apple). À creuser.
3. Utiliser django-webpush comme suggéré en 2. et assumer l'incompatibilité des notifications sur les vieux appareils Apple. Celà permettrait de minimiser le travail requis et les dépendances par rapport à l'hypothèse 2. On sait aussi que, le temps passant et le parc matériel se renouvelant, la compatibilité sera meilleure dans le futur.
4. Faire sans bibliothèque spécialisée. L'avantage serait une indépendance totale vis-à-vis d'autres outils. Les inconvénients seraient un développement probablement (beaucoup) plus long, et plus de travail de maintenance pour esup-pod puisque le code métier des notifications serait intégré au projet.
5. Développer avec les bibliothèques bas niveau, comme PyAPNs2 et pywebpush. Cette approche serait un intermédiaire entre les 2. 3. et 4.

À défaut d'utiliser django-push-notifications, nous suggérerions d'utiliser django-webpush en complément d'une autre bibliothèque pour les appareils Apple.

[LoicBonavent]

Nous vous remercions d'avoir exposé les différentes options possibles.

Au vu de celles-ci, comme vous, nous pensons que les solutions 4 et 5 reviennent à "réinventer la roue", ce qui serait une surcharge conséquente de développement, d'exploitation, etc. Bref, cela ne nous semble pas viable.

Au final, entre les 2 solutions (django-push-notifications ou django-webpush/autres bibliothèques), il se pose la question de la pérennité. Dans les 2 cas, cela ne semble pas évident, mais - de notre point de vue - la 2° solution présente plus de problèmes que la 1° : le fait que cela repose sur un seul développeur, qu'il faille par la suite utiliser d'autres bibliothèques et la possibilité d'avoir des problèmes d'incompatibilité avec certains appareils.

Au vu de ces informations, il nous semble alors préférable d’utiliser django-push-notifications, en espérant qu'elle évolue dans le bon sens, ou qu'à terme, un fork bien maintenu apparaisse.

De ce point de vue, le fait de contacter les mainteneurs de django-push-notifications, ne serait-ce que pour savoir à minima l'état de maintenance et leur roadmap prévisionnelle, serait bienvenu.

Merci encore pour ces informations pertinentes.

Bonne journée,

Loïc & Aymeric du comité technique d'Esup-Pod

[azmeuk]

J'ai posé la question de la maintenance chez django-push-notifications: jazzband/django-push-notifications#685

Nous allons entammer le développement de la PWA, on vous tiendra au courant des avancées et des difficultés éventuelles.

[LoicBonavent]

Merci beaucoup de ce retour.

Bonne journée

[azmeuk]

Bonjour,
J'ai quelques nouvelles réflexions à vous partager, notamment par rapport au support des terminaux Apple.

Depuis quelques années Push API est un standard qui vient remplacer les API natives des constructeurs (FCM/GCM de Google/APNS d'Apple/WNS de Microsoft). Le site caniuse nous apprends des choses intéressantes sur le support de Push API :

• Le support pour firefox date de 2016
• Le support pour chrome date de 2016
• Le support pour edge date de 2018
• Le support pour safari date d'octobre 2022

Le support pour Apple date donc de moins d'un an. Si l'on regarde les statistiques d'usage, on voit que :

• l'utilisation de safari (desktop+mobile) sans support webpush est de 8,69%
• l'utilisation de safari (desktop+mobile) avec support webpush est de 11,46%
  Parmi les utilisateurs de safari, 57% environ supportent webpush, C'est le nombre après moins d'un an de support par safari, et on peut supposer qu'il va croître dans le temps.

D'un côté django-push-notifications supporte webpush, mais pas pour safari, cependant une PR existe pour son support. D'un autre côté, l'alternative en restant sur le protocole APNS requiert d'utiliser pyapns2 qui semble être très peu maintenu, et a elle même une dépendance vers hyper qui est explicitement abandonné et pose des problèmes de montée de version. Des utilisateurs suggèrent de migrer django-push-notifications sur aioapns en remplacement, mais il n'y a pas de PR pour ça.
En alternative à django-push-notifications, il y a django-webpush qui ne supporte que webpush et qui est une bibliothèque assez petite. Le support de safari n'est pas encore implémenté.

Le support des matériels Apple est donc problématique puisque :

• utiliser APNS dans django-push-notifications en l'état n'est pas pérenne
• utiliser webpush pour safari n'est pas implémenté dans les options envisagées, et ne serait pas compatible avec une partie du parc Apple

À ce constat on peut imaginer :

1. implémenter les notifications avec le protocole webpush dans django-push-notifications, ne pas supporter les appareils apple dans un premier temps, travailler à migrer la bibliothèque vers aioapns en remplacement de pyapns2, puis implémenter les notifications en utilisant APNS
2. implémenter les notifications avec le protocole webpush dans django-push-notifications, ne pas supporter les appareils apple dans un premier temps, aider les mainteneurs à tester/valider la PR pour le support de webpush pour safari. Cela reviendrait à faire définitivement une croix sur les vieux matériels Apple.
3. implémenter les notifications avec le protocole webpush dans django-webpush, ne pas supporter les appareils apple dans un premier temps, travailler au support de webpush pour safari. Cela reviendrait à définitivement faire une croix sur les vieux matériels Apple.
4. utiliser django-push-notifications en l'état avec pyapns2 dans un premier temps, migrer sur d'autres solutions lorsque cela deviendra problématique

Les options 1, 2 et 3 ont l'inconvénient qu'il faut développer des PR dans des dépots existants, l'incertitude quant à la quantité de travail et à l'acceptation par les mainteneurs.
L'option 4, celle qui est retenue pour le moment, représenterait peut-être moins de travail dans un premier temps, on doit encore faire quelques tests techniques pour voir si elle est viable.

[azmeuk]

Comme convenu nous avons avancé sur l'implémentation via django-push-notifications. Les notifications pour Chrome et Firefox fonctionne bien, il nous reste à tester Safari.
Bonne nouvelle, le mainteneur de django-push-notifications a répondu à notre question sur la maintenance et passé en revue quelques contributions. Mauvaise nouvelle, il indique ne plus avoir le temps de maintenir la bibliothèque.

En regardant de plus près le fonctionnement de jazzband, nous nous sommes rendus compte que le collectif est assez ouvert. On peut devenir membre sur simple inscription au groupe, ce que j'ai fait. Il existe d'autres statuts, comme les project lead (qui peuvent publier des paquets sur pypi.org) ou les roadies (qui ont à peu près tous les droits).

En étant membre on peut donc contribuer au projet. Il reste la question des publications de version, qui est documentée ici. En résumé, pour publier une version il faut demander au project lead, et à défaut aux roadies de jazzband, ou devenir project lead.

En conclusion : le projet n'est donc plus maintenu, mais contribuer et amener des contributions jusqu'en production semble abordable.

[AymericJak]

Bonjour,

Nous vous remercions pour tous ces retours que vous avez partagés jusqu'à présent.
Nous reviendrons vers vous dans les prochains jours, avec des informations plus détaillées sur la direction que nous envisageons de prendre.

En attendant, si vous avez d'autres réflexions ou suggestions à partager, n'hésitez pas à nous en faire part.

Nous vous remercions encore pour votre implication.

Bonne journée,

Aymeric du comité technique d'Esup-Pod.

[cbissler]

Bonjour et merci pour ces échanges détaillés,

Je pense (mais on peut en débattre) qu'il ne faut pas "investir" dans les anciens protocoles APNS, GCM etc. mais qu'il faut partir sur du standard webpush. Ce sera un code unique, plus facile à maintenir quitte à "investir" du temps pour améliorer la compatibilité des librairies avec safari puisque que c'est ce qui semble être à la traine.

Partant de ça, django-push-notification qui fait tout (si j'ai bien compris) mais qui présente des incertitudes sur la maintenance c'est peut-être "la grosse artillerie". Je ne dis pas qu'il faut l'écarter à ce stade.

django-webpush est une librairie plus légère puisqu'elle ne fait que du webpush, et donc j'imagine plus facile à maintenir. Et il est indiqué dans les derniers échanges qu'elle est compatible avec ios 16.4... enfin que ça marche... On collerait donc avec la compatibilité caniuse (à mon sens l'incompatibilité avec les vieux safari n'est pas un problème, en tout cas on pourra le justifier). Qu'en est-il de la maintenance et de la pérénité de cette librairie ? Si c'est mieux il faudrait peut-être creuser cette option.

Existe-t-il d'autres librairies équivalentes et qui ne font que du webpush ?

Bonne journée,

Céline du comité technique POD aussi.

[azmeuk]

Quelques retours : nous nous sommes procurés un iphone cette semaine, ce qui nous a permis de tester les différents cas de figures. Nous confirmons que les deux bibliothèques permettent de produire des notifications avec l'API push standard sur les navigateurs ciblés (firefox, chrome, safari) (à condition néanmoins que cette PR soit fusionnée et publiée en ce qui concerne django-push-notifications).

Qu'en est-il de la maintenance et de la pérénité de cette librairie ?

• Il y a un seul développeur actif pour django-webpush, mais c'est aussi le cas pour django-push-notifications.
• django-webpush fait 350 lignes de python, contre 3000 pour django-push-notifications
• django-webpush semble être compatible avec les versions récentes de python (il n'y a pas de test pour le confirmer, mais personne ne se plaint d'incompatibilité sur le bug tracker) tandis que django-push-notifications est connu pour être incompatible avec python 3.10 et python 3.11 (ce que nous avons vérifié)

Existe-t-il d'autres librairies équivalentes et qui ne font que du webpush ?

La bibliothèque sous-jacente à django-webpush et django-push-notifications est pywebpush (qui fait 500 lignes de code, semble être assez peu active). pywebpush se charge des échanges réseau avec les serveur webpush tandis que django-pwa ou django-push-notifications vont faire la colle avec django, et notamment enregistrer les informations transmises par les serveurs webpush en base de donnée.

Comme nous le voyons :

• Si vous avez la volonté de supporter les vieux appareils iphone et APNS, alors il y a peu d'autre choix que d'adopter django-push-notifications, attendre que #674 soit fusionnée et publiée. Il faudra à l'avenir attendre ou implémenter le support pour python 3.10. Enfin nous n'avons pas encore testé si le support pour APNS était toujours fonctionnel, ça reste donc à démontrer. Nous ferons de plus amples tests si vous nous confirmez votre intérêt pour le support d'APNS.
• Si vous n'avez pas la volonté de supporter APNS, alors notre conseil c'est de partir sur django-webpush, qui est une dépendance plus petite et plus simple à maintenir.

[AymericJak]

Bonjour,

Je tiens à vous remercier pour ces retours constructifs.

Après avoir examiné le tout, nous arrivons à la conclusion que django-webpush semble mieux correspondre à nos besoins pour le projet.
La simplicité de maintenance et la compatibilité de cette librairie avec les versions plus récentes de Python n'apportent qu'avantages !

Ainsi, nous serions partants vers l'utilisation de django-webpush.
@ptitloup Quel est ton avis sur le sujet ?

Bonne journée,
Aymeric, Loic et Céline du comité technique d'Esup-Pod.

[ptitloup]

Bonjour à tous et merci pour votre suivi.

Je me range du côté des membres du comité technique pour vous demander de préférer l'usage de django-webpush.
Il est plus léger (donc plus facilement maintenable), tjs maintenu et compatible avec python 3.10, ce qui est le cas de Pod (compatible 3.8-3.9 et 3.10).
Je suis à votre disposition pour tout complément d'information
Bien cordialement
Nicolas

[azmeuk]

Merci pour vos retours. C'est noté on part donc sur django-webpush.