AEM driftsättning av SPA utan headless
AEM Headless single-page app (SPA) deployment omfattar JavaScript-baserade applikationer som byggts med ramverk som React eller Vue och som konsumerar och interagerar med AEM på ett headless sätt.
För att driftsätta en SPA som interagerar AEM utan att vara i kö måste du vara värd för SPA och göra den tillgänglig via en webbläsare.
SPA
En SPA består av en samling med inbyggda webbresurser: HTML, CSS och JavaScript. De här resurserna genereras under build-processen (till exempel npm run build) och distribueras till en värd som ska användas av slutanvändare.
Det finns olika värdalternativ beroende på organisationens krav:
-
Molnleverantörer, till exempel Azure eller AWS.
-
Lokal som är värd i ett företags datacenter
-
Värdplattformar på klientsidan som AWS Amplify, Azure App Service, Netlify, Heroku, Vercel osv.
Distributionskonfigurationer
Det viktigaste att tänka på när du är värd för en SPA som interagerar med AEM utan huvud är om SPA nås via AEM domän (eller värd), eller på en annan domän. Orsaken är SPA webbprogram som körs i webbläsare och därför omfattas av webbläsarens säkerhetsprofiler.
Delad domän
En SPA och AEM delar domäner när båda är åtkomliga för slutanvändare från samma domän. Till exempel:
- AEM nås via:
https://wknd.site/ - SPA nås via
https://wknd.site/spa
Eftersom både AEM och SPA är åtkomliga från samma domän kan SPA göra XHR till AEM Headless-slutpunkter utan CORS, och tillåta delning av HTTP-cookies (till exempel AEM login-token-cookies).
Det är upp till dig att dirigera SPA- och AEM-trafik till den delade domänen: CDN med flera ursprung, HTTP-server med omvänd proxy, som är värd för SPA direkt i AEM och så vidare.
Nedan visas distributionskonfigurationer som krävs för SPA produktionsdistributioner, när de finns på samma domän som AEM.
Olika domäner
En SPA och AEM har olika domäner när slutanvändare från olika domäner har åtkomst till dem. Till exempel:
- AEM nås via:
https://wknd.site/ - SPA nås via
https://wknd-app.site/
Eftersom AEM och SPA används från olika domäner tillämpar webbläsare säkerhetsprofiler som korsdomänsresursdelning (CORS) och förhindrar delning av HTTP-cookies (till exempel AEM login-token-cookies).
Nedan visas distributionskonfigurationer som krävs för SPA av produktionsdistributioner, när dessa lagras på en annan domän än AEM.
Exempel SPA distribution på olika domäner
I det här exemplet distribueras SPA till en Netlify-domän (https://main--sparkly-marzipan-b20bf8.netlify.app/) och SPA använder AEM GraphQL API:er från den AEM Publish-domänen (https://publish-p65804-e666805.adobeaemcloud.com). Skärmbilderna nedan visar CORS-kraven.
-
SPA hanteras från en Netlify-domän, men gör ett XHR-anrop till AEM GraphQL API:er på en annan domän. Den här begäran över flera platser kräver att CORS har konfigurerats AEM för att tillåta begäran från Netlify-domänen att få åtkomst till dess innehåll.
-
XHR-begäran inspekteras till AEM GraphQL API.
Access-Control-Allow-Originfinns, vilket anger för webbläsaren att AEM tillåter begäran från den här Netlify-domänen att komma åt dess innehåll.Om AEM CORS saknades eller inte innehöll Netlify-domänen, misslyckas webbläsaren med XHR-begäran och rapporterar ett CORS-fel.
Exempel på enkelsidig app
Adobe tillhandahåller ett exempel på en enkelsidig app som kodats i React.
Ett exempel på en enda sida, skrivet i React, som använder innehåll från AEM Headless GraphQL API:er.
Ett exempel på en enkelsidig app, skrivet i Next.js, som använder innehåll från AEM Headless GraphQL API:er.