Skip to content

Home

Jump to bottom
Tanju Erinmez edited this page Apr 23, 2025 · 9 revisions

Hackathon 2025 ‐ XWalk Render Offloading with Content API

The hackathon focused on implementing the new Content API Specification for an AEM Edge variant (known internally as “XWalk”). The primary goal was to accelerate development by moving certain functionalities out of AEM Sites and into lightweight Cloudflare-based services in front of the AEM Cloud instances. A related objective was to evaluate the developer experience of using the new Content API and identify opportunities to improve it.

Innovations

  • Microservices: Two prototype services were created—one to translate incoming requests to Content API calls, and another acting as the Content API Service itself.

  • Standardized Content API: By adopting a single, standardized Content API, future features and products within Adobe such as automated content improvements (auto-fix agents in Sites Optimizer) and direct navigation to last-edited pages (in LaunchPad) become significantly easier to implement.

  • Rapid Iteration: Thanks to the Cloudflare Workers approach, development and deployment cycles took minutes rather than hours, allowing frequent experimentation.

Business Impact

  • Faster Time-to-Market: Offloading rendering and content retrieval tasks to microservices cut down on reliance on core AEM infrastructure and reduced IT overhead.

  • Enhanced Developer Productivity: Standardizing content operations under one API simplified the integration process across multiple platforms (AEM, Edge, SharePoint, etc.), lowering the learning curve and increasing reusability.

  • Scalability: The decoupled architecture allows services to be updated, tested, and scaled independently without disrupting the main AEM environment. Experimentation with new Content API use cases become very agile.

Key Takeaways

  • Positive Developer Experience: Lightweight tooling and zero IT involvement were key enablers for rapid prototyping and innovation.

  • Content API Design Feedback: The hackathon surfaced the need for parts of the Content API (/pages/byUrl in particular) to be on api.adobeaemcloud.com and not in a bucket. Reason being, the user of the API wants to work off a public page URL and should not need to be burdened how to locate the service endpoint first before he can actually start working with the page.

  • Caching & Performance: Each Edge Delivery Services rendering request currently triggers three separate calls to AEM—one for site name resolution, one for page data, and one for page content. Introducing a caching strategy (to store site ID-to-name mappings) could reduce these calls to two. Additionally, combining /pages/{pageId} and /pages/{pageId}/content into a single query could theoretically reduce calls to just one.

Next Steps

  • Rework Content API Specification: As mentioned the byUrl endpoint has not proven that useful, what would be better is a way to get to the html directly given a siteId and the publishPath of the Page. Also, it was found that if only the json would contain the relevant page data and not all child pages, it would reduce the amount of overfetching. So it will be proposed to introduce a new resolver endpoint /sites/{siteId}/contentByPath/{pagePublishPath} which permits to implement the HTML rendering in a Content API Service but ask the Content API deployed with AEM to gather an efficient application/json representation (see sequence diagram below).

  • Production Deployment: Evaluate a Worker-based & Javascript developer friendly way to deploy on EthosFlex without bringing in heavy platforms such as OpenWhisk. Also see https://github.com/adobe-rnd/sites-content-api-poc/wiki/Content-API-Impl.-Options

  • Extend API Coverage: Implement additional Content API endpoints, formalize the caching strategy for site name lookups. Identify discovery use cases in the Content API and propose to move those to api.adobeaemcloud.com .

Clone this wiki locally