Disons que nous souhaitons inclure un identifiant de requête unique à chaque réponse GraphQL.
Nous pouvons le faire en ajoutant un champ requestId au type de requête, puis en résolvant ce champ en un identifiant unique que nous avons défini dans le contexte de chaque requête. Ce n'est cependant pas une solution parfaite, car nous devons inclure ce champ dans chaque requête de notre client et cela augmente légèrement la taille de la requête envoyée au serveur.
Il existe une meilleure façon !
Nous pouvons créer un petit plugin (middleware) qui attache nos données personnalisées au champ d'extensions du corps de la réponse.
D'après ce que nous dit la page de documentation « Création de plugins de serveur Apollo », notre plugin devrait ressembler à ceci :
// extensionsPlugin.js export const extensionsPlugin = () => { return { requestDidStart: () => { return { willSendResponse(requestContext) { requestContext.response.body.singleResult = { ...requestContext.response.body.singleResult, extensions: { ...requestContext.response.body?.extensions, requestId: requestContext.contextValue.requestId }, }; }, } } } };
N'hésitez pas à utiliser console.log(requestContent.response) pour savoir comment les données sont structurées.
Gardez à l'esprit que seule la clé d'extension de body.singleResult fonctionnera immédiatement, car elle fait partie du standard GraphQL. Nous ne pouvons pas ajouter requestId directement à body.singleResult.
Et maintenant il ne reste plus qu'à le mettre en œuvre !
Cet exemple utilise le package ulid pour générer des identifiants compacts et triables dans le temps.
// main.js import { ulid } from 'ulid'; import { extensionsPlugin } from "./extensionsPlugin.js"; // ... const server = new ApolloServer({ // ... plugins: [extensionsPlugin()], // ... }) const { url } = await startStandaloneServer(server, { // ... context: async () => { // ... const requestId = ulid(); return { requestId, } }, // ... })
et c'est tout !
Pourquoi ça marche ? Le contexte est construit pour chaque requête séparément (contextuel) et est toujours disponible pour tous les résolveurs traitant la requête. Il est préférable de définir toutes les variables nécessaires dans leur contexte, car elles sont créées avant le déclenchement des hooks de plugin (par exemple : requestDidStart). Nous ajoutons le requestId à notre contexte et le rendons disponible partout, puis notre plugin l'extrait du contexte et l'attache au corps de la réponse juste avant qu'il ne soit renvoyé.
Vous avez une idée de quoi d'autre pourrions-nous attacher à notre réponse ? Partagez dans les commentaires :)
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!