前言
從最開始的小公司做小**，到現在進入現在的公司做專案，發現小公司裡很多很多任務作都是重複的勞動（增刪改查），不過想想也是，業務軟體最基礎的東西不就是增刪改查嗎。
但是很多時候，這種業務邏輯其實沒有必要挨個重寫。總不能說你的增刪改查比我的高階很多。很大程度上，複雜的問題只是資料太多了怎麼優化。
簡介
在真的開始做之前，先來簡單介紹幾個概念。簡單介紹一下paas是什麼，大概意思就是已經做好了乙個大的平台，你可以在上邊快速的配置、擴充套件你的服務。
詳細的介紹推薦看一下阮一峰老師的部落格
概念上
我想從零開始搭建乙個能夠配置定義業務，通過**擴充套件業務的平台。在這個平台上，簡單的需求，不寫**。複雜需求，只寫與標準不同的**。
有啥好處
提高生產力
其實，做軟體的大部分時候，都是在寫增刪改查，實在是太簡單了。搬磚誰不會對吧，要想搬得快，不需要你有多麼好的腳力，更多的時候，你可能需要乙個塔吊。
穩定的高負載
paas的設計之初，就是為了比較大的資料量來考慮的。專案小的時候，怎麼著都行，但是，資料量一旦上來之後。小的專案可能根本沒法用，如果是paas平台的話，你可能只需要多幾台機器就完了，還是基礎組搞的事情。
分工明確
更少的服務代價
這個指的是客戶花銷，也是paas對於傳統軟體的優勢。paas平台一旦做完，他肯定已經有平台了，如果要開發新的功能，可能並不需要占用更多的資源，只是在原有的資源上增加點業務而已。況且paas服務商與客戶更多的是提供服務的續租模式，多乙個客戶少乙個客戶，其實對於伺服器來說並沒有啥壓力，同乙個團隊能夠服務與更多的人。
開發更快
具體點 我們要做什麼
假設我們現在要做乙個人員管理系統，我們一般需要以下內容。
- 增加資料
可以配置乙個或者多個新增資料的頁面，點選儲存就儲存了資料
- 刪除資料
可以配置個按鈕，點選一下就把相關資料刪除掉
- 修改資料
可以配置個按鈕，點選一下出現乙個編輯頁面，裡邊會出現對應的資料，你可以修改，然後點選一下更新，資料就更新了
- 查-- 列表頁面
-- 詳情頁面
你可以在列表頁面點選名稱（點選哪個可以配置）然後，就會自動跳轉到詳情頁面
詳情頁面要展示哪些內容也可以通過配置來進行修改
nocode能力
這個是整個業務的核心，也是paas之所以可以將幾個月的工作量濃縮為數週的原因所在。
其實就是乙個簡單想法的轉變，原本我們要實現我上邊畫的幾張圖，都是考改變**來實現，比如說列表頁面應該是戰士什麼title、列表要不要出現選擇框、列表究竟展示那幾列、右上角究竟有什麼按鈕等等。
現在將這些原本需要寫到**裡邊的邏輯整理到配置裡邊，然後通過解釋這些配置，渲染出頁面，渲染出邏輯。
lowcode能力
當然了，上述的情況太過於簡單了，基本上就是乙個資料庫的內容簡單展示而已，如果我們需要更複雜一點的內容呢？
比如說我們需要輸出這個人的年齡分層（幼兒、少年、青年、中年、老年），我們要怎麼做呢？
很顯然這個狀態不應該被存放在資料庫中的，因為這個實際上是通過年齡動態計算出來的，過一年之後這個展示狀態可能就會過期了，這個時候我們就需要能夠動態插入邏輯根據年齡計算這幾個值，然後輸出結果。
當然這並不是全部了，其他還有很多需要解決的事情。比如
這個玩意有點龐大，一口氣說不完。這次內容就這麼多，我也只能一邊整理一邊寫部落格，這可能會是乙個很長，也可能是做不下去很短的系列。
寫的不好，能力有限多多見諒
從零開始，搭建乙個簡單的購物平台（六）
從零開始，搭建乙個簡單的購物平台 五 專案原始碼 持續更新 在第四篇文章中實現了服務端的檔案上傳以及新增使用者的後端功能，並進行了測試，這篇文章主要實現前端上傳頭像和新增使用者的功能 首先我們引入antd中的檔案上傳元件，並將其封裝到我們的元件中 import react from react im...
從零開始，搭建乙個簡單的購物平台（十）
從零開始，搭建乙個簡單的購物平台 九 專案原始碼 持續更新 拖更時間較長，公司這幾個月專案高峰期，請見諒 這篇文章主要講述後端管理系統新增的訂單模組的部分內容 前端在之前的計畫下稍稍改動，引入了訂單的功能，但不包含支付功能 由於與使用者管理和商品管理稍有不同，所以單獨拎出來介紹一下 對於訂單模組，主...
從零開始，搭建乙個簡單的購物平台（三）
從零開始，搭建乙個簡單的購物平台 二 專案原始碼 持續更新 這篇文章在上次的服務端登入基礎上增加前端介面 在開始前我們可以簡單用postman測試一下token和登入的功能，可以先在後端生成一段token從前端請求 驗證token 成功和失敗 緊接著驗證一下使用者登入 前提事先在資料庫新增使用者資訊...