Implementazioni di AEM Headless SPA

Le implementazioni delle app (SPA) a pagina singola AEM headless coinvolgono applicazioni basate su JavaScript create utilizzando framework come React o Vue, che utilizzano e interagiscono con i contenuti in AEM in modo headless.

La distribuzione di un SPA che interagisce AEM in modo headless comporta l’hosting del SPA e la sua accessibilità tramite un browser web.

Host del SPA

Un SPA è composto da una raccolta di risorse web native: HTML, CSS e JavaScript. Queste risorse vengono generate durante la build processo (ad esempio, npm run build) e distribuita in un host per il consumo da parte degli utenti finali.

Ci sono varie hosting a seconda dei requisiti aziendali:

Provider cloud quali Azure o AWS.
On-Premise hosting in un'azienda centro dati
Piattaforme di hosting front-end quali AWS Amplifica, Servizio app di Azure, Netliare, Heroku, Vercel, ecc.

Configurazioni di distribuzione

La considerazione principale quando si ospita un SPA che interagisce con AEM headless, è se l’accesso al SPA avviene tramite dominio (o host) AEM o su un dominio diverso. Il motivo è SPA le applicazioni web in esecuzione nei browser web e sono quindi soggette ai criteri di sicurezza dei browser web.

Dominio condiviso

Un SPA e AEM condividono i domini quando entrambi gli utenti finali hanno accesso dallo stesso dominio. Esempio:

AEM è accessibile tramite: https://wknd.site/
SPA è accessibile tramite https://wknd.site/spa

Poiché sia AEM che SPA sono accessibili dallo stesso dominio, i browser web consentono al SPA di creare endpoint XHR per AEM Headless senza la necessità di CORS e consentono la condivisione di cookie HTTP (come AEM login-token cookie).

Il modo in cui il traffico SPA e AEM viene instradato sul dominio condiviso, dipende da te: CDN con origini multiple, server HTTP con proxy inverso, hosting del SPA direttamente in AEM e così via.

Di seguito sono riportate le configurazioni di distribuzione necessarie per le distribuzioni di produzione SPA, se ospitate sullo stesso dominio di AEM.

SPA si connette a	Autore AEM	AEM Publish	Anteprima AEM
Filtri del Dispatcher	✘	↓	↓
Condivisione delle risorse tra le origini (CORS)	✘	✘	✘
Host AEM	✘	✘	✘

Domini diversi

Un SPA e AEM hanno domini diversi quando gli utenti finali accedono da un dominio diverso. Esempio:

AEM è accessibile tramite: https://wknd.site/
SPA è accessibile tramite https://wknd-app.site/

Poiché l’accesso a AEM e SPA da domini diversi, i browser web applicano criteri di sicurezza come condivisione delle risorse tra origini (CORS)e impedisce la condivisione di cookie HTTP (come AEM login-token cookie).

Di seguito sono riportate le configurazioni di distribuzione necessarie per SPA distribuzioni di produzione, quando ospitate su un dominio diverso da AEM.

SPA si connette a	Autore AEM	Pubblicazione AEM	Anteprima AEM
Filtri del Dispatcher	✘	↓	↓
Condivisione delle risorse tra le origini (CORS)	↓	↓	↓
Host AEM	↓	↓	↓

Esempio SPA distribuzione su domini diversi

In questo esempio, il SPA viene distribuito su un dominio Netlify (https://main--sparkly-marzipan-b20bf8.netlify.app/) e il SPA utilizza AEM API GraphQL dal dominio di pubblicazione AEM (https://publish-p65804-e666805.adobeaemcloud.com). Le seguenti schermate evidenziano i requisiti CORS.

Il SPA viene servito da un dominio Netlify, ma effettua una chiamata XHR a AEM API GraphQL su un dominio diverso. Questa richiesta intersito richiede CORS da configurare su AEM per consentire la richiesta del dominio Netlify di accedere al relativo contenuto.
Ispezione della richiesta XHR all’API GraphQL AEM, la Access-Control-Allow-Origin è presente, indicando al browser Web che AEM consente la richiesta da questo dominio Netlify di accedere al relativo contenuto.

Se il AEM CORS Mancava o non includeva il dominio Netlify, il browser web avrebbe fallito la richiesta XHR e segnalato un errore CORS.