Optimized content workflows with AEM's latest headless APIs

In this session, we explore how AEM's Content Fragment Management and Delivery headless APIs work together to help streamline content authoring and delivery workflows.

Combined with the Admin and Editor UIs, the Management API simplifies content creation and management, while the Delivery API serves Content Fragments efficiently, using a streamlined JSON schema, optimized caching mechanisms and dynamic cache regeneration.

You will learn:

This session will help software developers and architects make the best use of AEM's Headless latest capabilities, focusing on content management and delivery.

Piotr

Are the new APIs available on premise?

Rainer Bartl

Not yet.

Radu Cotescu

All of these APIs are available for now exclusively on AEM as a Cloud Service. I know however that an implementation for 6.5 is in the works and likely to be published soon (a matter of months).

Robert Wunsch

What does "SharePoint support for CRUD" implementation mean (which is "in progress to be supported")?

lenardpalko

SharePoint support for CRUD, means that the Content API will support the editing of the Sharepoint content as well using the same API surface.

Catalina

If you had an EDS Site which is backed by Pages that are authored in SharePoint, the Content API would permit to access and manipulate those in the same manner. What the Content API for SharePoint brings to the table is the ability to see the structure of a Page AND reason about, what can go onto that Page.

Helge

Are the events send in realtime or batched?

Radu Cotescu

What is the nuance you're looking for? There are components in the system that will batch some of the events for efficiency. However, the events are available in a matter of seconds after the changes have been persisted in the repository. The delivery mechanism via Adobe IO Events will be either web-hooks or journalling.

Helge

Like what happens when I import 100cf and publish them. Will this result in 100 publish events or 1event containing 100 paths

Radu Cotescu

Got it – 1 event per object, always. The events are documented at https://developer.adobe.com/experience-cloud/experience-manager-apis/api/stable/sites/#tag/Fragment-Events. They have a standard CloudEvents envelope, with each even type documenting it specific payload for the `data` property.

Arko

Will this feature be available for AMS

Catalina

For now everything is on AEM cloud - but there is work in progress to backport the Management APIs in AEM 6.5 as well

Robert Wunsch

Do you authenticate against these AEM-CF-management-APIs through developer-console? What is the integration to use in developer-console?

Radu Cotescu

You will need to use the AEM CS Sites Content Management API card in the Adobe Developer Console. All authentication flows Jose presented earlier today are available.

Tomasz Sobczyk

Does the eventing now distinguish between publication to preview and publish? This info used to be missing in the past (which was rendering the page events not useful for someone who uses preview envs in aem)

Radu Cotescu

Yes, there's a tier property in the event payload - see for example the Content Fragment published event: https://developer.adobe.com/experience-cloud/experience-manager-apis/api/stable/sites/#operation/content-fragment-published!path=data/tier&t=request

Maverick

How would these new api compare against a complex scenario as the one see in the previous talk? Could they be a better fit? Would they solve some of the problems we saw with GraphQL?

Radu Cotescu

They are a different paradigm. Each approach has pros and cons. IMO, they are all tools in a toolbox. In some cases the GraphQL persisted queries might be a good approach (i.e. light structures for your your models, not a large number of references, you only need a subset of the fields), in other cases the OpenAPI APIs are a better fit (i.e. management, since the GraphQL APIs doesn't allow mutations, delivery of large structures like Lénárd showed in the presentation). The advantage with the OpenAPI APIs is that they all more or less look the same, regardless of the domain (Sites, Assets, Forms, Translations, etc.)

npeltier

With active cache invalidation, do you plan on increasing TTLs?

lenardpalko

Currently TTLs are not configurable, but I imagine that increasing them could be possible, but there are risks as well with having too long TTL.

Amine

What are the recommended migration strategies for existing AEM implementations looking to adopt these new fragmented models and APIs?

lenardpalko

As mentioned on the stage, the migration would be required only for client applications, the Management API and the Delivery API both operate on the existing Content Fragment resources so there is not need to migrate those.

Maverick

For new content fragments that may match a request but were not referenced anywhere because they did not exist, is this TTL based?

lenardpalko

The cache is going to be populated when the Content Fragment is requested for the first time and it will be served from cache until either the model, the fragment or any of the references (assets or fragments) are updated.

Georg Henzler

I assume JCR permissions are ignored on that new delivery tier. If restrictions of content are needed, what is the correct approach?

lenardpalko

Yes, you are right. Unfortunately the CDN cannot serve from cache authenticated requests, so those will all be sent to the origin. Maybe the authnetication at the edge will be able to handle these in the future.

MOHIT KATARIA

1. How will ACL's come into picture in these new apis? 2. in case of cache invalidation on CDN, you mentioned secondary cache will help to fill cdn cache but we also have cache on aem, how is this different?

lenardpalko

1. The management API will follow the ACL's, but Delivery API serves unauthenticated content, because CDN will forward all requests containing authentication to origin. Maybe the Auth at the Edge will be able to manage this case. 2. If you are using the Delivery API the request will not hit AEM at all, everything will be managed at the Delivery Service level.

sabdouni

Is this the new official way to do headless on AEMcaaS? If yes, we don't need a Publisher & Dispatcher?

lenardpalko

As Radu already mentioned in an earlier response. These are different paradigms and serve different needs. Some applications still might need GraphQL response, while others might could benefit of the new Delivery API. Let us know your use-case and we can help you choose the best suitable for your application.

Helge

Is the optimized image url from graphql also exposed via these apis or just the plain paths?

Radu Cotescu

You only get asset IDs so that you can freely use whatever API you want after that, whether that is another management API or a delivery one (i.e. Dynamic Media with Open API).

Helge

Okay but this will then result in a request waterfall sadly which is not always ideal

Radu Cotescu

You anyways end up with that – you will take the image URL from the GraphQL output and put it into an <img>/<picture> tag. It's the exact same paradigm in the end. Coffee? :D

Helge

Yes! Let’s also hang later if there is anything today

Arko

Will it cost extra on the normal license?

Catalina

Management API is available out of the box in the product Delivery API requires an onboarding request, since it is not an official way - but that has no extra cost

SessionLost

can we get all the shared links at one place?

Catalina

Sure, they will be present on the last slide in the powerpoint presentation - that will be posted soon