去無頭：用例和它的好處

已發表: 2022-03-10

快速總結↬無頭選項流行的驅動因素之一是對用戶體驗質量的期望不斷提高。我們擁有豐富的工具來幫助開發人員快速構建事物，從而快速預期結果。無頭模式可以讓您的團隊完全控制用戶體驗，而不是與無法完全滿足您需求的大型工具搏鬥。

回顧 Web 開發的這些年，我使用了幾十種不同的 CMS 工具，既有現成的，也有自製的。我一直在部署和構建大量WordPress 站點和插件，以及 .NET 中提供全方位服務的 CMS 站點的擴展。但對我來說，當我第一次聽說 headless 時，一切都變了，而現在，多年後，我在headless 生態系統中感覺再舒服不過了。

這種熱情並非憑空而來。雖然理解所有無頭選項似乎令人生畏，但我一直在針對不同環境中的不同無頭選項改進自己的策略，並使自己非常熟悉無頭空間中的常見嫌疑人。轉向無頭模式幫助我避免了因大型一體化系統的限製而遇到的障礙。

將功能區分開來，以便您今天可以實現複雜的目標並準備您的應用程序以在未來輕鬆發展，這讓我高枕無憂。很高興為私營公司和加利福尼亞州政府基於無頭解決方案構建的 Web 服務的成功部署和迭代做出貢獻。

在這篇文章中，我很樂意分享我這些年來學到的一些有用的指針和指導方針，希望它們能幫助你理解無頭世界，並為你的項目找到合適的候選人。但在我們深入研究之前，我們需要及時回顧一下，以了解無頭帶來了什麼。

無頭之前

就在幾年前，我們的工作流程似乎專注於一系列工具、堆棧和技術。對於 CMS，我們主要使用多合一工具。它們包括內容創作和內容查看功能。

文本模式 CMS — 你們中的一些人可能還記得很好的 ol' Textpattern、PHP-Nuke、Mambo 和其他 —— 一些在 2000 年代初發布的第一個 CMS。

這些工具的用戶被後端附帶的前端所困。你定制事物的能力是有限的。您可以安裝插件，但它們都必須為您的工具構建。您可以編寫自定義代碼——但只能使用您的工具所基於的語言並在其約束範圍內。

在過去的幾年裡，這一切都發生了變化，無頭 CMS在整個行業中獲得了關注。

專業工具的複興

今天，我們擁有大量專門用於創作或內容呈現視圖的工具。 無頭 CMS專注於內容創作部分，並提供了一種連接單獨的內容呈現工具的方法。缺乏面向用戶的前端使其無頭，並使其能夠靈活地通過其 API 使用任何工具。

能夠從頭開始設計自己的前端為許多開發團隊帶來了自由。您可能擁有一支精通工程師團隊，他們擅長在 Vue.js 中交付流暢的單頁應用程序，或者使用 11ty 快速渲染、防彈的靜態生成網站。所有最新的 Web 開發框架都旨在輕鬆處理可以從任何無頭 CMS 提供的結構化數據。

無頭 CMS 是一種專注的工具。與一體化解決方案相比，它的責任更少。無頭 CMS 提供的 API 端點在系統之間提供了清晰的分離，因此您可以隨著事情的發展獨立地交換前端或後端架構。您的產品在增長，工俱生態系統在擴展，新方法變得可用。您的後端和前端要求將發生變化。如果您有無頭設置，您將能夠更輕鬆地適應，因為您的前端和後端已經被 API 完全分開，您可以獨立昇級它們。

無頭適合我嗎？

最值得注意的是，headless 為您提供了滿足挑戰性要求所需的靈活性。如果您必須對多合一產品進行大量修改，則可能很難實現您的目標。將無頭工具與更小、不同或自製的前端相結合可能是交付所需設計和用戶流程的最簡單方法。

如果您想微調產品結帳流程的每一步，您可以使用無頭商務選項來實現這一點，
如果您想對 Time to First Byte 進行大量優化，您可能需要使用靜態站點生成器，該生成器基於無頭 CMS API 在更改時重建內容，
如果您託管自己的工具並且對安全性持謹慎態度，您可能希望將您的創作環境鎖定在防火牆後面，並從更簡單的基於 Jamstack 的前端無頭地使用它，
如果您為各種客戶端提供相同的內容，例如 Web、本機應用程序或第三方小部件，您可以構建它們，使它們都可以通過同一個 CMS 進行無頭通信。

如果您可以使用多合一工具完美地滿足項目要求，那麼無頭選項對您來說可能有點矯枉過正。同樣，如果您的團隊對您當前的多合一解決方案非常滿意並且精通，那麼您真的不需要擔心拆分前端和後端工具。但是，如果相反，您遇到了工具的限制，那麼無頭模式將使您能夠直接解決您的痛點。

示例：無頭電子商務

讓我們看一個特定的無頭選項：您可以將現有的電子商務平台（例如 Shopify）集成為一個完整的流程來接管整個結帳流程，或者您也可以使用 Shopify 提供的無頭選項。

在前一種情況下，您的設計將嚴重依賴 Shopify 的模板和開箱即用的功能，因此可以調整結帳流程，但非常有限。
在後一種情況下，您可以以任何您喜歡的方式設計結帳流程，並且您將依靠 Shopify 僅執行金融交易。

顯著的區別在於，無頭選項將要求您構建用戶看到的每個視圖。再一次，如果這聽起來像沒有好處的麻煩，那麼您可能不需要無頭解決方案。

需要無頭版本的團隊將歡迎它提供的自由。您的設計將沒有任何限制，您將能夠控制每個視圖的每個像素。您將完全控制在用戶設備上執行的所有代碼，因此您可以跟踪、優化和加速每一次交互。

同時，您仍然將交易處理留給您的無頭電子商務解決方案，因此您可以從他們的後端系統中受益。

底線是：如果您正在努力解決當前電子商務解決方案中的瓶頸——無論是繁重的前端、複雜的 UI 還是無法訪問的設計——那麼無頭選項將使您的團隊更容易解決這些問題。同樣，如果聽起來它可以讓您的團隊更輕鬆地通過更快、更順暢地部署新功能來增加您的轉化渠道，那麼考慮無頭選項也是一個好主意。

使用單一平台避免鎖定

看看當今前端的狀態，在前端和後端工具的選項不斷擴展的世界中，將您的創作和內容交付工具解耦是構建事物的最安全方式。創作和閱讀環境具有不同的需求集的情況並不少見，因此能夠選擇分別解決這些需求的工具可以為雙方提供更好的選擇。

基於 Jamstack 的設置由 API 啟用，因此它們通常與無頭 CMS 相關聯。不過，做出無頭選擇並不需要 Jamstack 前端。當然，如果您願意，您仍然可以運行一些服務器端代碼。

例如，我幫助構建了一些運行 Node.js 和 Express 的站點，這些站點使用Wordnik.com等後端 API，並且這種流行的模式運行順暢。 通過 API 訪問您的數據可以在生產中放棄您的服務器端代碼，因此如果這在您的項目中有意義，您可以輕鬆地採用 Jamstack 等客戶端方法。

“一體式”解決方案的問題在於，它們每個人都有很多承諾。例如，您必須致力於支持數據庫和編程環境，或者選擇支持的 SaaS 供應商；此外，您的設計更改必須在可用的主題和插件中進行。

有了無頭，我們就擺脫了被鎖定在一個平台上。因此，如果您需要為您的網站使用新的前端框架，或者您想要移除昂貴的生產基礎設施並使用靜態站點生成器，或者可能想要切換您的 CMS 而無需從頭開始重建所有前端 - 與替代方案相比，當您使用無頭選項時，您可以以更少的摩擦來實現所有這些。

讓我們看一個簡單的例子。想像一下，您的組織提出了一項新計劃和新設計，並從頭開始創建流程以滿足新的用戶需求。突然之間，需要組裝一個新的技術堆棧來滿足這些要求。

選擇無頭選項將使您的產品更長壽，並使您的內容更容易順利地進入多個交付渠道。
“

在這種情況下，您需要尋找一個完美的現成解決方案來完全滿足您的需求，或者妥協一些設計和用戶流程要求，以使其運行良好。但是，如果您的設計或性能要求很嚴格，那麼通過無頭來實現這些目標可能會更容易。

最重要的是，在選擇無頭選項時有很多用例，可以讓您的產品更好地延長使用壽命，並使您的內容更容易順利地進入多個交付渠道。能夠將您的內容作為結構化數據使用，可以使其在您自己的網站、本地應用程序中蓬勃發展，並與外部資源聯合。

並非一切都必須是無頭的

聽起來無頭總是更好的選擇，但事實並非如此。如果在您當前的項目中，您不太關心上述的設計和技術選項，或者您只需要一個可以在今天完成這項工作的運營網站，那麼您可能不需要那麼多的 headless。

當然，從概念到交付的速度很重要，因此，在沒有適當的工程支持的情況下，您只需點擊幾下即可獲得一個外觀不錯的網站，您可能希望將無頭選項推遲到以後。一旦你覺得你的想法可能奏效，你就可以專注於網站優化和長壽。

無頭選擇如何幫助您從失誤中恢復過來

升級後端

按用戶定價的風險

不久前，我幫助建立了一個可供數十位作者使用的博客系統。我們對其中一家無頭 CMS 供應商的功能集印象深刻，選擇了它作為無頭 CMS，並喜歡在它之上構建一個可以順利融入我們產品套件的前端。最終，該公司決定將作者人數擴大到幾千人。

大多數託管 CMS 解決方案不會針對這麼大的用戶數量發布定價結構。當我們詢問在同一平台上繼續運行它的成本時，我們不太喜歡這個答案。為了讓這個系統繼續具有商業意義，我們不得不更換我們的 CMS。由於無頭架構，我們能夠在不報廢前端的情況下進行交換。

API 節流

如此多的專注於創作環境的初創公司能夠使用開發人員友好的 API 構建漂亮的產品。 Airtable 是電子表格創新的一個例子，它通過用戶友好的 UI 結合了通過有據可查的 API 的干淨的開發人員體驗。

我構建了一些有用的原型，將抓取的數據輸入 Airtable，由人類專家編輯，然後使用他們的 API 為在主站點上運行的內容視圖和在第三方站點上運行的嵌入提供支持。在設置讀取系統時，我將 Airtable 數據提取到可以處理大流量負載的生產就緒系統中，這在一段時間內運行良好。

不過，我開始遇到寫入數據的問題。由於每秒 5 個請求的硬性限制，呼叫失敗。達到此限制會導致 30 秒的完整 API 請求鎖定。我試圖從分佈式系統中發送數據，所以我添加了節流閥並將事物分成不同的基礎。

隨著系統的擴展和數據量的增長，我們已經超越了這個工具。我能夠通過將基本的數據編輯功能構建到一個基於從 airtable 讀取的 AWS DynamoDB 實例的系統中來解決這個問題。我們能夠快速將流暢的 Airtable 創作 UI 功能換成更大規模和更低的每月 SaaS 賬單。

這是無頭創作工具的 API 提供的前端和後端之間的清晰分離如何讓您精確定位痛點的另一個示例。

升級前端

閃亮的新框架

已經存在了一段時間的組織經常遇到需要支持建立在各種技術堆棧上的生產系統的問題。同質化工具和創新都面臨著持續的壓力。我是一個負責構建視圖和小部件的團隊的一員，這些視圖和小部件將集成到基於無頭 CMS 的現有產品中。我們在使用不同的輕量級前端工具快速構建原型時獲得了很多樂趣。

我們舉辦了一場內部競賽，看看前端團隊中的哪個工程師可以根據從無頭 CMS API 端點提供的內容來打造最好的前端。一個演示文稿具有最好的功能集和最小的代碼佔用空間，因此開發人員獲得了項目並通過使用 Riot.js 構建它來交付產品。

Riot.js是一個很酷的小庫，將大量功能打包成一個小尺寸。它可以幫助您編寫數據驅動的單文件組件，例如 Vue.js。當這個前端的開發人員在發布 1.0 版後不久離開公司時，團隊失去了唯一對該庫充滿熱情的人。

有時，從令人興奮的、新的、快速的發展模式到技術債務的轉變會很快發生。
“

幸運的是，無頭 CMS 架構的解耦特性提供了在不觸及後端的情況下更改前端的靈活性。我們能夠重寫前端代碼並根據其他項目中更常用的不同庫交換更新的前端組件。

原始速度

我喜歡 Ghost 項目。我是早期訂閱者，因為看到基於 Node.js 構建的類似 WordPress 的解決方案很酷。我尊重這個組織提供基於他們不斷完善的開源工具的服務。當我將它用於我的個人博客時，我對這個工具非常滿意。

不過，解決方案的一個方面並不完美。我的 Ghost 託管博客上的第一個字節的時間太慢了。由於我可以通過 API 檢索所有帖子內容，因此我能夠在 S3 + Cloudfront 上設置我自己的靜態生成前端，該前端使用了我在 Ghost 中編寫的所有帖子內容，但獲得第一個字節的時間更快。

無頭 CMS 即服務

有許多軟件即服務業務已經全力以赴。與這些供應商之一註冊可以立即為您提供友好的內容編輯環境和乾淨的 API 端點以供使用。以下是其中一些的快速比較，它們都有非常低成本的入門級計劃，並且非常關注無頭 CMS 體驗。

所有這些服務都有一套堅實的基礎功能。它們都包括靜態資產託管、保存的修訂歷史記錄和有據可查的本地化支持。它們在內容創建用戶界面和 API 功能方面有所不同。

小販	內容編輯	API
黃油CMS	帶有 Word 樣式的 WYSIWIG 編輯器的表單，帶有切換到 HTML 代碼的功能。您可以通過鏈接前端模板 URL 來配置一鍵式完整預覽。	REST API 預覽顯示在與內容編輯器相同的屏幕上疊加可用的完整 JSON。
自在	基於表單的編輯器；沒有看到如何設置 1-click-in-context-preview。	REST API 端點鏈接在編輯器模式下可用，GraphQL 即將推出。
宇宙	帶有 Word 樣式的 WYSIWIG 編輯器的表單，帶有切換到 HTML 代碼的功能。您可以配置自己的預覽 URL 以提取草稿 JSON。	REST API。可以從對象編輯器中單擊 2 次查看完整的 JSON。
數據管理系統	基於表單的編輯器，可以設置一個插件來啟用整頁預覽。	帶有 API 瀏覽器的 GraphQL API。
故事塊	基於表單的編輯器，可視化編輯模式，帶有全頁預覽。	REST API，從編輯器模式一鍵獲取完整 JSON。
成形	基於表單的編輯器，具有可通過上傳模板進行配置的實時預覽。	帶有 API 瀏覽器的 GraphQL API。

令人興奮的無頭模式

使用基於 GitHub 的 CMS

能夠利用 GitHub 中的用戶管理、版本控制和批准工作流程是一大優勢。 不必在新系統上設置新帳戶很有幫助。能夠在內容更新旁邊看到評論的歷史是很好的。

有不同風格的基於 GitHub 的 CMS 工具。這是啟動文檔站點的一種快速方法：Spacebook，您可以將其與 Netlify 集成以獲得更清晰的降價編輯 UI 或直接在 GitHub 上使用。

現在內置在 GitHub Web 編輯器中的預覽功能使不熟悉 HTML 的人更容易使用其中的一些工具。我喜歡 GitHub 以完整預覽模式顯示降價更改的視圖豐富的差異選項。

這是 85 個 CMS 工具的優秀列表，可讓您對它們是否基於 GitHub 進行排序。

熟悉工具的 API

您的WordPress 安裝附帶 API 端點，因此您可以繼續以無頭方式使用您的團隊所擁有的創作工具。 WordPress 為他們的 REST API 提供了很好的文檔。這在新的 WordPress 安裝中啟用，因此當您啟動新的 WordPress 創作環境時，您可以開始從https://example.com/wp-json/wp/v2/posts讀取 JSON。

WordPress 設置頁麵包含一個更新服務字段，您可以在其中輸入您希望它在內容更改時 ping 的服務的 URL。這非常適合觸發無服務器工具以獲取最新更新。 WordPress v5 在設置的寫作部分有這個字段

使用 WordPress，您可以調整“更新服務”字段，您可以在其中輸入您希望它在內容更改時 ping 的服務的 URL。（大預覽）

組合數據源

在加利福尼亞州使用無頭工具幫助我們構建了提高性能標準的應急響應站點。我們完全控制了前端架構，並且仍然能夠讓作者使用熟悉的創作工具。

我們無頭使用 WordPress ，通過 FAAS 寫入 GitHub。我們還將其他數據源寫入存儲庫，並在每次更改時觸發靜態站點生成器構建。除了原始編輯內容之外，寫入 git 的數據示例是每天僅更改一次的數據，例如 topline 統計數據和我們每個頁面的人工翻譯版本。

使用GitHub 操作作為構建觸發器，我們可以將多個不同的數據源集成到站點中，從而實現快速發布和較小的生產基礎架構佔用空間。當我們遇到與政府大流行公告相關的流量高峰時，更少的生產基礎設施讓我們可以輕鬆呼吸。

架構的 WordPress -> FAAS -> GitHub repo 部分由 Carter Medlin 創建。在我們設計和構建站點前端的幾天內，他從頭開始將這條管道連接在一起。這是在無服務器 MS Azure 功能上運行的，因此基礎架構成本和維護成本低。它從前面描述的 WordPress 更新服務獲取 ping，從 WordPress API 中提取 json 並將新內容寫入 GitHub。此無服務器端點的代碼可在 GitHub 上查看。

Out 機器人在收到來自 WordPress 的 ping 信息時，會努力發布所有內容更新。此活動創建每個更新的易於查看的日誌，並能夠使用通常的 GitHub 流程恢復更改。

使用 11ty 靜態站點生成器構建該站點的前端非常快速、有趣且運行良好。當並髮用戶數量開始增加並且我們發布大量內容更新時，我們會在與大流行相關的新聞中獲得大量流量峰值，並且知道我們有一個靜態前端可以降低風險。

我喜歡 11ty 社區通過其社區排行榜和輕量級架構關注性能和可訪問性的方式。確保州政府構建的工具適用於所有加州人非常重要。我們希望事情可以在低帶寬條件下在任何設備上運行，並支持所有輔助技術。我們可以使用 11ty 之類的工具讓交付快速、可訪問的網站變得更加容易，這真是太酷了。我們在前端使用 Web 組件來提供附加功能，同時保持代碼量較小。

在 Covid19.ca.gov 上，我們可以使用 11ty 之類的工具，這些工具可以更輕鬆地提供快速、可訪問的網站。（大預覽）

做出無頭選擇時的注意事項

對無頭工具為您的團隊提供的功能感到興奮嗎？可用選項的數量可能是壓倒性的。這是可以幫助您減少選項的功能列表：

創作環境功能

易於編寫文檔
易於添加結構化數據
佈局選項
預覽功能
內容審批工作流程

內容 API 功能

有哪些查詢可用
內容結構的粒度如何
數據訪問是否有任何限制（Airtable REST API 硬限制）
可擴展性：是否需要在內容 API 前面放置 CDN
易於添加本地化
獲取您的內容，如果您改變您的計劃，提取所有數據會有多難？

成本

您是否為託管解決方案按用戶付費？
您是否正在管理您在自己的環境中安裝的開源軟件？
用戶帳戶是否易於管理？
您可以與現有的單點登錄解決方案集成嗎？
產品是否通過了安全審核，是否包括雙重身份驗證？

源代碼控制/批准流程

內容是否版本化，以便您可以回滾到以前的版本並跟踪發布的內容以及何時進行了哪些編輯？
您可以在發布之前分享新版本的內容嗎？您可以限制對這些預覽的訪問嗎？

靜態文件管理

您的作者添加新圖像、pdf 等文件有多容易？
將作者上傳的文件掛接到圖像優化流程中是否容易？

無頭的地方

當您仔細研究無頭環境時，您會發現無頭工具有意限制其功能範圍並提供集成到更大系統的方法。當系統變得更複雜時，拆分特定功能是有益的。當您使用更小、更專注的工具時，更容易做出特定選擇來限制更大代碼足蹟的成本、安全性、維護和託管要求。

值得注意的是，無頭選項通常需要自己編寫一些代碼。然而，隨著前端越來越多地是一組預先構建的組件，並且通常是一個完整的現成設計，其中填充了您自己的數據，期望更多的方法來混合和匹配專業工具並無縫集成不應該太冒昧無需自己編寫代碼的無頭選項。

一個項目的完美後端可能只是一個 SAAS 訂閱或一個開源項目安裝。這可以無代碼地與滿足您所有需求的現成前端集成。我看到 Stackbit 已經將無頭 CMS 與他們的無代碼前端融合在一起。我可以使用 Stackbit 的 WYSIWYG 無代碼頁創建工具設置一個新站點，然後我可以從不同供應商的一組無頭 CMS 選項中進行選擇，以管理完整的站點數據。

在本文中，我們討論了一些使用無頭模式幫助我工作過的公司應對變化的用例。無論您是出於應用程序架構的靈活性、用戶體驗控制還是仔細考慮服務的壽命，無頭選擇都很誘人。

我很高興看到這個空間如何繼續增長，並將繼續尋找使用這些選項的方法來提供更好的產品，並使我作為開發人員的工作更輕鬆。