[BP#64] Mettre en cache les données calculées souvent utilisées

[devcrafting]

Cette BP m'intrigue, je n'arrive pas à voir de cas d'utilisation. Il manque peut-être un exemple plus précis.

[didierfred]

Je dirais plutôt : Mettre en place un mécanisme de cache pour les données souvent utilisées .

Pour eviter de refaire inutilement plusieurs fois un calcul , un appel API , une requete SQL ....

[devcrafting]

On va arriver sur un terrain qui me plaît beaucoup :) : j'associe cela à CQRS (Command Query Responsability Segregation) où l'idée forte est de dire qu'il faut utiliser le bon modèle de données pour chaque cas d'utilisation (notamment en séparant Command - écriture - et Query - lecture). Il est aussi souvent dit en boutage que "CQRS c'est le cache parfait" :) (car les caches c'est assez/très complexe).

Je pense en effet que cela a un effet de bord vraiment intéressant en terme de sobriété, même s'il faut tempérer car la réduction de CPU d'un côté se paie en RAM ou disque pour le cache de l'autre côté.

[tbroyer]

En terme de cas d'utilisation, j'imagine tout ce qui est du genre "nombre de likes", "nombre de commentaires", "note moyenne des avis", etc. qui sont facilement calculés à partir des données mais qui gagneraient probablement à être dénormalisés et/ou mis en cache par ailleurs (memcache-like). On pourrait penser aussi éventuellement aux "articles similaires" ou "ceci pourrait aussi vous intéresser", etc. et tout ce qui sera affiché globalement sur la plupart des pages et qui demande un calcul et pas uniquement une lecture de données (la liste des catégories d'un blog, OK, mais si on y ajoute le nombre d'articles dans chaque catégorie ça peut valoir le coup de le mettre en cache)

Un autre cas d'usage, probablement bien plus problématique en fait, les tokens d'autorisation d'API, notamment OAuth 2.0. L'API reçoit une requête avec un entête Authorization: Bearer afdsoidjajnck, elle valide ce token auprès du serveur d'autorisation, qui lui indique également la date d'expiration du token. On peut donc mettre en cache cette information et éviter de revalider le token à chaque requête, d'autant plus une fois la date d'expiration atteinte (tant que le token n'est pas expiré, on le revalidera de temps à autres quand même pour vérifier s'il n'a pas été révoqué entre temps, mais on peut quand même éviter un grand nombre de requêtes strictement identiques).

[ACTLEM]

Note équipe projet: Mettre des exemples plus précis, concrets et actuels

Issue créée: #179

[devcrafting]

Cette discussion #116 peut avoir un impact sur la "mise en cache" par denormalisation