AEM Headless: A Glimpse of Developer Tools
Are you a JavaScript developer looking to create web applications with Adobe Experience Manager (AEM)? You may have encountered obstacles with the Java tooling requirements, such as JDK, Maven, and IntelliJ plug-ins, which can be overwhelming. However, with AEM Headless, JavaScript developers can leverage their preferred tools and frameworks, like React and Angular, and take advantage of the vast NPM ecosystem.
This session highlights the latest AEM developer tools for building frontend web applications with JavaScript, including Headless GraphQL clients, content fragment REST API clients, and CLI tools. Attendees will learn how to use these tools in practical scenarios and discover best practices for maximizing productivity.
By the end of this talk, you will have gained insight into how AEM Headless and its accompanying frontend developer tools simplify web development and enable JavaScript developers to build high-performing, scalable web applications with ease.
robertb
Does the API and tools support working with CF variations?
Radu Cotescu
Yes, we can talk about it later today in the panel discussions or in the meet the experts session or tomorrow after my API-first talk. 😂
Henry Kuijpers
Are you planning to go a bit further with the API and support for example managing/manipulating assets (and other types of content) as well?
Duy Nguyen
The API shown in this session is mainly for CFs. There is already Assets HTTP API for managing assets: https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/assets/admin/mac-api-assets.html?lang=en. What are the other types of content that you have in mind?
robertb
Are these simplified APIs exposed in the Java runtime as well?
robertb
The current java CF apis are overly complicated. The sdk here showcased a significantly simpler way of creating models and fragments. Looking forward to the java client
Duy Nguyen
Thanks for your interest. Currently we don't have plan to add Java sdk for the new REST API, mainly because the use case for out-of-process Java extensibility is slim. If you have a clear use case in mind, happy to discuss further.
Rogier
Is there multiligual / translation support?
Duy Nguyen
I understand this question in the context of AEM Headless. You might leverage variations to have multiple translations for the same content. Also, there's a doc page showing how you could structure your content, integrating with translation services, and some examples to create multilingual sites in the client: https://experienceleague.adobe.com/docs/experience-manager-learn/getting-started-with-aem-headless/how-to/localized-content.html?lang=en
Shakkir
How does integration with dynamic media work? We are facing an issue that Graphql not fetching scene7 metadata. There was another round of request to a custom built servlet. That felt inefficient. A work around that we are trying is by intercepting response (persisted queries) and enriching the response with DM metadata via another servlet.
Duy Nguyen
What I did to integrate with DM / scene7 was having a custom image loader in the client side (where you render the app, e.g. React), which would fetch the images from s7 instead of AEM publish. Not sure if / how it can be done on the API level. On another note, slightly related: the GraphQL result also gives optimized image URLs if you have your assets in AEM: https://experienceleague.adobe.com/docs/experience-manager-learn/getting-started-with-aem-headless/how-to/images.html?lang=en