[BP#10] Stocker les données statiques localement

[devcrafting]

Je m'interroge sur l'impact sur les terminaux utilisateurs d'une grosse utilisation du stockage local ? N'y a-t-il pas un effet obsolescence plus fort?
Peut-être rajouter un avertissement sur le volume de données ?

Aussi je me demande comment orienter pour définir une donnée statique... ça ne semble pas si trivial. Peut-être donner des exemples (l'exemple n'en est pas vraiment un) ?

Pourquoi on parle de mainframe ici 🤔 (pourquoi pas...mais je trouve que ça tombe comme un cheveu sur la soupe 😋)

[ACTLEM]

Oui, plutôt que mainframe, un terme plus générique comme "serveur applicatif jusque base de données" serait plus simple.

Pour le stockage, je suis d'accord, c'est toujours une question d'être mesurée. Trop charger le cache local peut provoquer des ralentissements (cf Teams ^^)

[Fred-artwai]

Il a plusieurs choses différentes dans cette BP qui a mon avis peuvent être confusant. Il y a le web storage, IndexedDB et le service worker. Chacun a un usage différent.

Le Service Worker correspond le plus à cette BP dans le sens où il peut créer un cache dédié et éviter un appel HTTP pour connaitre la version du document et le servir lui même. Il peut même faire fournir les ressources stockées quand le terminal est hors ligne. Mais il peut aussi faire des appels par anticipation de la navigation de l'internaute et potentiellement mettre en cache des ressources qui ne serviront à rien. Là on n'est plus vraiment dans de l'éco-conception.

Pour les Web Storage, on va dire succinctement que çà remplace les cookies.

Pour IndexedDB, c'est utile si l'on veut faire un traitement de donnée sur le terminal et non plus cotés serveur. Par contre, je n'ai aucune idée de savoir comment mesurer la pertinence écoconçue de cet usage. Plus on encourage cette pratique, plus les devs vont en abuser et plus les terminaux qui ont moins de puissance de calculs vont sembler obsolètes... D'autant plus qu'il y aura très souvent un système de synchronisation entre la BDD local et celle serveur avec des échanges de données que l'on souhaite éviter.

Pour moi seul un système de cache avec un service worker peut être pertinent sur cette BP (mais bon je peux changer d'avis si on m'explique le contraire).

[tbroyer]

Une page aussi pourrait faire des appels "par anticipation" et mettre des données/ressources en cache (la Cache Storage API n'est d'ailleurs pas l'apanage des service workers: https://caniuse.com/mdn-api_cache), et pour être clair un service worker pourrait très bien aussi mettre des données en cache dans IndexedDB et/ou Web Storage, pas uniquement via la Cache Storage API.

En gros, "tout" peut "tout faire", il n'y a pas de distinction particulière à faire ici.

[tbroyer]

Il faut reformuler la description, il y a des erreurs/inexactitudes:

• “base de données relationnelle SQL (IndexedDB)”: j'imagine qu'à l'origine ça parlait de WebSQL, il faudrait regrouper IndexedDB avec Web Storage dans la catégorie “paires valeurs-clés” (on dit d'ailleurs "clé-valeur" en général, reformuler en "base de données clé-valeur" ?)
• “mise en cache applicatif (Service Workers)”: il s'agit de la Cache Storage API (ou Cache API), qui peut être utilisée en dehors des services workers ; je ne comprend pas trop ce que signifie "applicatif" ici, est-ce qu'on parle de la "mise en cache HTTP" "programmatiquement" ? (gérée/contrôlée/dirigée par l'application)

Et il faudra bien entendu mettre à jour le paragraphe “À l’heure où nous écrivons ces lignes (juillet 2015)”

[ACTLEM]

+1

[ACTLEM]

J'ai créé l'issue pour corriger les erreurs, améliorer la description et les exemples: #252