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:

  1. Molnleverantörer, till exempel Azure eller AWS.

  2. Lokal som är värd i ett företags datacenter

  3. 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.

SPA ansluter till →
AEM
AEM Publish
AEM
Dispatcher-filter
Cross-origin resource sharing (CORS)
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.

SPA ansluter till →
AEM
AEM Publish
AEM
Dispatcher-filter
Resursdelning mellan ursprung (CORS)
AEM värdar

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.

  1. 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.

    SPA begäran från SPA och AEM

  2. XHR-begäran inspekteras till AEM GraphQL API. Access-Control-Allow-Origin finns, 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.

    CORS-svarshuvud AEM GraphQL API

Exempel på enkelsidig app

Adobe tillhandahåller ett exempel på en enkelsidig app som kodats i React.

Reagera-app

Reagera-app

Ett exempel på en enda sida, skrivet i React, som använder innehåll från AEM Headless GraphQL API:er.

Visa exempel

Next.js-appen

Next.js-appen

Ett exempel på en enkelsidig app, skrivet i Next.js, som använder innehåll från AEM Headless GraphQL API:er.

Visa exempel

recommendation-more-help
e25b6834-e87f-4ff3-ba56-4cd16cdfdec4