7 points par xguru 2022-10-23 | 3 commentaires | Partager sur WhatsApp
  • Outil de cache léger et facile à utiliser, exploitant Redis (LFU) ou son propre cache (LRU)
  • Node/Express + Typescript + Chart.js + Jest + React + Webpack

3 commentaires

 
colus001 2022-10-23

J’ai regardé un peu le code, et il y a pas mal de points qui me laissent perplexe. Je ne sais pas si ça fonctionnera bien. Comme l’architecture consiste à vérifier s’il y a un cache puis, s’il n’y en a pas, à renvoyer une requête POST vers l’endpoint depuis le serveur, il faut avoir deux endpoints, et comme cela met en cache l’intégralité de la query GraphQL, je ne pense pas qu’il y ait beaucoup de cas d’usage.

 
kbsbroad 2022-10-24

Eh bien... dans ce cas, quelle est la meilleure façon de mettre en place un cache GraphQL ? Comme les paramètres des requêtes GraphQL peuvent varier selon les cas, même si je construis moi-même le cache, si je mets en place un cache côté serveur, j’ai l’impression que ce ne sera pas très différent de DacheQL. Y aurait-il une meilleure approche ? La question m’est venue soudainement, alors je me permets de la poser !

 
colus001 2022-10-24

En général, on dirait qu’on fait le cache avec des data loaders au niveau des ressources. Ce n’est pas qu’on ne peut pas utiliser une approche comme celle-là, mais les cas d’usage pour cette bibliothèque sont limités, et comme l’endpoint se retrouve scindé en deux, elle est aussi plus facile à attaquer et présente pas mal d’inconvénients. Lors des requêtes de ressources, il suffit qu’une seule clé soit générée pour que le cache ne soit plus utilisé.