CCMS

以往CMS系統只適用在管理官網和部落格內容上，但現階段的CMS則更加專注於通過管理資料來提高我們的工作效率和覆蓋更多業務場景

對於運營同學來說，就是很好用的管理平臺，可以管理公司所有產品。同時需求可以快速的被滿足不用再一直等排期

對於技術同學來說，就是把以往枯燥無味的管理後臺手動開發變成了線上視覺化平臺，同時對於運營同學一些簡單需求也可以通過系統直接實現

對於個人開發者來說，就是同時是個後臺也是個後端服務，可以更加專注於產品本身

特點

• 無頭/無狀態，意味著並不侷限你把他用在哪個業務場景上
• 整合解決方案，意味著它可以幫你更快的構建起專案
• 好看好用，沒辦法產品負責人審美和互動要求太高了
• API暴露，甚至連客戶端的後端服務都不用寫
• 檢視看板，輕輕鬆鬆搞定資料檢視和看板
• 流程覆蓋，不管你是產品、運營還是技術都都可以在同個平臺完成大量工作
• 觸發器，資料操作後流程處理

使用場景

場景一：小活動或者小工具的後端服務和管理後臺

比如說最常見的留言板、邀新h5等，這些產品其實功能上就很簡單。技術上基本就是對資料的增刪改查。

以往我們需要準備一個後端服務對資料庫進行操作，一個運營後臺讓運營同學進行使用

但，是不是有點枯燥和重複？

我們轉變一下，我們先通過CCMS建立一個專案和資料結構，這時候運營後臺就已經完成了。
之後我們通過暴露成API，讓前端同學直接進行呼叫。這時候後端服務也完成了。

甚至一行程式碼都沒寫，何樂而不為？

場景二：專屬運營後臺

以往來說，當開發完一個大型專案的時候，我們還需要再單獨寫一個運營後臺

但這活其實大家都不愛幹，因為無聊枯燥還要頻繁對接。一般都交給實習生做，然後做出來的質量又實在太差

那這玩意其實也可以搞通用。因為這個需求無非還是對資料的增刪改查，加上角色許可權這類功能。

如果再複雜一點，我們也可以通過觸發器和檢視功能解決

場景三：前端後臺

比如我們頁面上有些經常更新入口，那就需要後端，可這玩意寫起來很無聊，並且根本不需要什麼什麼型別和關聯。而且這玩意剛好就是CMS負責的內容
那麼流程就變成
前端同學新建資料模型 => 填寫內容 => 使用系統提供的API => 結束
可以說5分鐘就能搞完之前30分鐘以上的事情

為什麼是30分鐘？後端同學接到需求需要理解清楚 => 建表 + 索引 => 後端服務增加型別 + 路由 + 實現 => 部署服務 + 閘道器 => 與前端對接 => 修改介面 => 完成

特別是對接這塊耗時最久，因為需求方不一定能說清楚自己的需求，實現方也不一定能理解完全需求，然後對接又涉及到溝通。

有人在用嗎？

有，我們公司自己就在用。

我們本身是做各種小產品的，以前開發一個產品

討論定項半天，原型半天，前端1天。一方面是風格就是快，一方面是產品和前端能力都很好。
但後端開發和資料聯調反而要花上一週以上時間。原因是
一方面我們後端人員思維比較傳統，所以不適用這種節奏
一方面涉及到溝通就會浪費太多的時間
更別說還要開發管理後臺這種技術不想開發，運營又很需要的事情

那麼，如何解決這個問題呢？

正常來說，就是招思維不那麼傳統和溝通能力比較好的後端，但我們公司沒有資源幹這件事
還有就是通過流程和規範提高效率這種... 就是能做的都做了，但確實需要這麼多時間

所以，我們嘗試其他思考，能不能自己開發管理後臺？ 於是我們嘗試了直接通過資料庫管理軟體、Headless CMS來解決

但有一定侷限性，比如資料庫管理軟體好用的都是桌面軟體，而運營同學是隨時隨地的。
Headless CMS呢，現有產品都不能完全覆蓋我們的需求

但至少給我們提供了思路，有了Headless CMS我們就可以實現快速搭建管理後臺

但產品前期開發時間還是沒減少，這時候就輪到另一個解決方案上場，那就是雲開發
前端同學自己寫後臺服務，然後部署到雲開發就行

當然，這裡要擴充套件說一下
首先，前端同學後臺服務其實佔不了多少時間因為

• 用JavaScript語言可以寫後端服務
• 絕大部分產品的需求就很簡單，也不用特別考慮效能
• 自己對接自己效率當然更高啦
• 雲開發直接免運維
• 現在也很多一體化框架，寫的環節效率都很高，前後端直接通過函式呼叫

換句話說，大部分需求理論上無論前後端開發都是一個時間，而且並不需要很久，可能就是1天。真正需要解決的是4天的對接（不過是同時開發還是順序）（對接慢的原因大家都深有體會就不多說）

然後我們嘗試這個方案以後，開發效率大幅度提升，基本上一個小產品3天完成，比以前快1倍。身心也愉快

其次，並不是說就可以沒有後端同學。或者說應該這麼理解，後端同學的精力也可以放在更重要的事情上

比如

• 複雜產品的三高要求
• 提供更基礎的服務

比如我們要開發一個複雜的產品，那肯定要求就不一樣，術業有專攻效率才會更高
而基礎服務的開發就是完善生態，這樣業務開發的時候就會更加的方便和可靠

與其他產品不同

• Headless CMS 例如strapi，底層邏輯相同，但功能更強大