瞭解CMS無頭開發

無AEM頭開發者之旅, 瞭解無頭技術,以及你為什麼要使用它。

目標

本文檔可幫助您瞭解無頭內容交付以及使用它的原因。 閱讀完後,您應:

  • 瞭解無頭內容交付的基本概念和術語
  • 瞭解為什麼和何時需要無頭
  • 在高級別瞭解如何使用無頭概念及其相互關係

完整堆棧內容交付

自從易於使用的大規模內容管理系統(CMS)興起以來,各公司一直利用它們作為管理消息傳遞、品牌推廣和通信的中心位置。 將CMS用作管理經驗的中心點,通過消除在不同系統中重複任務的需要而提高了效率。

經典的全堆棧CMS

在全堆棧CMS中,用於處理內容的所有功能都在CMS中。 系統的功能構成了CMS堆棧的不同元件。 全棧解決方案具有許多優點。

  • 你有一個系統要維護。
  • 內容集中管理。
  • 系統的所有服務都是整合的。
  • 內容創作是無縫的。

因此,如果您想添加新渠道或支援新類型的體驗,則可以將一個(或多個)新元件插入堆棧,並且您只有一個位置進行更改。

向堆棧添加新通道

堆棧中依賴項的複雜性很快變得明顯,因為您可能需要調整堆棧中的其他項以適應更改。

全堆棧交付限制

全堆棧方法天生就會形成一個孤島,所有體驗都在一個系統中著陸。 對思洛儲存器的一個元件進行更改或添加需要對其他元件進行更改,這會使更改耗時且成本高昂。

在傳統設定中,演示系統通常與CMS緊密相連,這一點尤為明顯。 任何新頻道通常意味著對演示系統的更新,這可能會影響所有其他頻道。

隨著通道添加到堆棧中,複雜性增加

此自然思洛儲存器的局限性隨著您花費更多精力協調堆棧所有元件的更改而變得明顯。

無論平台或觸點是什麼,用戶都希望參與,這要求您在提供體驗時保持靈活性。 這種多通道方法是數字型驗的標準,而在某些情況下,全堆棧方法可能被證明是不靈活的。

《無頭》

任何系統的頭通常是該系統的輸出呈現器,通常以GUI或其他圖形輸出的形式。

例如,無頭伺服器可能位於某個伺服器機房的機架中,且未連接顯示器。 要訪問它,您必須遠程連接到它。 在這種情況下,顯示器是負責呈現伺服器輸出的頭。 您作為服務的使用者,在遠程連接到服務時提供自己的頭(顯示器)。

當我們討論無頭CMS時, CMS會管理內容,並繼續將其提供給消費者。 但是,只通過 內容 無頭CMS以標準化方式忽略最終輸出渲染, 演示 內容到消費服務。

無頭CMS

消費服務,無論是AR體驗、網店、移動體驗、漸進式Web應用(PWA)等,都會從無頭CMS中獲取內容並提供自己的呈現。 他們會為您的內容提供自己的頭腦。

省去頭部,通過消除複雜性來簡化CMS。 這樣做還會將內容呈現的責任轉移到實際需要內容並且通常更適合此類呈現的服務上。

解耦

通過公開一組強大而靈活的應用程式寫程式介面(API),您的所有體驗都可以利用這些介面進行無頭傳送。 API是服務之間的一種通用語言,通過標準化的內容交付在內容級別將它們綁定在一起,但允許它們靈活地實施自己的解決方案。

「無頭」是將內容與其演示文稿分離的示例。 或者從更一般的意義上講,將前端與服務堆棧的後端分離。 在無頭設定中,呈現系統(頭)與內容管理(尾)分離。 兩個只通過API調用進行交互。

這種解耦意味著每個消費服務(前端)都可以基於通過API傳遞的相同內容構建其體驗,從而確保內容重用和一致性。 然後,消費服務可以實施其自己的演示系統,使內容管理堆棧(後端)能夠輕鬆地水準擴展。

技術基礎

無頭方法使您能夠構建技術堆棧,輕鬆、快速地適應未來數字型驗需求。

過去,CMS的API通常基於REST。 表示狀態轉移(REST)以無狀態方式將資源作為文本提供。 這允許使用預定義的操作集來讀取和修改資源。 通過確保內容的無狀態表示, REST允許在Web上的服務之間實現強大的互操作性。

仍然需要強大的REST API。 但REST請求可能大而冗餘。 如果您有多個客戶在為您的所有渠道撥打REST電話,則此詳細程度會影響效能。

無頭內容傳遞通常使用GraphQL API。 GraphQL允許類似的無狀態傳輸,但允許更有針對性的查詢,減少所需查詢的總數,並提高效能。 常見的情況是,解決方案使用REST和GraphQL的混合,實質上是為手頭的作業選擇最佳工具。

無論您選擇的API是什麼,通過定義基於通用API的無頭系統,您都可以利用最新的瀏覽器和其他Web技術,如漸進式Web應用(PWA)。 API建立一個易於擴展和適應性的標準介面。

通常,內容在客戶端上呈現。 這通常意味著有人在移動設備上調用您的內容,您的CMS將傳遞內容,然後移動設備(客戶端)負責呈現您所提供的內容。 如果設備已舊或速度較慢,則您的數字型驗同樣很慢。

將內容與演示分離意味著可以對這種客戶端效能關注進行更多的控制。 伺服器端呈現(SSR)將內容從客戶端瀏覽器呈現到伺服器的責任轉移給伺服器。 這樣,作為內容提供者,您就能夠向您的觀眾提供一定級別的保證效能(如果需要)。

組織挑戰

無頭遊戲為提供數字型驗帶來了靈活性。 但這種靈活性也可能帶來其自身的挑戰。

有許多不同的頻道意味著他們各自擁有各自的演示系統。 儘管他們都通過相同的API使用相同的內容,但由於不同的演示,體驗可能會有所不同。 必須關注並注意確保客戶體驗的一致性。

通過實施仔細的設計系統、共用模式庫以及利用可重用的設計元件以及已建立的開放客戶端框架,可以確保一致的體驗,但這必須得到規劃。

未來是無頭,未來是現在

數字型驗將繼續決定品牌如何與客戶互動。 無頭設計的令人興奮之處在於它為我們提供了靈活性,以響應不斷變化的客戶期望。

預測未來是不可能的,但無頭使你能夠靈活地對未來帶來的任何變化做出反應。

AEM無頭

在您繼續完成此開發人員旅程時,您將瞭解AEM如何支援其全堆棧交付功能的同時進行無頭交付。

作為數字型驗管理行業的領頭羊,Adobe認識到,解決體驗創造者所面臨的現實挑戰的理想解決方案很少是二元選擇。 這就是AEM為什麼不僅支援兩種模型,而且獨特地允許兩種模型的無縫混合組合,將無頭和完整堆棧的優勢結合起來,幫助您最好地服務內容的消費者,無論他們在何處。

這一旅程的重點是內容交付的無頭模式。 但是,一旦您掌握了這一基本知識,您就可以進一步探討如何利用這兩種模型的威力。

下一步是什麼

謝謝你開始無頭AEM之旅! 現在您閱讀了此文檔,您應:

  • 瞭解無頭內容交付的基本概念和術語。
  • 瞭解為什麼和何時需要無頭。
  • 在高級別瞭解如何使用無頭概念,以及它們之間的關聯。

在此知識的基礎上再接再厲,AEM繼續您無頭的旅程,繼續查看文檔 無頭as a Cloud Service入AEM門 您將在何處學習如何設定必要的工具以及如何開始考慮如何以無AEM用的方式交付內容及其先決條件。

其他資源

雖然建議您通過查看文檔來進入無頭開發旅程的下一部分 開始使用無AEM頭as a Cloud Service, 下面是一些附加的可選資源,這些資源對本文檔中提到的一些概念進行了更深入的探討,但不需要繼續進行無頭之旅。

本頁內容