Les requêtes persistantes sont des requêtes GraphQL qui sont créées et stockées sur le serveur Adobe Experience Manager (AEM) as a Cloud Service. Elles peuvent être demandées avec une requête GET par les applications clientes. La réponse d’une requête GET peut être mise en cache aux couches Dispatcher et CDN, ce qui améliore finalement les performances de l’application cliente qui la demande. Elles sont en cela différentes des requêtes GraphQL standard, qui sont exécutées à l’aide de requêtes POST dans lesquelles la réponse ne peut pas être facilement mise en cache.
Des requêtes persistantes sont recommandées. Voir Bonnes pratiques de requête GraphQL (Dispatcher) pour plus d’informations et la configuration Dispatcher associée.
L’IDE GraphiQL est disponible dans AEM pour que vous puissiez le développer, le tester et conserver vos requêtes GraphQL, avant de le transférer vers votre environnement de production. Dans les cas qui nécessitent une personnalisation (par exemple, pour la personnalisation du cache) vous pouvez utiliser l’API ; consultez l’exemple de cURL fourni dans Conservation d’une requête GraphQL.
Les requêtes persistantes doivent toujours utiliser le point d’entrée associé à la configuration Sites appropriée afin qu’ils puissent utiliser l’une des fonctionnalités ou les deux :
Voir Activation de la fonctionnalité de fragment de contenu dans le navigateur de configuration pour plus d’informations.
Les requêtes persistantes GraphQL doivent être activées pour la configuration appropriée des sites.
Par exemple, s’il existe une requête spécifique appelée my-query
, qui utilise un modèle my-model
de la configuration Sites my-conf
:
my-conf
spécifique, puis la requête est enregistrée comme suit :/conf/my-conf/settings/graphql/persistentQueries/my-query
global
, mais elle est dans ce cas enregistrée comme suit :/conf/global/settings/graphql/persistentQueries/my-query
Il s’agit de deux requêtes différentes, enregistrées sous des chemins différents.
Il se trouve qu’elles utilisent le même modèle – mais via différents points d’entrée.
Il est recommandé d’appliquer des requêtes persistantes dans un environnement de création d’AEM dès le départ, puis de transférer la requête à votre environnement de publication AEM de production, pour être utilisées par les applications.
Il existe différentes méthodes pour créer des requêtes persistantes, notamment :
L’IDE GraphiQL est la méthode préférée pour les requêtes persistantes. Pour conserver une requête donnée à l’aide de l’outil de ligne de commande cURL :
Préparez la requête avec une commande PUT sur l’URL du nouveau point d’entrée /graphql/persist.json/<config>/<persisted-label>
.
Par exemple, créez une requête persistante :
$ curl -X PUT \
-H 'authorization: Basic YWRtaW46YWRtaW4=' \
-H "Content-Type: application/json" \
"http://localhost:4502/graphql/persist.json/wknd/plain-article-query" \
-d \
'{
articleList {
items{
_path
author
main {
json
}
}
}
}'
À ce stade, vérifiez la réponse.
Par exemple, contrôlez le succès :
{
"action": "create",
"configurationName": "wknd",
"name": "plain-article-query",
"shortPath": "/wknd/plain-article-query",
"path": "/conf/wknd/settings/graphql/persistentQueries/plain-article-query"
}
Vous pouvez ensuite exécuter à nouveau la requête persistante avec une commande GET sur l’URL /graphql/execute.json/<shortPath>
.
Par exemple, utilisez la requête persistante :
$ curl -X GET \
http://localhost:4502/graphql/execute.json/wknd/plain-article-query
Mettez à jour une requête persistante avec une commande POST vers un chemin de requête existant.
Par exemple, utilisez la requête persistante :
$ curl -X POST \
-H 'authorization: Basic YWRtaW46YWRtaW4=' \
-H "Content-Type: application/json" \
"http://localhost:4502/graphql/persist.json/wknd/plain-article-query" \
-d \
'{
articleList {
items{
_path
author
main {
json
}
referencearticle {
_path
}
}
}
}'
Créez une requête ordinaire encapsulée.
Par exemple :
$ curl -X PUT \
-H 'authorization: Basic YWRtaW46YWRtaW4=' \
-H "Content-Type: application/json" \
"http://localhost:4502/graphql/persist.json/wknd/plain-article-query-wrapped" \
-d \
'{ "query": "{articleList { items { _path author main { json } referencearticle { _path } } } }"}'
Créez une requête ordinaire encapsulée avec le contrôle de cache.
Par exemple :
$ curl -X PUT \
-H 'authorization: Basic YWRtaW46YWRtaW4=' \
-H "Content-Type: application/json" \
"http://localhost:4502/graphql/persist.json/wknd/plain-article-query-max-age" \
-d \
'{ "query": "{articleList { items { _path author main { json } referencearticle { _path } } } }", "cache-control": { "max-age": 300 }}'
Créez une requête persistante avec des paramètres :
Par exemple :
$ curl -X PUT \
-H 'authorization: Basic YWRtaW46YWRtaW4=' \
-H "Content-Type: application/json" \
"http://localhost:4502/graphql/persist.json/wknd/plain-article-query-parameters" \
-d \
'query GetAsGraphqlModelTestByPath($apath: String!, $withReference: Boolean = true) {
articleByPath(_path: $apath) {
item {
_path
author
main {
plaintext
}
referencearticle @include(if: $withReference) {
_path
}
}
}
}'
Pour exécuter une requête persistante, une application cliente effectue une requête GET en utilisant la syntaxe suivante :
GET <AEM_HOST>/graphql/execute.json/<PERSISTENT_PATH>
Où PERSISTENT_PATH
est un chemin raccourci vers l’emplacement d’enregistrement de la requête persistante.
Par exemple, wknd
est le nom de la configuration et plain-article-query
est le nom de la requête persistante. Pour exécuter la requête :
$ curl -X GET \
https://publish-p123-e456.adobeaemcloud.com/graphql/execute.json/wknd/plain-article-query
Exécuter une requête avec des paramètres.
Les variables et valeurs de requête doivent être correctement encodées lors de l’exécution d’une requête persistante.
Par exemple :
$ curl -X GET \
"https://publish-p123-e456.adobeaemcloud.com/graphql/execute.json/wknd/plain-article-query-parameters%3Bapath%3D%2Fcontent%2Fdam%2Fwknd%2Fen%2Fmagazine%2Falaska-adventure%2Falaskan-adventures%3BwithReference%3Dfalse
Voir la section Utiliser les variables de requête pour plus d’informations.
Les variables de requête peuvent être utilisées avec les requêtes persistantes. Les variables de requête sont ajoutées à la requête précédée d’un point-virgule (;
) à l’aide du nom et de la valeur de la variable. Plusieurs variables sont séparées par des points-virgules.
Le modèle ressemble à ce qui suit :
<AEM_HOST>/graphql/execute.json/<PERSISTENT_QUERY_PATH>;variable1=value1;variable2=value2
Par exemple, la requête suivante contient une variable activity
pour filtrer une liste en fonction d’une valeur d’activité.
query getAdventuresByActivity($activity: String!) {
adventureList (filter: {
adventureActivity: {
_expressions: [
{
value: $activity
}
]
}
}){
items {
_path
adventureTitle
adventurePrice
adventureTripLength
}
}
}
Cette requête peut être conservée sous un chemin wknd/adventures-by-activity
. Pour appeler la requête persistante où activity=Camping
la requête ressemblerait à ceci :
<AEM_HOST>/graphql/execute.json/wknd/adventures-by-activity%3Bactivity%3DCamping
Notez que %3B
est l’encodage UTF-8 pour ;
et %3D
est l’encodage pour =
. Les variables de requête et les caractères spéciaux doivent être correctement encodés pour que la requête persistante s’exécute.
Les requêtes persistantes sont recommandées, car elles peuvent être mises en cache au niveau des couches Dispatcher et réseau de diffusion de contenu (CDN), ce qui améliore les performances de l’application cliente effectuant les requêtes.
Par défaut, AEM invalide le cache en fonction d’une définition de durée de vie (TTL). Ces TTL peuvent être définies par les paramètres suivants. Ces paramètres sont accessibles de plusieurs manières, avec des variantes dans les noms en fonction du mécanisme utilisé :
Type de cache | En-tête HTTP | cURL | Configuration OSGi | Cloud Manager |
---|---|---|---|---|
Navigateur | max-age |
cache-control : max-age |
cacheControlMaxAge |
graphqlCacheControl |
Réseau de diffusion de contenu | s-maxage |
surrogate-control : max-age |
surrogateControlMaxAge |
graphqlSurrogateControl |
Réseau de diffusion de contenu | stale-while-revalidate |
surrogate-control : stale-while-revalidate |
surrogateControlStaleWhileRevalidate |
graphqlStaleWhileRevalidate |
Réseau de diffusion de contenu | stale-if-error |
surrogate-control : stale-if-error |
surrogateControlStaleIfError |
graphqlStaleIfError |
Pour les instances de création, les valeurs par défaut sont les suivantes :
max-age
: 60s-maxage
: 60stale-while-revalidate
: 86400stale-if-error
: 86400Celles-ci :
cache-control
et/ou surrogate-control
; pour consulter des exemples, voir Gestion du cache au niveau de la requête persistante.Pour les instances de publication, les valeurs par défaut sont les suivantes :
max-age
: 60s-maxage
: 7200stale-while-revalidate
: 86400stale-if-error
: 86400Elles peuvent être remplacées :
au niveau de la requête persistante ; cela implique de publier la requête sur AEM à l’aide de cURL dans votre interface de ligne de commande et de publier la requête persistante.
L’IDE GraphiQL - Consultez Enregistrement de requêtes persistantes
Cela implique de publier la requête dans AEM à l’aide de cURL dans votre interface de ligne de commande.
Pour un exemple de la méthode PUT (création) :
curl -u admin:admin -X PUT \
--url "http://localhost:4502/graphql/persist.json/wknd/plain-article-query-max-age" \
--header "Content-Type: application/json" \
--data '{ "query": "{articleList { items { _path author } } }", "cache-control": { "max-age": 300 }, "surrogate-control": {"max-age":600, "stale-while-revalidate":1000, "stale-if-error":1000} }'
Pour un exemple de la méthode POST (mise à jour) :
curl -u admin:admin -X POST \
--url "http://localhost:4502/graphql/persist.json/wknd/plain-article-query-max-age" \
--header "Content-Type: application/json" \
--data '{ "query": "{articleList { items { _path author } } }", "cache-control": { "max-age": 300 }, "surrogate-control": {"max-age":600, "stale-while-revalidate":1000, "stale-if-error":1000} }'
Le cache-control
peut être défini au moment de la création (PUT) ou ultérieurement (par exemple, via une demande de POST). Le contrôle du cache est facultatif lors de la création de la requête persistante car AEM peut fournir la valeur par défaut. Consultez Conservation d’une requête GraphQL, par exemple pour conserver une requête à l’aide de cURL.
Les variables d’environnement Cloud Manager peuvent être définies avec Cloud Manager pour définir les valeurs requises :
Nom | Valeur | Service appliqué | Type |
---|---|---|---|
graphqlStaleIfError |
86400 | En fonction des besoins | En fonction des besoins |
graphqlSurrogateControl |
600 | En fonction des besoins | En fonction des besoins |
Pour gérer le cache globalement, vous pouvez configurer les paramètres OSGi pour la Configuration du service de requête persistante.
Pour le contrôle du cache, la configuration OSGi n’est appropriée que pour les instances de publication. La configuration existe sur les instances de création, mais elle est ignorée.
La configuration du service de requête persistante est également utilisée pour configurer le code de réponse à la requête.
Configuration OSGi par défaut pour les instances de publication :
lit les variables Cloud Manager si elles sont disponibles :
Propriétés de configuration OSGi | lit ceci | Variable Cloud Manager |
---|---|---|
cacheControlMaxAge |
lit | graphqlCacheControl |
surrogateControlMaxAge |
lit | graphqlSurrogateControl |
surrogateControlStaleWhileRevalidate |
lit | graphqlStaleWhileRevalidate |
surrogateControlStaleIfError |
lit | graphqlStaleIfError |
et, si elle n’est pas disponible, la configuration OSGi utilise les valeurs par défaut des instances de publication.
Par défaut, le PersistedQueryServlet
envoie une réponse 200
lors de l’exécution d’une requête, quel que soit le résultat réel.
Vous pouvez configurer les paramètres OSGi pour la configuration du service de requête persistante afin de contrôler quel code d’état est renvoyé par le point d’entrée /execute.json/persisted-query
, en cas d’erreur dans la requête persistante.
La configuration du service de requête persistante est également utilisée pour la gestion du cache.
Le champ Respond with application/graphql-response+json
(responseContentTypeGraphQLResponseJson
) peut être défini selon les besoins :
false
(valeur par défaut) :
peu importe que la requête persistante soit réussie ou non. La /execute.json/persisted-query
renvoie le code d’état 200
et l’en-tête Content-Type
renvoyé est application/json
.
true
:
le point d’entrée renvoie 400
ou 500
, le cas échéant, lorsqu’il existe une forme d’erreur lors de l’exécution de la requête persistante. En outre, le Content-Type
renvoyé est application/graphql-response+json
.
Voir https://graphql.github.io/graphql-over-http/draft/#sec-Status-Codes
Pour une utilisation par une application, tout caractère spécial utilisé lors de la création de variables de requête (c’est-à-dire les points-virgules (;
), le signe égal (=
), les barres obliques /
) doit être converti pour utiliser le codage UTF-8 correspondant.
Par exemple :
curl -X GET \ "https://publish-p123-e456.adobeaemcloud.com/graphql/execute.json/wknd/adventure-by-path%3BadventurePath%3D%2Fcontent%2Fdam%2Fwknd%2Fen%2Fadventures%2Fbali-surf-camp%2Fbali-surf-camp"
L’URL peut être divisée en plusieurs parties :
Partie de l’URL | Description |
---|---|
/graphql/execute.json |
Point d’entrée de requête persistante |
/wknd/adventure-by-path |
Chemin de requête persistante |
%3B |
Encodage de ; |
adventurePath |
Variable de requête |
%3D |
Encodage de = |
%2F |
Encodage de / |
%2Fcontent%2Fdam... |
Chemin codé vers le fragment de contenu |
En texte brut, l’URI de requête ressemble à ce qui suit :
/graphql/execute.json/wknd/adventure-by-path;adventurePath=/content/dam/wknd/en/adventures/bali-surf-camp/bali-surf-camp
Pour utiliser une requête persistante dans une application cliente, le SDK client AEM Headless doit être utilisé pour JavaScript, Java ou NodeJS. Le SDK client Headless codera automatiquement toutes les variables de requête correctement dans la requête concernée.
Les requêtes persistantes doivent toujours être créées sur un service de création AEM, puis publiées (répliquées) sur un service de publication AEM. Souvent, les requêtes persistantes sont créées et testées dans des environnements inférieurs tels que les environnements locaux ou de développement. Il est alors nécessaire de promouvoir les requêtes persistantes dans des environnements de niveau supérieur, ce qui rend ces requêtes disponibles dans un environnement de publication AEM de production pour que les applications clientes puissent les utiliser.
Les requêtes persistantes peuvent être intégrées aux packages AEM. Les packages AEM peuvent ensuite être téléchargés et installés dans différents environnements. Les packages AEM peuvent également être répliqués d’un environnement de création AEM vers des environnements de publication AEM.
Création d’un package :
persistentQueries
sous la configuration. Par exemple, pour la configuration wknd
, le chemin d’accès complet sera /conf/wknd/settings/graphql/persistentQueries
.Une fois le package créé, vous pouvez :