Vägen till din första upplevelse med AEM utan headless path-to-first-experience

I den här delen av AEM Headless Developer Journey får du en förståelse för hur du implementerar din första headless-upplevelse när det gäller AEM, inklusive planeringsöverväganden, och du får även lära dig bästa praxis för att göra din väg så smidig som möjligt.

Story hittills story-so-far

I det föregående dokumentet om den AEM resan utan huvud, Getting Started with AEM Headless as a Cloud Service, lärde du dig den grundläggande teorin om vad ett headless CMS är och du bör nu:

Den här artikeln bygger på dessa grundläggande funktioner så att du förstår hur du förbereder ett eget AEM headless-projekt.

Syfte objective

Det här dokumentet hjälper dig att förstå de steg som krävs för att implementera ditt första projekt. Efter att ha läst den bör du:

Krav requirements

Innan du fortsätter med det här dokumentet måste du kontrollera att du har granskat det tidigare dokumentet på AEM Headless Developer Journey, Getting Started with AEM Headless as a Cloud Service, så att du är säker på att du:

Planering för lyckat resultat planning-for-success

För att starta ditt första AEM headless-projekt måste ni se till att ni har en innehållsmodell som stöder den personalisering och de uppdateringar ni vill göra i alla era kanaler.

Förutom AEM vill du också se till att du har en korrekt utvecklingsmiljö konfigurerad om du skapar ett klientprogram så att du kan testa klienten mot API-anrop till AEM as a Cloud Service.

Definiera innehållsmodeller och API:er defining-models

Ni vill skapa en enhetlig upplevelse och hantera personaliserade kampanjer i alla kanaler, så att ni kan se varje enskild kanal och yta som sin egen innehållsstruktur att leverera till. Det är emellertid en utmaning att behålla en egen innehållsmodell för varje kanal.

Istället bör ni överväga hur innehåll på olika ytor är relaterat till en organiseringsprincip som varumärken och produkthierarkier, kategorier av varor eller ytor, eller steg i kundresan. Om du t.ex. har en uppsättning ytor som stöder ett visst varumärke med bilar som du tillverkar, kanske du vill börja med en innehållsmodell för allmän information som är sann för hela bilen och sedan har mer - specifika element som innehåll som behövs när bilen startar vid serviceproblem. En sådan modell kommer att genomdriva arv av allmänt varumärkesinnehåll samtidigt som den möjliggör förändringar baserat på det specifika sammanhang som behövs. Det hjälper även till med framtida hantering av uppdateringar av det här innehållet eftersom ni kan tillämpa kontroll baserat på roller som den övergripande marknadsföraren eller produktchefen för hela varumärket jämfört med en författare som ansvarar för upplevelsen av att starta bilen.

När du har innehållsmodellen och en tydlig bild av de olika klienterna som innehållet måste visas för, måste du se till att de GraphQL/API:er som är kopplade till åtkomsten till olika innehållsmodeller publiceras till alla klienter som behöver det här innehållet. Det finns olika sätt att komma åt visst innehåll. Du kan begära ett visst statiskt innehåll som möjliggör cachelagring av innehållet och högre prestanda. Du kan också begära dynamiskt genererat innehåll som kräver mer bearbetning. Se till att kunderna använder de API:er som är mest effektiva för deras affärsbehov.

Förstå era miljöer understanding-environments

Inom AEM finns det tre typer av miljöer: utveckling, staging och produktion.

Utvecklingsmiljöerna (du kan ha flera) är en säker plats att experimentera med och testa idéer på. Under projektets inledande fas rekommenderar Adobe att utvecklingsmiljöerna används för att testa olika varianter av innehållsmodellerna och för att se vilka som ger de avsedda resultaten för ytorna.

Mellanlagringsmiljön för headless-projekt används för att validera nya AEM produktreleaser innan de börjar producera. Håll en uppdaterad lista över produktionsinnehållsmodellerna där och en delmängd av innehållet, så att du kan få JSON-filer renderade för att jämföra dem som fortfarande ger samma utdata, när du gör ändringar eller AEM gör ändringar

Det är i produktionen som innehållsförfattare skapar och hanterar sitt faktiska innehåll. Modellförändringar i produktionen måste genomföras med försiktighet och bakåtkompatibilitet i åtanke.

Under utvecklingsfasen rekommenderar vi att du arbetar med en utvecklings- och staging-miljö. När du går över till prestandatestning vill du gå över till produktionsmiljön.

Samarbete mellan utvecklare och innehållsförfattare cooperation

Utvecklarna behöver en AEM utvecklingsmiljö som är anpassad efter de populära innehållsmodellerna. Utvecklaren utvecklar klienten som konsumerar innehåll från AEM headless eftersom innehållsförfattarna fortfarande skapar innehållet. Därför är API-definitionerna mycket viktiga. Genom att använda AEM SDK kan utvecklaren skapa en testkrok så att klient- och enhetstester kan skapas för att säkerställa att klienten kan återge innehållet på rätt sätt.

Innehållsförfattare skapar innehåll baserat på de innehållsmodeller som har definierats i mellanlagringsmiljön. Med hjälp av utvecklingsverktyget för innehållsfragment kan författaren skapa ett innehållsfragment eller redigera ett befintligt innehållsfragment. Innan den publiceras kan författaren förhandsgranska hur den kommer att se ut i klienten genom att arbeta med utvecklaren för att överföra innehållsmodellen till utveckling eller konfigurera en utvecklingsmiljö enbart för att författarna ska kunna se hur den skulle se ut i klienten.

Inställningar setup

Innan du börjar använda headless i AEM måste du se till att alla nödvändiga funktioner är aktiverade. I det här avsnittet beskrivs vad som krävs. De faktiska stegen för att utföra dessa steg beskrivs senare i AEM Headless Developer Journey.

Du kan även se ytterligare resurser om du vill ha mer information om de enskilda ämnena.

Konfiguration configuration

Implementera din första AEM Headless-app

Detta är en översikt över vad som behövs för att implementera din första headless-app med AEM för att leverera ditt innehåll. Hur du utför dessa steg beskrivs i detalj i senare delar av den Headless Developer Journey.

Bästa praxis best-practices

Ett headless-projekt är inte bara framgångsrikt på grund av den teknik som används, utan också på grund av god planering och projektledning. Här följer några tips som både författare och utvecklare kan använda när du planerar ditt projekt.

Ordna ditt innehåll organizing-content

Skapa innehåll authoring

Skapa globalt innehåll localization

What's Next what-is-next

Nu när du är klar med den här delen av AEM Headless Developer Journey ska du:

Vi vill att du bygger vidare på denna grundläggande kunskap för att till fullo förstå styrkan och flexibiliteten hos AEM Headless så att du kan utnyttja den för dina egna projekt. För att göra detta har du alternativ.

Välj din egen Adventure choose-your-path

Oavsett vilken inlärningsstil du har vill Adobe att du ska lyckas när du börjar med AEM Headless-projekt.

Ytterligare resurser additional-resources

Vi rekommenderar att du går vidare till nästa del av den headless-utvecklingsresan genom att granska dokumentet Så här modellerar du ditt innehåll som AEM innehållsmodeller, men följande är ytterligare, valfria resurser som gör en djupdykning i vissa koncept som nämns i det här dokumentet, men de behöver inte fortsätta på den headless-resan.