專欄：頭無身和構成式平臺的優缺點
概述
對於希望為桌面、移動裝置和物聯網開發先進數位型驗的銷售人員，可能會遇到諸如無頭和可組合等術語。雖然它們的目標都是連線一系列功能以建立創新、具有吸引力的全通道體驗，但無頭工具和可組合的框架代表著不同的概念：無頭指的是產品的後端與面向觀眾的前端體驗分離或解耦。可組合則是指組裝體驗的方便程度和誰負責組裝。銷售人員和企業使用者可以透過高度可組合的平臺製作體驗；更僵硬、不太可組合的系統需要開發人員。讓我們更進一步定義無頭和可組合並聚焦其優點、缺點和注意事項。
為什麼 composable 架構受到關注
傳統上，網站的開發依賴於全功能解決方案或基於傳統架構的產品，除非它們來自同一解決方案或架構，否則不允許與新的元件進行整合。composable 變得越來越受到歡迎，因為它使開發人員可以插入和播放無頭產品或元件，這有助於最快地推向市場，並有能力快速測試、學習和創新。與傳統解決方案相比，可組合始終為新功能保留未來設計的空間，從而不會迫使公司拆除舊基礎設施。
composable 受到質疑的地方
composable 的反對者主張它太復雜，部分原因是因為沒有兩種可組合的架構是相同的。因此需要更多的內部標準管理實踐，以更新開發人員和其他人員的特定框架並確保組織內的一致性。此外在技術堆疊中在各種工具之間來回切換對於銷售人員和企業使用者來說是一項繁瑣的任務。更不用說新增過多可能會導致團隊在哪些任務上使用哪些工具方面的混亂效應了。
為什麼 headless 受到關注
透過 API 和微服務，無頭產品旨在提供狹義的、專為特定功能而建的功能。因此品牌可以將內容儲存、管理和傳遞到完全與幕後內容或商務功能分離的前端，即被定義為「頭」或終端使用者體驗。三個優點立即顯而易見：品牌可以自由選擇任何工具和框架，而不是必須使用遺留平臺中的工具和框架。與可組合一樣，無頭的靈活性為品牌提供了在執行體驗方面的控制權。在過去五年中，前端框架和展示速度超過了封閉式平臺，因此採用無頭的品牌可以建立符合消費者需求並比以往任何時候都更具創新性的體驗。無頭工具為品牌提供了選擇，使其整體的數位型驗更具彈性。對於消費者來說這種靈活性培養了他們與最喜愛品牌之間更強烈、更真誠的關係。
headless 的質疑
由於無頭將內容撰寫過程與跨渠道的內容顯示分開，因此商務使用者和銷售人員可能需要依靠開發人員協助修改和傳遞體驗，從而對整體工作流程失去了掌控。例如，習慣於在封閉式平臺上構建頁面或標準工作流程的商務使用者可能沒有使用無頭的正確工具來完成工作。由於 API 是為開發人員使用而設計的，因此大多數無頭產品在可組合性方面得分較低。然而您可以使用 API 聚合工具、作為服務的前端解決方案和數位型驗構成平臺等技術將無頭解決方案納入可組合系統中，這些技術通常因其 API 編排和業務使用者的無程式碼工具而產生最高水平的可組合性。實施解決方案後，codegen，它借用市面上主流的 API description，產出完整的呼叫模板。通常情況下呢，這種 codegen 還有完整的 API Client 可以使用。然後，沒有程式碼構建工具的市場來滿足了業務人員新增功能的需求，同時讓開發人員有時間進行更有價值的專案、創新以及建立新的渠道來跟上市場變化的速度。
如何解決 headless 和 composable 系統中的問題
對於已準備好採用無頭和可組合的公司來說最大的陷阱是粘合程式碼，它潛藏在後端和前端之間，作為連線儲存庫和體驗的視覺層的管道。隨著時間的推移，所有程式碼都可能變得乾燥、硬化和堵塞訊息流，幾乎抵消了可組合性和靈活性的所有好處。不僅如此，諸如構成式解決方案等許多進入可組合解決方案的工具可能需要額外的程式碼。所有系統都必須相互通訊，最終形成程式碼粘合。為了保持可組合，開發人員必須鬆散地耦合解決方案的元件，避免堆疊粘合程式碼和技術債務。否則，必須進行大量的額外工作，以替換陷入粘合程式碼中的系統，從而大大減緩銷售工作流程和專案的進展速度。當粘合程式碼造成災害時，連簡單的任務，例如構建網頁都很難執行。
總結
跨零售、金融服務、旅遊和酒店等行業，消費者正在尋求更個性化的體驗，包括影片、擴增現實（AR）和其他吸引人的功能。因此企業必須調整建立程式，以實現沉浸式和現代體驗，並謹記銷售人員需要用於即時更新訊息的系統，而開發人員需要釋放他們的枷鎖以專注於工程中心的專案。理解無頭和可組合平臺的細微區別是實現現代企業和消費者所期望的數位型驗的關鍵。然而請記住，根據產品不同，無頭和可組合可能無法像預期的那樣無縫執行。
