AEM Headless as a Cloud Service 快速入門 getting-started

在 AEM Headless 開發人員歷程的這一部分中，了解需要滿足哪些條件才能使用 AEM Headless 開始您自己的專案。

目前進度 story-so-far

在 AEM Headless 歷程的上一個文件「了解 CMS Headless 開發」中，您已了解了 Headless CMS 的基本理論，現在您應該：

本文章以這些基本知識為基礎，以便您了解如何使用 AEM 實作 Headless 解決方案。

目標 objective

本文件可幫助您在自己的專案情境中了解 AEM Headless。閱讀本文件後，您應該：

AEM 基本概念 aem-basics

在 AEM 中定義 Headless 專案之前，了解一些基本的 AEM 概念非常重要。

製作執行個體 author

最簡單的情況是，AEM 由一個製作執行個體和一個發佈執行個體組成，它們協同工作以建立、管理和發佈您的內容。

內容從製作執行個體開始。這是內容作者建立內容的地方。製作環境為作者提供了各種工具來建立、組織和重複使用他們的內容。

發佈執行個體 publish

在製作執行個體中建立內容後，必須將其發佈以供其他服務取用。發佈執行個體包含所有已發佈的內容。

預覽服務 preview

在發佈到發佈執行個體之前，您還可以將內容片段發佈到​ 預覽服務，以進行測試和檢閱。這會從​ 內容片段 ​主控台完成。

複製 replication

複製是將內容從製作執行個體轉移到發佈執行個體的動作。當作者或具有適當權限的其他使用者發佈內容時，AEM 會自動完成此操作。

AEM 基本概念摘要 aem-basics-summary

在最簡單的層級上，在 AEM 中建立數位體驗需要以下步驟：

AEM Headless 提供強大的工具來管理 Headless 內容，從而建構此技術基礎，將在下一節中介紹。

AEM Headless 基本概念 aem-headless-basics

AEM 的 Headless 功能以幾個關鍵功能為基礎。這些將在歷程的後續部分詳細說明。現在重點只需知道它們的作用和名稱。

內容片段模型 content-fragment-models

內容片段模型定義您在 AEM 中建和管理之資料和內容的結構。它們做為您內容的支架。選擇建立內容時，您的作者會從您定義的內容片段模型中進行選擇，這會指引他們建立內容。

內容片段 content-fragments

內容片段允許您設計、建立、規劃和發佈每頁自主的內容。它們可讓您將內容準備就緒用於多個位置和多個管道。

內容片段包含結構化內容，能以 JSON 格式傳遞。

GraphQL 和 REST API apis

為了以 Headless 方式修改您的內容，AEM 提供了兩個強大的 API。

您將在 AEM Headless 歷程的後段會了解這些 API 以及如何使用它們。或者，參閱下面的「其他資源」區段以取得更多文件。

Headless 整合層級 integration-levels

AEM 支援 CMS 的全 Headless 模型和傳統的全堆疊或 Headful 模型。但是，AEM 不僅提供這兩種獨特的選擇，而且也支援結合了兩者優勢的混合模型，從而為您的 Headless 專案提供獨特的靈活性。

為了確保您了解 Headless 概念，此 AEM Headless 開發人員歷程重點放在純 Headless 模型，讓您在 AEM 中無需製作程式碼即可快速開始使用。

但是，一旦您了解 AEM Headless 功能，您就應明白混合模型帶來的額外可能性。下面列出了這些案例，以便您明白。在歷程結束時，您會更詳盡地了解這些概念，以防您的專案需要這種靈活性。

您有 Headless 內容的外部取用者，例如單次頁面應用程式 (SPA)。 already-have-a-spa

讓我們假設您的基本要求至少是將內容從 AEM 傳遞到現有的外部服務。

層級 1：內容片段整合 - 傳統的 Headless 模型 level-1

此整合層級是傳統的 Headless 模型，允許您的內容作者在 AEM 中建立內容，並使用 GraphQL 將以 Headless 方式傳遞到任意數量的外部服務，或者使用資產 API 從外部服務編輯它們。AEM 中不需要製作程式碼。

在此模型中，AEM 僅用於使用 AEM 內容片段建立和提供內容。內容的呈現和互動則委派給取用內容的外部應用程式，通常是單頁應用程式 (SPA)。

層級 2：將 SPA 嵌入 AEM - 混合模型 level-2

此整合層級是建置在層級 1 上，也允許將外部應用程式 (SPA) 嵌入到 AEM 中，以便內容作者可以在 AEM 內的外部應用程式情境中檢視內容。該應用程式也支援在 AEM 中對外部應用程式進行有限編輯。

此層級的優勢是允許內容作者以 Headful 方式在 AEM 中靈活地製作內容，他們的內容會在嵌入的外部 SPA 中依情境呈現，同時仍以 Headless 方式傳遞內容。

層級 3：在 AEM 中嵌入並完全啟用 SPA - 混合模型 level-3

此整合層級是建置在層級 2 上，使外部 SPA 中的大部分內容都可以在 AEM 中進行編輯。

您沒有 Headless 內容的外部取用者，例如單頁應用程式 (SPA)。 do-not-have-a-spa

如果您的目標是建立一個新的 SPA 以 Headless 方式取用來自 AEM 的內容，您可以使用內容片段等功能來管理您的 Headless 內容，也可以使用 AEM 的 SPA 編輯器框架來建置 SPA。

使用 SPA 編輯器，SPA 不僅可以取用來自 AEM 的內容，還可以由您的內容作者在 AEM 中進行完全編輯，從而為您提供在 AEM 中進行 Headless 傳遞和在情境中編輯的靈活性。

要求和先決條件 requirements-prerequisites

您必須先滿足數個要求才能開始 Headless AEM 專案。

知識 knowledge

工具 tools

定義您的專案 defining-your-project

對於任何成功的專案，重要的是不僅要明確定義專案的要求，還要明確定義角色和責任。

範圍 scope

明確定義專案的範圍很重要。範圍會告知接受標準，並讓您設立完成的定義。

您必須問的第一個問題是「我想透過 AEM Headless 實現什麼目標？」一般來說，答案應該是您擁有或將來將擁有您使用自己的開發工具而非 AEM 建置的體驗應用程式。此體驗應用程式可以是行動應用程式、網站或任何其他面向取用內容之使用者的體驗應用程式。使用 AEM Headless 的目標是使用最先進的 API 為您的體驗應用程式提供在 AEM 中建立、儲存和管理的內容，這些 API 會直接從您的體驗應用程式呼叫 AEM Headless 以擷取內容或甚至是全 CRUD 內容。如果這不是您想要的，您可能想要返回 AEM 文件尋找符合您目標的內容。

角色和責任 roles-responsibilities

任一專案的角色皆不相同，但在 AEM Headless 開發方面需要考慮的重要角色是：

管理員 administrator

管理員負責系統的基本設定和配置。例如，管理員在 Adobe 使用者管理系統 (稱為 Identity Management System (IMS)) 中設定您的組織。Adobe 在 IMS 中建立您的組織後，管理員是組織中第一個收到來自 Adobe 的電子郵件邀請的使用者。管理員可以登入 IMS 並新增其他角色的使用者。

管理員設定好使用者後，他們將被授予存取所有 AEM 資源的權限，以完成他們的份內工作，使用 AEM Headless 傳遞體驗應用程式。

管理員應該是設定 AEM 並準備好執行階段，以使內容作者能夠建立和更新內容，開發人員使用 API 擷取或修改內容以供體驗應用程式取用。

內容作者 content-author

內容作者建立和管理 AEM Headless 傳遞的內容。內容作者使用內容片段編輯器和不同主控台等 AEM 功能來管理他們的內容。

內容作者應謹記以下最佳做法。

翻譯計畫 translation

在專案一開始就計畫翻譯。將「翻譯專家」視為一個獨立的角色，其職責是定義哪些內容應該翻譯，哪些內容不應該翻譯，以及哪些翻譯內容可以由區域或本機內容作者修改。

根據您需要的內容翻譯擬訂計畫。

清楚您的內容更新工作流程。系統必須支援的核准流程是什麼？是否可以使用 AEM 工作流程來自動化此流程？

可以使用您的「內容階層」讓翻譯變輕鬆。

請參閱其他資源章節，了解有關 AEM 工作流程和翻譯工具的其他文件，包括指向 AEM Headless 翻譯歷程的連結。

利用內容階層 content-hierarchy

資料夾階層可以解決與內容管理有關的兩個主要問題：

AEM 允許靈活的內容結構，階層可以任意擴大。但是，重要的是要認識到，資料夾結構的任何變更都可能對依賴於內容路徑的現有查詢造成未預期的後果。因此，事先明確設定的定義完善的階層可能對您的內容作者有所幫助。

資料夾也可以限制為只允許某些類型的內容 (根據內容片段模型)。建議一律明確指定階層中的所有資料夾允許哪些模型。為特定資料夾指定允許的內容：

透過建立適當的內容結構，可以更輕鬆地跨管道協調 Headless 內容的製作，以便能最大限度地重複使用內容。利用跨多個管道的內容大幅提升內容生產效率和變更管理。

建立良好的命名慣例 naming-conventions

內容片段名稱必須對內容作者具有描述性。AEM 透明地將在存放庫層級別使用的 ID 名稱逸出和/或截斷。因此，內容作者提供的邏輯名稱應一律具可讀性並代表內容。

如需有關 AEM 頁面命名慣例的其他文件，請參閱其他資源章節。

不要過度擴展內容巢狀 content-nesting

內容片段在 AEM 中用於建立 Headless 內容。對於內容片段的內容巢狀，AEM 支援最多十層。但是請務必記住，AEM 必須迭代解析父內容片段中定義的每個參考，然後檢查所有同層級中是否有任何子參考。這些操作可以迅速累加並成為效能問題。

作為一般經驗法則，內容片段參考巢狀不應超過五層。

內容架構師 content-architect

內容架構師分析必須 Headless 傳遞之資料的要求並定義該資料的結構。這些結構在 AEM 中稱為內容片段模型。內容片段模型用作內容作者建立之內容片段的基礎。

定義內容片段模型時，一種有用的方法是建立對應到取用內容之應用程式 UX 元件的模型。

因為內容作者在建立新內容時會持續與模型互動，因此將模型與 UX 對齊有助於他們將生成的數位體驗視覺化。更進一步，您可以將圖示指派給表示 UX 元素的內容片段模型，以便作者可以根據視覺提示直覺地選擇正確的模型。

開發人員 developer

開發人員負責將在 AEM 中以 Headless 方式建立的內容連接到該內容的取用者，通常是單頁應用程式 (SPA)、漸進式網頁應用程式 (PWA)、網路商店或 AEM 外部其他服務。

GraphQL 可作為 AEM 和 Headless 內容取用者之間的「黏著劑」。GraphQL 是向 AEM 查詢必要內容的語言。

開發人員在計畫查詢時應謹記一些基本建議：

對於使用 AEM 的典型 Headless 實作， 開發人員不需要 AEM 的製作程式碼知識。

效能要求 performance-requirements

任何專案要取得成功，在建立任何內容之前都必須考慮效能。

您必須了解您的使用者/訪客的期望和相關設計。設定服務層級目標 (SLO)，並加以測量以了解您是否滿足使用者的期望。

流量模式 traffic-patterns

若要了解流量和流量模式，首先要收集過去資料，然後預測未來幾年的預期成長。需要考慮的一些最重要的變數：

更新頻率 update-frequency

通常不同的體驗部分具有不同的內容更新頻率。了解這一點很重要，因為才能微調 CDN 和快取設定。這也是給內容架構師的重要輸入，因為他們設計模型來表示您的內容。考慮：

下一步 what-is-next

您已完成此部分的 AEM Headless 開發人員歷程，您應該：

您應該繼續您的 AEM Headless 歷程，接著檢閱「首次使用 AEM Headless 的方法」，並從中學習如何設定必要的工具，以及如何開始思考在 AEM 中建立資料模型。

其他資源 additional-resources

雖然建議您查看文件踏上首次使用 AEM Headless 之路，來繼續 Headless 開發歷程，但以下是一些額外的內容和選用資源，對此文件提到的一些概念有更深入的探討，但它們不是繼續 Headless 開發歷程的必要條件。