The query can now be requested via GET request and the result will be cached depending on the dispatcher settings.
Use this URL for the GET request
- /graphql/execute.json/my-project/get-simple-article;apath=%2Fcontent%2Fdam%2Fmy-project%2Ftest-article
Don't forget to replicate the query under /conf/my-project/settings/graphql/persistentQueries to make the persistent query available on the publish instance.
When to use GraphQL
We now have a basic understanding what GraphQL looks like and how it can be used in AEM. But as with all technologies it needs the right use case.
GraphQL offers many possiblities, and especially with Apps or Single Page Applications (SPA) it can bring the flexibility that most developers wish for.
Some other scenarios are
- Dynamic web components
- Rapid Prototyping
- Multiple output channels with different frontend technologies
- Content Management Purposes in combination with Assets HTTP API
Example for SPA with GraphQL in AEM
https://github.com/adobe/aem-guides-wknd-graphql
Limitations
In the backend, AEM translates the GraphQL queries to SQL2 queries. In case we have complex GraphQL queries, we are fully depending on AEM to produce performant SQL2 queries for us. This can lead to slow performance, if not looked at carefully.
GraphQL in AEM is quite new and it brings a lot of new possibilites, especially for fast prototyping. For big data structures it can reach limitations in regards of how data can be requested.
The Alternatives for Headless Content in AEM
Assets HTTP API
The Assets API of AEM is a well established and quite powerfull API to request Content Fragments and other Assets as JSON Data. But the strong side of Assets API is the possibility to add, edit and delete data. When requesting data it is restricted to simple listing of folder contents or when requesting Content Fragments only the whole Content Fragment can requested and not parts of it.
In short, use Assets HTTP API if
- You are fine getting all data, even data that you don't need
- Caching is no big topic for you
- You need an API to store, update, delete data and not only request it
Sling Model Exporter (Components/Experience Fragments)
This is the "normal" AEM way. You create pages on the pages components and then write your Sling Model Exporter java code to export the data that you need. You can also use the Adobe Core Components and include Content Fragments into your pages quite simple.
In short, use Sling Model Exporter if you
- are fine with using "export pages" that need to be created and published separatly from the Content Fragments to update cache etc.
- want to write and deploy code for custom/special requests
What the future holds
Adobe is pushing AEM with GraphQL and in the documentation we can read
“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.”
Source
This is a very good sign and we are excited what the future will bring for AEM Headless with GraphQL.
Further information
More information on GraphQL with AEM
https://experienceleague.adobe.com/docs/experience-manager-65/assets/extending/graphql-api-content-fragments.html?lang=en
Example Queries
https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/headless/graphql-api/sample-queries.html?lang=en