Die Query kann nun per GET-Request erfolgen und das Ergebnis wird je nach Dispatcher-Einstellungen zwischengespeichert.
Verwenden Sie diese URL für den GET-Request
- /graphql/execute.json/my-project/get-simple-article;apath=%2Fcontent%2Fdam%2Fmy-project%2Ftest-article
Vergessen Sie nicht, die Query unter /conf/my-project/settings/graphql/persistentQueries zu replizieren, damit die persistente Query auf der Publisherinstanz verfügbar ist.
Wann GraphQL verwendet werden sollte
Wir haben nun ein grundlegendes Verständnis davon, wie GraphQL aussieht und wie es in AEM verwendet werden kann. Aber wie bei allen Technologien braucht es den richtigen Anwendungsfall.
GraphQL bietet viele Möglichkeiten, und gerade bei Apps oder Single Page Applications (SPA) kann es die Flexibilität bringen, die sich die meisten Entwickler wünschen.
Einige andere Szenarien sind
- Dynamische Webkomponenten
- Schnelles Prototyping
- Mehrere Ausgabekanäle mit unterschiedlichen Frontend-Technologien
- Content-Management-Zwecke in Kombination mit Assets HTTP API
Beispiel für SPA mit GraphQL in AEM
https://github.com/adobe/aem-guides-wknd-graphql
Grenzen
Im Backend wandelt AEM die GraphQL Queries in SQL2 Queries um. Wenn wir komplexe GraphQL Queries haben, sind wir vollständig davon abhängig, dass AEM performante SQL2 Queries für uns erstellt. Dies kann zu einer langsamen Abfrage führen, wenn nicht sorgfältig darauf geachtet wird.
GraphQL in AEM ist recht neu und bietet viele neue Möglichkeiten, insbesondere für schnelles Prototyping. Bei großen Datenstrukturen kann es an Grenzen stoßen, wenn es darum geht, wie Daten angefordert werden können.
Die Alternativen für Headless Inhalte in AEM
Assets HTTP API
Die Assets API von AEM ist eine gut etablierte und leistungsfähige API zum Abrufen von Content Fragments und anderen Assets als JSON-Daten. Die Stärke der Assets-API ist jedoch die Möglichkeit, Daten hinzuzufügen, zu bearbeiten und zu löschen. Bei der Abfrage von Daten ist sie auf die einfache Auflistung von Ordnerinhalten beschränkt und bei der Abfrage von Content Fragments kann nur das gesamte Content Fragment und nicht Teile davon abgefragt werden.
Kurz gesagt, verwenden Sie die Assets HTTP API, wenn
- Sie damit einverstanden sind, alle Daten zu bekommen, auch die, die Sie nicht brauchen
- Caching kein großes Thema für Sie ist
- Sie eine API brauchen, um Daten zu speichern, zu aktualisieren und zu löschen und nicht nur um sie abzufragen
Sling Model Exporter (Components/Experience Fragments)
Dies ist die "normale" AEM-Methode. Sie erstellen Pages mit Komponenten und schreiben dann Ihren Sling Model Exporter-Javacode, um die benötigten Daten zu exportieren. Sie können auch die Adobe Core Components verwenden und ganz einfach Content Fragments in Ihre Pages einfügen.
Kurz gesagt, verwenden Sie Sling Model Exporter, wenn Sie
- mit der Verwendung von "Export-Pages" einverstanden sind, die separat von den Content Fragments erstellt und veröffentlicht werden müssen, um den Cache zu aktualisieren usw.
- Code für benutzerdefinierte/spezielle Anfragen schreiben und bereitstellen möchten
Was die Zukunft verspricht
Adobe treibt AEM mit GraphQL voran und in der Dokumentation können wir lesen
„The AEM GraphQL API offers total control on the JSON output, and is an industry standard for querying content.
Moving forward, AEM is planning to invest in the AEM GraphQL API.“
Quelle
Dies ist ein sehr gutes Zeichen und wir sind gespannt, was die Zukunft für AEM Headless mit GraphQL bringen wird.
Weiterführende Informationen
Weitere Informationen zu GraphQL mit AEM
https://experienceleague.adobe.com/docs/experience-manager-65/assets/extending/graphql-api-content-fragments.html?lang=en
Beispiel Queries
https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/headless/graphql-api/sample-queries.html?lang=en