如何選擇無頭 CMS
已發表: 2022-03-10這篇文章得到了我們親愛的 Storyblok 朋友的大力支持，Storyblok 是一個友好的無頭 CMS，具有可視化編輯器、嵌套組件以及用於網站和應用程序的可自定義內容塊。 謝謝！
網頁（例如您現在正在閱讀的網頁）包含文本、圖像、視頻和其他資產，可以為您帶來信息。 該數據將由內容編輯器在 Web 內容管理系統 (WCMS) 中進行整理和創作。 WCMS 經歷了從傳統 CMS 到解耦 CMS 再到無頭 CMS 的演變。
遷移到無頭 CMS 不是一個容易的決定，選擇過程不應掉以輕心。 在本文中，我將重點介紹每個無頭 CMS 應提供的一些核心功能。 我們將探索這些功能、相關挑戰並幫助您選擇無頭 CMS 以滿足您組織的獨特需求。
作為 Luminary 的技術總監，我一直在幫助我們的客戶選擇最適合他們需求的 CMS、DXP（數字體驗平台）或無頭 CMS。 憑藉 Luminary 在數字領域 21 年的經驗、我在 CMS 領域 17 年的經驗以及我們自 2016 年以來對 Headless 的關注，以下是我的兩分錢，告訴你應該注意什麼。
選擇無頭 CMS 時要考慮的事項
- 概念
- 微服務架構
- 全渠道
- 對於內容作者
- 編輯經歷
- 管理圖像
- 創作角色
- 工作流程
- 預覽內容
- 本地化內容
- 對於開發人員
- RESTful 和 GraphQL API
- 原生 SDK
- 環境
- CDN
- 使用限制
- 其他因素
- 數據中心位置
- 技術和銷售支持
- 企業功能
- 基礎設施集成
- 知名SaaS供應商
- 將無頭 CMS 集成為微服務
- 最佳品種服務
- 您要定位的頻道
- 良好的內容建模實踐
- 創作經歷
- 內容項的結構
- 易於搜索內容
- 過度使用所見即所得編輯器
- 重用內容
- 組織圖像
- 通過 CDN 裁剪和交付圖像
- 外部最佳視頻服務
- 不同的角色
- 後台用戶數
- 強大的工作流程
- 網絡掛鉤
- 預覽供應商提供的 API
- 在您的端單獨的登台和生產環境
- 國際化和本地化支持
- 創建自己的處理語言環境的藍圖
- 成熟的 REST API
- GraphQL 支持
- 預覽和保護 API
- 用於 CRUD 操作的內容管理 API
- 免費試用
- 支持的 SDK，供您選擇技術、語言和平台。
- 無頭 CMS 中的環境
- 在環境之間移植內容的能力
- 通過 CDN 緩存圖像和內容
- 自定義域功能
- 某些功能的限制
- 運營開支
- 存儲數據的法律和法規要求
- 本地銷售和技術支持
- 離不開的企業功能
- 與供應商和產品的社區參與
- 支持您選擇的基礎架構
- 去無頭：用例和它的好處
- 不要失去理智：評估無頭
單體與微服務
我們已經在 Smashing Magazine 上詳細探討了無頭 CMS 背後的概念，但讓我們快速回顧一下。 對於傳統的 CMS，CMS 和由此產生的前端網站是建立在一個整體架構上的。 傳統 CMS 以多種方式嘗試並成功地滿足了開發人員、內容作者和營銷人員的需求。 例如，如果 CMS 是基於 Microsoft 的 .NET Framework 構建的，那麼前端網站也將基於相同的技術構建。 所有功能和集成也將具有緊密的依賴關係，這反過來會導致龐大、繁瑣的單體代碼庫。
解耦的 CMS在一定程度上消除了這種相互依賴。 這是通過將前端網站與 CMS 後台和內容存儲庫分開來實現的。
單體架構在無頭 CMS 中處於次要地位。 CMS 和所有其他集成都是微服務。 CMS 本身是基於軟件即服務(SaaS) 模型提供的，我喜歡將其稱為內容即服務(CaaS)。 使用這種微服務架構，您從傳統 CMS 中獲得的一切都不會憑空出現。 您可能有不同的服務和供應商來為您提供滿足您的每個要求的最佳品種。
轉向微服務思維需要一點耐心。 我們有來自傳統 CMS 背景的營銷人員，他們拒絕在使用無頭 CMS 時深入研究多個系統和服務的想法。 在選擇和實施他們的無頭 CMS 平台期間，我們設法帶他們一起踏上了旅程。 現在，他們是無頭 CMS 平台的擁護者，因為它允許他們集成新系統和服務，而不是綁定到傳統 CMS 提供的系統和服務。
密切注意，提防，小心：
全渠道為核心
在集成無頭 CMS 時，儘管微服務思維方式可以幫助您，但無頭的真正力量是在其全渠道性質中實現的。 全渠道體驗以您的客戶為中心，並通過統一銷售和營銷在您的品牌中創建單一客戶體驗。 借助無頭 CMS，可以將內容提供給不同的渠道，例如網絡、移動、社交、無 UI 智能設備、物聯網設備，甚至是實體店面等非數字接觸點。
使用無頭 CMS，您需要從頭開始為每個內容模型定義模式。 為您創建和發布的內容項定義這種健全的邏輯分類結構的過程稱為內容建模。 如果您的第一個渠道將成為您的網站，請確保您的內容建模將全渠道考慮在內，以減輕未來的痛苦。 如果您只是在尋找替代 CMS 來為您的網站提供動力，請再仔細研究一下傳統或解耦 CMS 空間，看看是否有更適合您要求的東西。
在對內容模式進行建模時，請考慮未來。 甚至不到十年前，我還在一家大型航空公司工作，我記得曾嘗試為移動設備建模內容（是的！移動網站有一個單獨的子域）。 這是極其困難的，因為內容模式僅適用於桌面網站。 但即使在今天，我們也需要對內容建模保持警惕。
密切注意，提防，小心：
創造偉大的內容
無論是傳統的 CMS 還是無頭 CMS，主要需求是管理內容。 內容作者應該喜歡在後台工作。 如果您看到作者轉向其他創作工具（例如 Google Docs）以獲得評論或建議功能，則可能是您缺少哪些功能的危險信號。
與內容作者合作時，Microsoft Word 文檔、電子表格、Google 文檔總是會抬起頭來。 讓內容作者在 CMS 上工作的最簡單方法是為他們提供所需的功能，然後他們會自動逐步淘汰這些功能，而不是試圖提前驅逐他們。 當我們將 Luminary 自己的網站推送到無頭 CMS 上時，每個團隊成員（其中 50 人）都有足夠的訪問權限來添加和編輯他們自己的網站個人資料。 在沒有 50 個 Google Docs 到處亂飛的情況下，它奏效了。
編輯經驗
使用無頭 CMS 的決定可能是 IT 決定。 但組織內營銷人員和內容作者的支持對於其採用和成功至關重要。 允許內容作者輕鬆輸入內容、查找現有內容和重用內容的無頭 CMS 應該是開箱即用的東西。
為了便於創作內容，必須擁有易於使用的編輯器，例如所見即所得編輯器、文本編輯器、下拉菜單和自定義編輯器。 一個乾淨和簡約的界面，允許內容作者專注於手頭的任務，將受到讚賞。 允許在同一界面中同時編輯、評論和創建子內容項的編輯界面將提高內容作者的生產力。
使用 WYSIWYG 編輯器或嚴重依賴任何生成 HTML 的編輯界面時請注意。 由於無頭 CMS 旨在迎合多個渠道，因此依賴所見即所得的編輯器將消除可重複使用的內容的原子性質。 確保自定義編輯器允許在粒度級別訪問數據字段。 我們已經看到這阻礙了跨不同渠道（例如移動和桌面）的內容重用。
對於無頭 CMS，以樹狀結構組織內容項不是常態。 但它是一座橋樑，讓內容作者可以輕鬆地從傳統 CMS 過渡到無頭 CMS。 如果內容項沒有以樹狀結構可視化，那麼具有分面和標記功能的強大搜索引擎對於您的內容編輯器來說至關重要。 這使作者可以輕鬆地查找和重用現有內容。
在重用內容時，要考慮的另一個方面是內容項是否可以輕鬆地嵌套在其他內容項中。 這允許最大程度地重用現有內容。 但要注意對內容的循環引用，這可能會導致頭痛和性能問題。 一個示例是律師的內容項，該內容項鍊接到專業知識的內容項。 然後，如果專業知識內容項再次鏈接到多個律師內容項，則這可以形成循環引用。 尋找具有智能功能的無頭 CMS，以限制 API 和可視化的深度，以顯示鏈接的內容項，以避免這種陷阱。
密切注意，提防，小心：
圖片的價值：如何處理媒體
一張圖片勝過千言萬語。 但是圖像資產難以運輸、難以組織且難以搜索。 在典型的 CMS 中，隨著時間的推移，您會看到重複和名稱不佳的圖像資產。 重要的是，為內容編輯器提供工具來組織、分類、標記、重用和搜索無頭 CMS 中的圖像。 對我來說，這意味著在文件夾或容器中組織資產。 但是最好了解您的團隊在管理靜態資產方面的要求。
上傳單個圖像，為其設置焦點，然後針對不同設備和屏幕尺寸操縱其尺寸和質量的能力，為內容編輯器甚至那些在幕後工作的設計師/圖形藝術家節省了大量時間。 通過內容交付網絡 (CDN) 以 WebP 等格式交付靜態資產對於為用戶提供快速網站也至關重要。
大多數無頭 CMS 都帶有這些開箱即用的功能。 如果沒有，您需要決定可以不使用哪些功能。 該規則有一個警告。 對於原始圖像的廣泛編輯，您應該堅持使用最適合該工作的工具，例如 Photoshop。
除圖像外，下一個最重的資產是視頻。 再一次，以微服務的心態，視頻流應該留給服務提供商，如 YouTube、Vimeo 和其他在線流媒體服務。 如果您的無頭 CMS 可以為您提供一個不錯的編輯界面來搜索或從這些提供商之一中選擇視頻，那將是一個額外的好處。
密切注意，提防，小心：
創作角色
誰可以輸入內容，誰可以批准或發佈內容到實時站點，以及其他細粒度的權限也需要通過無頭 CMS 進行管理。 一個兩人團隊可以在沒有不同創作角色的情況下生存，但隨著組織和內容團隊的發展，創作角色是必須的。
我曾與 40 多名編輯的內容團隊合作，需要根據您選擇的無頭 CMS 仔細評估此要求。 否則，混亂將佔上風。 在與我共事的 40 人團隊中，我們有文案撰寫人、翻譯人員、QA 人員和法律審批人員，他們擁有不同的權限來訪問某些內容、語言變體、工作流程審批和發布權。
不同角色和後台用戶的數量通常是無頭 CMS 定價的方式。 在比較供應商之間的價格點時，請考慮當前數字和內容團隊的未來增長。
密切注意，提防，小心：
工作流程
並非每個內容項都需要通過工作流進行管理。 但是，當需要工作流、審計跟踪和批准時，需要在無頭 CMS 中管理流程。 在無頭 CMS 上從頭開始構建強大的工作流程，讓您高枕無憂，並有機會根據您的業務流程處理每個內容項。 通過 webhook 或 API 集成第三方系統的能力是您應該注意的一個好處。
密切注意，提防，小心：
內容預覽
內容編輯器已創作內容、添加圖像並通過工作流發送以供批准。 但是，在將內容提供給公眾之前，他們在哪裡預覽內容呢？ 這就是用於檢索未發佈內容的預覽 API 和設置預覽環境的能力發揮作用的地方。
有了無頭 CMS，擺脫了單一渠道的思維方式，您的內容編輯不應該期望在 CMS 後台看到全頁預覽。 每個頻道都應該有自己的登台或預覽環境來查看尚未發布的草稿內容。 這可能是您網站的臨時站點或本地安裝的移動應用程序版本。 您為所選的無頭 CMS 選擇的定價計劃中必須提供預覽功能。
密切注意，提防，小心：
語言環境
如果您的內容需要提供給不同的語言環境，則需要在項目早期確定該要求。 改造是可能的，但不是一個有趣的活動。 應該考慮並記錄您如何管理跨文化和語言的內容和資產。 我建議創建一個藍圖來確定哪些語言和資產從另一個繼承或默認。 然後確保您選擇的無頭 CMS 支持該藍圖或探索以不同方式實現相同結果的途徑。
密切注意，提防，小心：
創造偉大的內容總是很重要的。 因此，內容作者應該在他們的日常活動中獲得最佳體驗，以使您成功過渡到無頭 CMS。
“
開發時間很寶貴
對於無頭 CMS，開發人員的參與是必須的。 這可能是後端開發人員或前端開發人員使用無頭 API 在網站上顯示內容。 但是一旦完成初始開發，內容作者應該能夠以最少的干預工作。 這就是使用 CMS 的全部意義所在。 它也適用於無頭 CMS。
在比較功能時盡可能多地考慮內容作者，開發者功能也應該被探索。 在本節中，我們將介紹可以為開發人員節省時間的功能。
API/GraphQL 支持
允許內容項的選擇、分頁和投影的成熟 API 對於開發人員使用無頭 CMS 至關重要。 開箱即用的 GraphQL 支持是另一個決定性因素，因為它將允許開發人員在非常精細的級別上定義他們需要的結果。 全面的文檔和代碼示例也是必須的。
在提交無頭 CMS 之前，請確保您的開發人員對內容檢索 API 感到滿意。 不要忘記預覽 API、安全 API 以及通過代碼輕鬆使用它們。 您想自動化內容創建嗎？ 然後應該考慮內容管理 API 。
內容管理 API 一直是我們的福音，我們將 2,000 多篇博客文章從 WordPress 站點自動導入到無頭 CMS。 所有博客文章和相關圖像都是以內容作者的最少工作量導入的。 一些無頭 CMS 提供了 Google 表格插件和其他漂亮的工具，只需單擊一下按鈕即可完成此操作。
由於許多無頭 CMS 提供免費試用，因此最好讓它們進行試駕，以了解它們對您選擇的內容創建和檢索的適用性和一致性。
密切注意，提防，小心：
原生 SDK
適用於各種技術、語言和平台的軟件開發工具包 (SDK) 可直接從 Headless 供應商、開源計劃或第三方處獲得。 確保這些 SDK 支持您將在其上構建網站或消費者應用程序的技術、語言和平台。 儘管 RESTful 和 GraphQL API 允許您查詢內容，但擁有原生 SDK 可以顯著減少開發時間。
在 Luminary，使用用於無頭 CMS 的原生 SDK 使我們能夠採用 Microsoft .NET Core 和 .NET 5 等最新技術。此外，在現有 SDK 的基礎上構建使我們能夠遵循供應商推薦的最佳實踐，同時節省成本時間。
密切注意，提防，小心：
環境
夫妻店的網站或應用程序可能能夠通過單一的生產環境來策劃和預覽內容。 但隨著組織、團隊和功能的發展，需要多種環境來管理和預覽內容。 您的無頭 CMS 不僅需要提供環境，而且您的消費應用程序也應該設置環境。 需要考慮跨環境刷新內容的方法。
密切注意，提防，小心：
圖像、文件和 CDN
在討論內容作者的功能時，我們談到了管理圖像。 從開發人員的角度來看，不僅靜態資產需要緩存在 CDN 上。 許多無頭 CMS 緩存通過 RESTful 或 GraphQL API 檢索的內容。 這加快了檢索過程並為您的應用程序帶來了性能改進。
雖然 CDN 緩存非常有用，但有時緩存損壞或較舊的緩存項目可能會產生問題。 清除 CDN 緩存或提取具有特定 HTTP 標頭的最新內容的能力應該是無頭 CMS API 功能的一部分。
對 CDN 使用自定義域來交付內容或靜態資產的能力可能是您需要考慮的一項要求。
密切注意，提防，小心：
跨計劃的使用限制
要考慮的另一個因素是為您訂閱的每個計劃設置的使用限制，這些計劃是針對您選擇的無頭 CMS 的。 需要考慮內容項的數量、帶寬消耗、後台用戶的數量、API 調用的數量和速率限制。 在規劃使用限制時，請考慮當前使用和未來使用。 請記住，許多無頭 CMS 在訂閱的基礎上運行，它們確實允許您幾乎立即升級到具有更高限制的計劃。
但是，值得了解有多少用戶將使用該平台，以及該解決方案是否需要大規模擴展。 我們目睹了一個客戶收到一筆非常大的賬單，因為他們在不知不覺中添加了大量用戶，超出了分配的配額。 管理員最好了解他們的 Headless 計劃提供的內容並密切關注使用情況。
請考慮使用客戶端緩存、靜態頁面生成器和智能 API 或 GraphQL 調用將當前限制保持在使用限制以下，以減少您的運營支出。
密切注意，提防，小心：
開發人員的時間很昂貴。 儘管無頭 CMS 被吹捧為對開發人員友好的 CMS，但每個供應商都有各自支持的不同功能。 強烈建議您根據開發人員的需求了解和比較這些內容。
“
其他因素
還有一些其他因素可能不會影響內容作者或開發人員。 這可以從市場營銷到財務，再到您所在行業和業務的法律和監管要求。
數據中心位置
我們經常被問到的一個問題是，數據存儲在哪裡？ 是的，在雲端。 但是由於某些企業的法律和監管要求，哪個地理數據中心是一個重要的問題。 允許您將數據存儲在您選擇的數據中心的無頭 CMS 可能是決定您選擇哪種 CMS 的關鍵因素。
技術和銷售支持
在您的時區獲得技術和銷售支持的能力是選擇無頭 CMS 時的另一個決定因素。 由於沒有本地銷售人員，許多項目都傾向於那些在相關地區有人員的供應商。
由於能夠將數據存儲在澳大利亞境內的 Azure 數據中心，我們有一個大型 NFP（非盈利）組織選擇了無頭 CMS 供應商。 擁有實地銷售支持和全天候技術支持為該無頭 CMS 供應商贏得了銷售。
密切注意，提防，小心：
要考慮的企業功能
一些大型組織可能需要與公司的身份驗證系統或審計日誌相關聯的單點登錄 (SSO)，以便輕鬆查詢。 在 SaaS 產品被認為合適之前，可能需要集成現有系統和某些 ISO 認證。 在選擇無頭 CMS 時，列出這些企業功能以及企業級組織獨有的其他功能是一個很好的起點。
社區在行動
另一個通常被忽視的領域是圍繞給定無頭 CMS 的社區。 那裡有對產品充滿熱情的人嗎？ 我不是在談論供應商的營銷窺視。 使用該工具的人是否有足夠的開源資源共享？ 這可能不是決定性因素，但當您在項目的實施或支持階段處於困境時會有所幫助。
基礎設施集成
使用無頭 CMS，您不受技術、語言或平台的束縛。 構建無頭 CMS 的技術或平台不會影響客戶端應用程序。 您可以使用您選擇的技術，從 .NET 到 Node.js，您的操作系統可以是 Windows、Linux 或 macOS，您的語言可以是從 Python 到 C# 的任何語言。
同樣，在採購基礎設施方面，您可以選擇在 Netlify、Azure、GCP 或 AWS 上託管您的網站。 您的網站架構及其基礎架構決策現在完全基於您的要求。 還有與 Gatsby Cloud 等服務的原生一流集成，帶來更多組合，讓您的生活更輕鬆。 對於某些人來說，這可能是一個重大決定，應該通過與 Headless 領域的一些專家從業者交談來做出。
密切注意，提防，小心：
我們在 Luminary 的經驗
在 Luminary，我們有幸與無頭 CMS 合作，例如 Acoustic、Contentful、Kentico Kontent 和 Umbraco Heartcore。 自這些 CMS 平台的 beta 版本以來，我們一直在與其中一些 CMS 合作。 公共路線圖、出色的技術支持以及解決我們的功能請求是我們在這些平台上的一些亮點。
我們在使用僅前端實現、緩存大型列表頁面、處理大型服務器端緩存以及將其他微服務與無頭 CMS 集成的無頭網站處理 SEO 方面擁有豐富的經驗。 其中每一個都有其獨特的挑戰，您應該注意這些挑戰。 此外，傳統 CMS 上的簡單任務（例如表單提交和站點搜索）以及更高級的功能（例如用戶身份驗證和第三方服務授權）都需要經過深思熟慮。
如果您選擇了正確的無頭 CMS 和正確的實施合作夥伴，那麼您最終應該得到一個無頭 CMS，它會讓營銷人員、內容編輯和開發人員開心。