Retours sur le spike du cache

[nicolaskempf57]

Solution passée

Nous avons souhaité mettre en place une solution de cache côté serveur avec Nginx. Cela n'a pas fonctionné et tous les utilisateurs accédaient au site au nom du premier utilisateur connecté.

Solution actuelle

Pour corriger rapidement le problème, aucun cache n'est présent sur le site mais c'est une mauvaise pratique.

Solution proposée

Nginx

Une solution via Nginx, comme initialement proposée, permet de répondre à des besoins simples de mise en cache d'un fichier en entier.

Cette solution peut être utilisée pour l'intégralité du dossier public de Nuxt qui contient les images et autres fichiers non traités par notre outil de build.

De même, les autres fichiers générés peuvent suivre cette même solution.

Cependant, le fonctionnement devient plus sujet à "erreur de cache" sur nos pages applicatives avec la gestion des utilisateurs connectés. Il est possible d'intégrer un cookie à la clef de cache mais cela revient à avoir un cache par session donc on perd l'intérêt premier du cache.

Nuxt

Pour les routes du projet, il semble préférable d'avoir recours à la solution de cache du framework, qui est plus flexible et plus intégrée à l'applicatif, comme nous le faisons avec flask-cache côté udata.

Concrètement cela signifie que nous attribuons à chaque route, ou groupe de routes une indication de cache qui est traitée lorsque la requête arrive à Node.

Les routes qui n'ont aucun contenu changeant peuvent être générée au build, comme les "pages" ou les pages de login, etc.

Les pages avec du contenu changeant, comme un article avec commentaires ou une page de détails d'un dataset, peuvent être mises en cache pour une certaine durée, et ensuite le renouvellement s'effectue en tâche de fond. Il est également possible d'avoir ce fonctionnement sans durée configurée pour avoir le renouvellement en tâche de fond en continu.

Pour des pages où ce fonctionnement est limité, il est possible de recourir à un rendu côté serveur sans cache, comme pour l'administration.

Comme avec Flask-cache, il est possible d'être beaucoup plus fin en terme de mise en cache et aller jusqu'à cibler un retour de fonction.

Par défaut, le système de cache est stocké en mémoire mais il est possible d'utiliser un driver Redis.

Limitations et contournements

L'utilisation du cookie d'udata côté client comme solution d'identification crée une différence de contexte entre le rendu initial coté serveur (non connecté) et le coté client (connecté ou non connecté). L'information de connexion est propagée côté serveur, dans le cas de requêtes successives, mais le serveur traite toujours une nouvelle session utilisateur comme étant non connectée au chargement de la page, sauf requête explicite au chargement comme c'est le cas pour les pages d'administration.

Cela peut poser un problème d'hydratation du contenu si nous utilisons des routes en cache ou pré-générée. Afin de résoudre ce problème, les composants relatifs à un utilisateur comme l'entête sont uniquement résolus côté client. Cela évite que l'utilisateur voit une en-tete non connectée, qui ensuite devient une en-tete connectée au moment où le JavaScript côté client a fini de requêter l'API udata avec les données de l'utilisateur.

Autres considérations

Afin de réduire la charge côté serveur, il est possible de limiter les requêtes d'API effectuées côté serveur. Cela permet également de mettre plus de pages en cache quand il y a très peu d'éléments dynamiques sur la page (ex: les posts).

Pour améliorer l'expérience utilisateur, il est possible de naviguer d'une page à une autre avant d'avoir un retour des requêtes d'API qui y sont effectuées. Il faut alors gérer un état de chargement au sein de la page.

Liens utiles

• cache Nuxt des routes : https://nuxt.com/docs/guide/concepts/rendering#route-rules
• cache des requêtes d'API : https://nuxt.com/docs/getting-started/data-fetching#caching-and-refetching
• cache de fonctions : https://nitro.build/guide/cache#cached-functions
• proxy_cache avec cookie : https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_key
• PR draft coté docket-udata avec le détails des conteneurs utilisés : feat: add front-end opendatateam/docker-udata#352