As the need to reach customers through new channels and devices such as mobile apps, smart devices, digital assistants and others is on the rise, traditional Content Management Systems (CMS) are being challenged by ‘headless’ CMS. This is why moving from a traditional CMS to headless architecture is one of the hot topics of interest today for the tech leadership in any organization.
A headless CMS architecture is a content-only repository that can be accessed by a large number of front-end sources to present the content to end-users. Headless CMS does not manage the presentation layer and only focuses on content. The content in headless CMS is typically accessed via content application program interfaces (APIs).
However, despite the sound architectural benefits of moving to headless deployments of Adobe Experience Manager (AEM), out-of-the-box (OOTB) AEM content services with headless capabilities have very limited features.
In this article, we will discuss how AEM content services> can be integrated with GraphQL to deliver the use cases not supported by OOTB AEM content services.
Why Integrate GraphQL with AEM content services?
GraphQL is user friendly for front-end developers. It allows them to request multiple data sets leveraging a single endpoint. Considering the rising popularity of ‘React’ and ‘Angular,’ GraphQL APIs are a good choice for front-end developers, providing ample flexibility for accessing content. GraphQL caters extremely efficiently to one of the basic challenges i.e. delivering a personalized data set over the rest of the APIs.
Drawbacks of OOTB content services
- OOTB asset APIs support URL based search only. Any use case required to support full text-based search is not supported by OOTB Asset APIs
- OOTB asset APIs do not support field/tag-based search. Any use case like article search etc. is not supported by OOTB asset APIs
- Content fragment models are currently not supported
- In future, if the organization decides to replace AEM with some different CMS, then all-consuming channels will have a downstream impact
- Service orchestration is not possible. If AEM content needs to be merged with some other data before sending it to channels, it is not supported by OOTB content services
In a nutshell, OOTB content services only support basic use cases and are still far from reaching maturity.
How GraphQL integration with AEM APIs solves these problems
- Service orchestration can happen at GraphQL API level. It is easy to return non CMS content as a part of the API response.
- Ensures a clean JSON response since the response can be tweaked as needed. OOTB content service response gives JSON output with lot of additional details, which can be confusing for channels.
- Cache layer can be built between GraphQL and AEM including a serverless deployment, making the application very scalable.
- AEM will be abstracted for consuming channels. Any changes to AEM services will not have a downstream channel impact.
- Various deployment options like Adobe I/O (serverless), AWS AppSync (serverless), GraphQL (server) are available.
Business Value Delivered
- Faster time to market as front-end developers can leverage flexible graph APIs to get the desired response
- With GraphQL API options, application may be near infinite scalability, which reduces AEM license costs
Impact on IT
- AEM upgrade/ CMS changes will have minimal impact on consuming channels, which means less effort is spent on application support
- Quick development process as GraphQL APIs are front-end developer friendly
- Developers have the option to use OOTB content services, Sling exporters, or query builders depending on use cases
- Service orchestration happens outside AEM which eventually reduces the load on the AEM server
Mindtree’s work with clients in this space
Mindtree has helped one of the largest investment banks in building the architecture of the digital platform, capable of exposing AEM content to consuming channels via GraphQL APIs.
Summary and Conclusion
GraphQL-based AEM content services enable applications to access content, specific for that application. It adds a lot of flexibility to the architecture and the ways different applications can access the AEM content. It is a cleaner approach as front-end developers are no longer required to massage the OOTB AEM content service response, and instead need to deal with only one API endpoint.
Connect with the author Pawan Khatri (firstname.lastname@example.org) or go-to market leader Harshal Gaikwad (Harshal.Gaikwad@mindtree.com) to know more about the advantage your business can get with customized solutions based on AEM content services and GraphQL APIs.