Content API Impl. Options

Considerations for the future Implementation of the Content API

There are different options for a production deployment of the Content API and we need to evaluate a Worker-based with Javascript approach over an AEM Java based approach. Both have pros and cons.

JavaScript (Worker / out‑of‑process)	AEM (Java‑based)
Pros – Multiple orders‑of‑magnitude faster turnaround (PLG) for feature iterations (≤ 30s vs ≥ 10 min) – Likely better horizontal scaling via serverless/edge versus JVM – Can become a Content API Service to expose other content stores (SharePoint, G‑Drive, DA, …)	Pros – API implementation follows other AEM APIs → high code reuse – Implementation runs close to the data (JCR) – Routes needing several resource look‑ups are fast – Security (IMS Auth, ACLs) already built‑in – Operational stack (monitoring, Splunk logs, API Router…) already in place – Flexible deployment to Author and Publish buckets
Cons – Routes touching many resources require multiple AEM JSON calls – No direct code reuse from existing AEM API implementations – (For Cloudflare, monitoring & logging needs to be set up; with EthosFlex they are be included)	Cons – Slower iteration cadence – tied to the AEM release cycle – Experimentation today is cumbersome – private releases must be built and installed on each selected customer instance, which then has to be removed from daily‑update service so the experimental bundle survives updates. – In‑progress requests consume JVM resources