Content API Impl. Options

Considerations for the future implementation of the Content API

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

AEM Java based implementation

Pro	Con
- API impl. follows other AEM API impls, high re-use of code from others	- slow iteration as we depend on AEM release
- API impl close to data (JCR)	- in-progress consumes JVM resources
- API routes which require multiple resource looks are fast
- API Security (IMS Auth etc.) and Content Security (ACLs) are already solved and sort ob build in
- Operational aspects (Monitoring, Logs in Splunk, API Router, etc.) are already solved
- Flexible deployment for AEM Author & AEM Publish buckets

JS out of process based implementation

Pro	Con
- Faster turn arround (PLG)	- API routes which require multiple resources need multiple AEM JSON calls
- Likely better scaling by useing serverless/edge stack vs. JVM	- No code re-use / references from previous AEM API implementations
- Could be blueprint for other Content API impls for Sharepoint, GDrive, DA	- Operational aspects (Monitoring, Logs in Splunk, API Router, etc.) must be set up seperatly

Alternative presentation

JavaScript (Worker / out‑of‑process)	AEM (Java‑based)
Pros – Multiple Orders of magnitude Faster turnaround (PLG) for feature iterations – Likely better horizontal scaling via serverless/edge versus JVM - Can become a blueprint for future Content‑API variants (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 etc. needs to be setup, with EthosFlex it would be included)	Cons – Slower iteration cadence—tied to AEM release cycle – In‑progress requests consume JVM resources