Pour un développement d’un blog avec Astro.build et WordPress, nous avions besoin de récupérer les catégories et les tags en une fois. Le problème est que cette récupération entrainait deux requêtes à l’API GraphQL de WordPress. Comment faire pour l’éviter ? et bien tout simplement grâce à un Singleton
Mais qu’est ce qu’un Singleton au juste ?
Un singleton est utilisé en programmation dès lors que l’on souhaite récupérer la même instance d’une classe et il fournit, ici, un point d’accès global et unique à cette ressource.
Cela peut servir à gérer les connexions à la base de données par exemple où on récupère des ressources d’un pool, ou bien ici, dans notre cas, cela sert à faire en sorte de n’envoyer qu’une seule requête vers l’API GraphQL de WordPress
Comment faire ?
Dans notre cas, nous avons utilisé la dépendance @heap-code/singleton. Nous aurions pu l’implémenter à nouveau mais vu la simplicité de la dépendance, et que nous aimons bien ne pas réinventer la roue, nous avons préféré utilisé cette dépendance
import {Singleton} from "@heap-code/singleton";
const terms = new Singleton(() => getTerms());
export async function getTags() {
return (await terms.get()).filter((term) => term.taxonomyName === 'post_tag');
}
export async function getCategories() {
return (await terms.get()).filter((term) => term.taxonomyName === 'category');
}
Pour expliquer un peu le code, nous utilisons au niveau de Astro.build les Content Collection. Dès lors que nous démarrons Astro.build, celui-ci va aller chercher les catégories et les tags et donc faire appel à la méthode getTerms, à travers le Singleton.
Le singleton fait son travail et donne accès à la même ressource et cela permet de facilement récupérer les catégories et les tags en appelant une seule fois la méthode getTerms.
C’est une façon élégante de développer et de consommer des ressources, car en, effet, la consommation des ressources incombe toujours au développeur !
Pour finir
Les singletons fonctionne pour la même instance ou bien le même flux d’execution. Si vous démarrez un autre processus, ce sera un autre Singleton qui sera démarré. On le rencontre souvent dans des applications développées avec Spring Boot. En effet, le JAR de l’application est démarré une fois et donne toujours accès aux mêmes ressources. Si vous en démarrez un autre, le Singleton sera propre à l’instance démarrée, ainsi, il ne sera pas partagé entre les multiples instances.
On peut également se servir de Singleton pour consommer une API et récupérer un token JWT permettant de faire les appels. Dans certains cas, la fourniture de jeton JWT peut consommer des appels en base de données, mais pour le consommateur de l’API, tout ceci n’est pas visible.
Alors quand on est développeur et qu’on est soucieux de ne pas gaspiller inutilement des ressources, on met des stratégies en place pour ce faire … et le Singleton est une solution qui permet d’y arriver. Un cache pourrait aussi le faire mais au final, cela revient au même, c’est un point de coordination unique qui donne des données. Dans notre cas, cela ne servait à rien, les données récupérées sont stockées justement dans une base de données.
