Aller au contenu
PWA + Cadriciel

Projet 3: Notifications push et optimisation

Contexte et objectifs

Cette troisième phase complète la PWA Avis et alertes en y ajoutant un serveur backend Node.js/Express, des notifications push envoyées aux appareils abonnés, et un travail d'optimisation accompagné d'une auto-analyse écrite.

Le frontend, jusqu'ici branché directement sur l'API de la Ville, consomme désormais un serveur intermédiaire qui récupère, formate et distribue les données, en plus d'orchestrer l'envoi des notifications.

Compétences visées

  • Concevoir et implémenter une API REST avec Express.
  • Persister des données dans une base infonuagique (MongoDB Atlas ou Firebase).
  • Implémenter le flux complet de notifications push Web (VAPID, subscribe, push event, display).
  • Orchestrer un projet full-stack (frontend + backend + base de données).
  • Analyser son propre code et formuler des propositions d'amélioration étayées.

Mandat

Application PWA (Frontend)

Faites évoluer votre PWA du projet 2 en intégrant les changements suivants :

  • Interface, recherche, filtres, page de détail, responsive – idem que projet 2. Toute fonctionnalité incomplète du projet 2 doit être complétée ici.
  • Modale d'abonnement : le lien « M'abonner » ouvre une fenêtre modale (composant React, aucune bibliothèque externe requise).
    • Texte explicatif décrivant le fonctionnement des notifications.
    • Si l'appareil n'est pas abonné : bouton « S'abonner » qui demande la permission, crée la souscription et la transmet au serveur.
    • Si l'appareil est déjà abonné : bouton « Se désabonner ».
    • Gestion des cas : permission refusée, permission déjà bloquée au niveau du navigateur, API Push indisponible.
    • Fermeture via la touche Esc ou un bouton de fermeture.
    Bonus : permettre à l'utilisateur de choisir ses sujets et arrondissements d'intérêt. Ces préférences doivent être persistées côté serveur avec l'abonnement et filtrer les notifications reçues.
  • Source de données : le frontend interroge maintenant le serveur Express plutôt que l'API de la Ville directement.
  • Installabilité et mode hors-ligne – idem que projet 2, cible Lighthouse PWA ≥ 90 maintenue.
  • Notifications push :
    • Utilisez l'API Push et la Notifications API côté client, avec la clé VAPID publique fournie par le serveur.
    • Les notifications doivent s'afficher même lorsque l'application est fermée (gérées par le service worker via l'événement push).
    • Au clic sur une notification, l'utilisateur est amené à la page pertinente de l'application.
    • Bonus : afficher la notification in-app lorsque l'application est ouverte.
  • Pagination (Bonus) : limiter à 10 avis par page. Deux options : bouton « Charger plus » OU pagination numérotée.

Serveur Express (Backend)

Développez un serveur Node.js/Express exposant une API REST. Le serveur est responsable de :

  1. Récupérer et normaliser les données de la Ville de Montréal.
  2. Gérer les abonnements push (stockage en base).
  3. Envoyer des notifications push aux appareils abonnés.

Routes

  • GET /avis-alertes — Retourne la liste normalisée des avis.
    Bonus : supporter ?sujet=, ?arrondissement=, ?q=, ?limit=, ?offset=.
  • GET /vapid-public-key — Retourne la clé publique VAPID nécessaire au client pour s'abonner.
  • POST /subscribe — Corps : { subscription, preferences? }. Stocke l'abonnement s'il n'existe pas déjà (clé d'unicité : endpoint).
  • POST /unsubscribe — Corps : { endpoint }. Supprime l'abonnement correspondant. Retourne 404 si introuvable.
  • POST /send-notification — Corps : { title, body, url? }. Envoie la notification à tous les abonnés (ou à ceux correspondant aux préférences, en bonus) via web-push. Testable depuis Postman/Insomnia.

Conventions

  • CORS configuré pour autoriser l'origine de votre frontend.
  • Réponses JSON cohérentes : succès { data }, erreur { error, message }.
  • Codes HTTP appropriés : 200, 201, 400, 404, 410 (abonnement expiré), 500.
  • Secrets (clés VAPID, URL de connexion à la base) dans .env — jamais committé. Fournir un .env.example.

Base de données

MongoDB Atlas ou Firebase Firestore. Schéma minimal :

  • Subscription : endpoint (unique), keys (p256dh, auth), createdAt, preferences? (bonus).
  • Notification (bonus) : title, body, sentAt, recipientsCount, successCount, failureCount.

Lorsqu'un envoi retourne 410 ou 404, l'abonnement obsolète doit être automatiquement supprimé de la base.

Déploiement et démo

Les notifications push requièrent HTTPS. Pour la démo en classe, deux options :

  1. Recommandé : déployer le frontend (Vercel, Netlify, GitHub Pages) et le backend (Render, Railway, Fly.io).
  2. En local : servir le frontend en HTTPS (vite --https).

Indiquez clairement dans le README comment démarrer l'application et tester l'envoi de notifications.

Rapport technique

Rédigez un rapport d'environ une page (≈ 500 mots), remis en PDF dans docs/rapport.pdf. Il doit couvrir les sections suivantes :

  • Qualités et faiblesses du code : architecture, modularité, lisibilité, gestion des erreurs. Appuyez-vous sur des exemples concrets avec référence au fichier.
  • Qualités et faiblesses de l'application : UX, performance (scores Lighthouse), fiabilité des notifications, fonctionnement hors-ligne.
  • Propositions d'améliorations : au moins 3 suggestions concrètes, priorisées.

Évaluation

Application (25 %)

  • Utilisabilité (UI/UX) et responsive.
  • Respect de la spécification frontend.
  • Qualité de la modale d'abonnement (incluant cas limites).

Fonctionnalités PWA (25 %)

  • Installabilité et personnalisation.
  • Mode hors-ligne et service worker.
  • Gestion de la mise en cache.
  • Notifications push (bout en bout, incluant clic et navigation).
  • Performance Lighthouse.

Backend (20 %)

  • Exactitude des routes et des contrats d'API.
  • Intégration avec la base de données.
  • Gestion des erreurs et des abonnements expirés.
  • Sécurité des secrets (variables d'environnement).

Qualité du code (15 %)

  • Modularité, décomposition, usage des hooks.
  • Absence de code mort ou dupliqué.
  • Documentation et README.

Rapport et maîtrise (15 %)

  • Rapport technique (pertinence, exemples concrets, propositions priorisées).
  • Évaluation orale en classe.

Les bonus peuvent ajouter jusqu'à +10 points sur 100, non cumulables au-delà de ce plafond.

Remise

Ce projet compte pour 40 % de la note finale. Vous devez remettre, sur Léa (Omnivox), avant le lundi 1er juin 23 h 59 :

  • Le lien vers votre dépôt GitHub (avec une release étiquetée).
  • Le rapport PDF (également inclus dans le dépôt sous docs/rapport.pdf).

Pénalité de 5 % par jour de retard. Toute remise doit impérativement être effectuée avant l'évaluation orale.
Évaluation orale en classe le mardi 2 juin (~ 15 min par étudiant·e).

Précisions sur le dépôt GitHub

Fichier README

  1. Titre et description du projet.
  2. Liste des fonctionnalités (incluant les bonus implémentés).
  3. Organisation du dépôt (backend, frontend, docs).
  4. Instructions d'installation et de démarrage (frontend, backend, base de données).
  5. Variables d'environnement requises (sans valeurs).
  6. Procédure pour tester l'envoi d'une notification.
  7. URL de déploiement, le cas échéant.

Organisation suggérée

  • Répertoirebackend/ Serveur Express.js
    • Répertoiredb/
      • …
    • Répertoireroutes/
      • …
    • Répertoireutils/
      • …
    • .env.example
    • index.js
    • package.json
    • .gitignore
  • Répertoirefrontend/ Application PWA React
    • Répertoirepublic/
      • Répertoireicons/
        • …
      • manifest.webmanifest
    • Répertoiresrc/
      • Répertoireassets/
        • …
      • Répertoirecomponents/
        • …
      • Répertoirehooks/
        • …
      • Répertoirepages/
        • …
      • Répertoireservices/
        • …
      • sw.js
      • main.jsx
    • .env.example
    • index.html
    • vite.config.js
    • package.json
    • .gitignore
  • Répertoiredocs/
    • rapport.pdf
  • .gitignore
  • README.md