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