CaaS: 內容是新的基礎設施 Content-as-a-Service

內容是每家企業的必爭之地，根據 CMI 的數據報告，88% 的 B2B 企業天天至少產生一篇內容。內容正在成爲新的基礎設施，Content as a Service 能夠被簡單理解爲一種 CMS（Content Management Systen，內容管理系統），可是和傳統的 CMS （如 Wordpress、Drupal 等）徹底不一樣。傳統 CMS 聚焦於內容管理和建立網站（好比 Wordpress 提供的大量網站模版），而 CaaS 只聚焦於內容的生產，並以 API （應用程序編程接口）的形式向外提供服務，這些 API 可被二次編程，從而用於打印機、移動應用或者其餘設備上。

在這篇文章中，你將瞭解到什麼是 CaaS 以及爲何內容是一種新的基礎設施。在你想要使用 CaaS 時，本文可做爲對比 CMS 和 CaaS 優劣的參考文章。咱們還會羅列一些 CaaS 的使用場景，幫助你更好的瞭解 CaaS。

內容是新的基礎設施

互聯網上的全部應用都是信息管理軟件，這些軟件在本質上是由一張張互相聯繫的表組成的（若是你不理解這句話，那麼你能夠將一個網站想象成三張 Excel 表，一張表存儲網站用戶，一張表存儲網站內容，還有一張表存儲網站分類）。當你使用一個傳統 CMS 時，你能夠建立一些分類，並在分類上面撰寫文章，這樣的操做在網站時代是比較友好的，由於每一個用戶都只有一個平臺 —— 那就是瀏覽器，這種方式在瀏覽器上分發很是容易。

進入移動時代後就不同了，一家公司至少擁有三個平臺（Web、iOS、Android），針對這些平臺，每家企業都須要定製本身的 CMS，他們多是在 Wordpress 上作深度定製，也多是本身開發。作的多了以後，你們會發現，每家公司都在作一樣的事情 —— 寫管理界面、建表、寫 API，這些界面多是與公司業務高度結合的，好比頭條 APP 的後臺與微信公衆號的後臺確定是不同的。但細細研究卻會發現，其本質就是五個事情：增刪改查和聯表。

因而有人作了一種名爲**「Headless CMS」**的平臺出來，這種平臺能夠在線設計表和表的字段（和 想象下 Excel 的建表，寫字段，可是用起來要比 Excel 簡單不少），而後系統會根據設計好的表和字段自動生成立馬可使用的 API，這些 API 符合一種名爲 RESTful 的規範，這種規範是開發者們共同遵照的一種規範，只要看到這個規範，開發者就知道該如何使用這些 API。知道如何使用以後，開發者就能夠將這些內容用於實際的應用中（也就是展現給終端用戶看），多是抖音，也多是微博（這些本質上都是信息管理軟件）。

這麼作帶來的好處是，假如一款產品上線後，產品經理想要新上一個「用戶反饋功能」，在沒有 Headless CMS 的時候須要開發者在數據庫中建一個新的表，而後用一上午的時間調通 API 和圖片上傳功能，最後再作個界面。有了 Headless CMS 以後就不得了了，產品經理想要用戶反饋什麼內容直接在後臺建好字段，而後 API 就自動生成了，開發者省去了建表、建字段、調 API 的時間，直接進入界面開發了。若是產品經理想修改需求，本身就能直接改，這樣不但大幅提高了工做效率，還減小了不少產品經理與程序員之間因爲需求變動帶來的巨大摩擦，所以世界更加美好了。

這類 Headless CMS 正在開發者圈子中流行開來，開發者開始主動將這類軟件用於公司業務中。「Headless CMS」 翻譯成中文就是**「無頭 CMS」**，簡單來講就是無論界面生成的 CMS，他使用了一種名爲「RESTful API」的規範對外提供服務，開發者根據這套規範能夠作任何應用。

一旦標準化，就會變成基礎設施，內容正在這條路上。

什麼是 CaaS

CaaS 是內容基礎設施的雲上版本，他提供雲上的 Headless CMS，並提供公網可用的 API 讓開發者能夠直接使用，開發者省去了部署運維的精力開銷。除此以外，其還有 Headless CMS 不具有的高性能高可用優點。大部分 Headless CMS 是開源的，只能處理百萬級別的數據，對於千萬或億級的數據，仍須要作很多優化工做，而 CaaS 將這些也省去了，這就是雲計算的好處，標準化一切能夠標準化的東西。

企業對於 CaaS 的擔心主要仍是安全和隱私問題，也就是你們常常聽到的對雲計算的質疑 —— 「憑什麼我把數據、代碼和業務給你，還要給你錢？」

對於中國的企業來講可能還有合規問題。若是在中國作 CaaS，必須投入大量資金和人力到內容審查上。

若是一個 CaaS 能作到壟斷作成寡頭，那麼將來的一個最大的可能就是開放版的微信公衆號。經過其 CaaS 平臺分發出去的內容不只有社會大衆的娛樂內容，還有不少專業知識，而全部這些內容都是開放可檢索的 —— 若是說中國互聯網最大的遺憾是什麼，那就是大量優質內容沒法經過搜索引擎檢索，中國只是個互閉網。

CaaS 相比 CMS 的優點

CaaS 相比 CMS 有很是多的優點。

1. 結構化的內容。CaaS 可讓內容管理者從「管理頁面」的思惟轉向「管理內容」，這將讓咱們互聯網上的內容變得更加專業和優質。
2. 代碼結構優化。傳統 CMS 的內容和界面都是耦合十分嚴重的，像 Wordpress 使用了很是多的自定義指令去表示網頁內的信息，從開發者的角度來講，這點是沒法忍受的。CaaS 容許內容代碼和界面完全分離，這對開發效率來講會有更大幅的提高，而且符合現代開發框架。
3. 內容和展現分離。傳統 CMS 因爲其界面佈局等緣由會制約內容的發展，有了 CaaS 以後做者只用關心內容而沒必要關心界面設計，只須要生產優質內容。
4. 雲原生應用。CaaS 是一種雲原生應用，也是 SaaS 的一種，雲服務提供商會爲你安裝、維護和作自動伸縮、性能優化等工做，你須要作的只是將內容遷移到 CaaS 和使用。
5. 個性化。使用 CaaS 能夠爲所欲爲的定義你想要的表和字段，而且有能夠當即投入生產環境的接口使用。這在作一些 A/B 測時會很是有用，由於全部的修改都不須要改動底層的數據庫或代碼結構。

CaaS 的使用場景

總的來講，CaaS 的主要特性就是自由和靈活，如下是依據這些特性的典型使用場景（其實 CaaS 的應用場景很是普遍，幾乎全部信息系統均可以用 CaaS 完成，如下只是拋磚引玉）：

1. 多渠道分發。這裏的多渠道分發主要是指分發到不一樣的內容平臺上，多是三端相同的應用，也多是三端不一樣的應用。經過 CaaS 的開放 API 特性，做者只須要寫一次，就能夠重用這些內容，並分發給全部兼容了這些 API 的網站。
2. 移動應用內容分發。不少移動應用都直接內嵌網頁來展現內容，而 CaaS 的 API 容許移動應用在很方便的進行內容展現（傳統的 CMS 沒有結構化的 API 可用）。
3. 移動應用後端。移動應用本質上也是信息管理軟件，使用 CaaS 管理移動應用的業務邏輯是個不錯的解決方案，CaaS 是個成熟的方案，比本身寫要容易且穩定不少。
4. 與身份認證雲配套使用。使用身份認證雲（如 Authing.cn）的用戶每每有自定義字段和內容管理的需求，這些在業務層面的功能身份認證雲是不提供的，那麼 CaaS 便成爲了拓展這些字段的一個良好補充。咱們所知道的案例是，將 Authing.cn 配置進 Strapi(一款 CaaS 產品)，登陸 Strapi 時使用 Authing 登陸，而後攜帶 Authing 的 Token 訪問 Strapi 的資源並進行受權認證。
5. 我的博客。與傳統 CMS 同樣，CaaS 也能夠做博客，不過須要創做者懂一些編程能力。若是懂編程，CaaS 是個更容易實現我的博客的方案。

一個優秀 CaaS 應該具備的功能特性

做者角度

1. **體驗良好的編輯器。**有相似石墨文檔或 Notion 的文檔編輯體驗，讓做者儘量溫馨的創做內容。
2. **簡單符合直覺的建表及字段配置。**讓內容創做者能夠很容易管理、修改和與團隊協做。

開發者角度

1. 支持 CRUD 的自動生成並符合 RESTful 規範。
2. 支持每一個 API 邏輯的增長和修改。 開發者能夠很方便的無限制的拓展 API 的業務邏輯。
3. 支持拓展計算能力。 支持函數計算，讓開發者能夠無限制的拓展平臺能力。
4. 支持數據的受權以及標準認真協議（OAuth 2.0 或 OIDC）。 能基於 RBAC 或 WAC 對數據進行細粒度受權，同時支持 OAuth 2.0 或 OIDC 協議，能兼容各種身份提供商的登陸認證，並能使用身份提供商的 Token 受權資源訪問。
5. 高可用高性能。 低時延，快速響應以及完善的日誌記錄和錯誤監控。

如何開始使用 CaaS

1. 若是你是 JavaScript 開發者，咱們建議到 Github 上搜索 Strapi 使用；
2. 若是你是其餘語言開發者，請到 Google 上搜索 Headless CMS 尋找你想要的語言使用；
3. 若是你是非工程人員，請到 Google 上搜索 Content as a Service 找到最適合你的在線 CaaS 使用。