Taro團隊攜手雲開發搭建電商後臺服務

原創： 京東凹凸實驗室

本文從Taro及小程序·雲開發的簡介開始，介紹瞭如何經過小程序·雲開發搭建電商後臺服務，最後再深刻地闡述購物車頁，訂單頁的小程序·雲開發端處理邏輯，由淺入深地剖析了使用小程序·雲開發開發電商後臺服務的整個過程。

Taro簡介

Taro是由凹凸實驗室開源、遵循 React 語法規範的多端開發解決方案，截止目前 star 數已經突破16.9k，受到了前端開發者的普遍關注，成爲了當前最受歡迎的小程序多端開發框架之一。

Taro 目前已支持微信小程序、H五、RN、支付寶小程序、百度小程序以及字節跳動小程序，持續迭代中的 Taro，也正在努力兼容更多的端，並增長支持一些新特性。

小程序·雲開發簡介

先看官方文檔的說法：

小程序·雲開發是微信團隊聯合騰訊雲團隊推出的一套小程序開發解決方案。小程序·雲開發爲開發者提供完整的雲端流程，弱化後端和運維概念，開發者無需購買和管理底層計算資源，包括服務器、數據庫、靜態存儲，只需使用平臺提供的簡易 API 進行核心業務等開發，實現快速上線和迭代，把握業務發展的黃金時期。

其實翻譯過來就是，一個在小程序中使用的，不用購買服務器，不用運維的簡易後端體系，主要是爲了突出快和簡便。因此小程序·雲開發，就很是適合那些對數據自己弱依賴的，中小型的功能性小程序使用。

小程序·雲開發主要有幾大部分組成，分別是雲控制檯、數據庫、雲函數、雲存儲。以及分別在小程序端，和雲端使用的 js-sdk、admin-sdk。關於這幾部分的具體內容，能夠在官方文檔中查看。

而與傳統的電商後端開發相比，小程序·雲開發有如下區別：

​	傳統電商後端開發	小程序·雲開發
後端代碼	自主編寫、開發接口	開發接口，雲函數部署
服務器	自主購買、部署	無
數據監控	自主搭建	官方提供，控制檯查看
調用日誌	自主搭建	官方提供，控制檯查看
費用	服務器購買成本	無

項目結構

由於該項目使用了小程序·雲開發進行後端開發，故項目結構會有些不一樣。具體結構使用的是 Taro 初始化時提供的雲開發模板，大體結構以下：

├── demo                          代碼目錄 |   ├── client                    小程序代碼目錄 |       ├── ...            |   ├── cloud                     小程序·雲開發相關代碼目錄 |       ├── functions             雲函數相關目錄 |           ├── shop              shop 雲函數目錄 |               ├── index.js      入口函數 |               ├── getShop.js    getShop.js |               ├── package.json |               ├── ... |   ├── project.config.json       小程序配置文件 |   ├── tcb.json                  小程序·雲開發配置文件 └── README.md                     readme 文件

能夠看到目錄裏主要分了兩大塊 client和 cloud：

client 裏和咱們日常小程序的開發目錄，存放的都是小程序裏業務代碼。

cloud 裏則是放雲函數相關的代碼，而且是以模板進行分割，每一個模塊一個雲函數。

基於這樣的目錄結構，小程序·雲開發相關的代碼與小程序自己的代碼進行了有效分隔，極大地方便了項目的管理與開發，同時也有助於雲函數的上線部署。

經過小程序經過小程序·雲開發搭建電商後臺服務

介紹完 Taro 及小程序·雲開發，下面便開始講解如何經過小程序·雲開發搭建一個後端服務。

1.後臺服務搭建思路 2.數據庫創建 3.數據交互 4.【首頁】【商詳頁】後端邏輯處理 5.【購物車】後端邏輯處理 6.【訂單頁】後端邏輯處理

後臺服務搭建思路

首先，咱們知道一個最簡單的後端程序就是，開啓一個 HTTP服務，鏈接上數據庫，而後根據收到的請求進行相關操做，例如數據庫的增刪查改，返回 HTML，返回接口數據之類，若是要知足外網訪問還要部署上線等等。

而用上了小程序·雲開發以後，由於雲函數這個概念，咱們免去了開啓服務器和部署的步驟。同時，小程序是自然先後端分離的，也不須要返回HTML。因此在這種狀況下，咱們所搭建的後臺服務最主要爲了實現兩個部分的內容，分別是數據庫的創建和先後端的數據交互。

1.數據庫創建

數據庫創建，指的是數據集合及一些初始數據的建立。在咱們搭建的這個 Demo 裏，主要有如下數據集合：

• Information - 首頁的資訊數據集。主要是以一個資訊爲單位的數據集合，一個資訊可能含有商店圖片，商店介紹，商品介紹等，主要做導購做用，點擊後引導至相關頁面。
• Shop - 商店頁的數據集。以商店爲單位，一個商店頁面裏主要是各類樓層數據。
• Commodity - 商品的數據集。顯然，一個商品數據天然就是該商品所須要的各類信息。
• Cart - 購物車的數據集。以用戶爲單位存放購物車數據。
• Order - 訂單的數據集。以用戶爲單位存放訂單數據。
• User - 用戶信息的數據集。存放用戶信息數據。

上面所講述的 6個數據集，基本就涵蓋了一個最簡單的電商所須要的各類數據，能夠構成一個完整的購物流程。

同時以下圖，還能夠設置數據集權限。例如將 Information、 Shop、Commodity設置爲全部用戶可讀、僅管理員可寫；將 Cart、 Order、 User改爲僅建立者及管理員可讀寫。經過權限限制，加強了數據集的可靠性。

2.數據交互

數據集創建起來後，再往裏面填充一些假數據，基本的數據就有了，那麼在小程序中如何進行數據交互？

若是不是用小程序·雲開發，天然是經過request拉取接口數據，進行展現。而在使用了小程序·雲開發的狀況下，經過官方提供的 sdk，主要有兩種辦法進行數據拉取：

1.直接在小程序端操做數據庫，獲取所需數據，並進行增刪查改等操做。 2.使用雲函數，把數據庫的操做放到雲端；而後在小程序端調用雲函數，達到相似調用接口的效果。

第一種方法其實比較適合一些簡單的、對數據要求不高、量也不大的小程序。否則在小程序的代碼中混合着數據庫操做，實踐起來不太優雅，也不利於維護。

這裏重點說下第二種方法。上篇文章有提到了雲函數的概念，這裏再回顧一下。所謂雲函數，就是將一個函數放在Node.js（即服務端）環境下運行。所以，咱們能夠將數據庫的操做放到雲函數中執行，而後在小程序中調用雲函數，達到一種相似調用接口的效果。回顧咱們上一章節說到的雲函數的目錄：

├── demo                          代碼目錄 |   ├── cloud                     小程序·雲開發相關代碼目錄 |       ├── functions             雲函數相關目錄 |           ├── shop              shop 雲函數目錄 |               ├── index.js      入口函數 |               ├── getShop.js    getShop.js |               ├── package.json |               ├── ... |   ... └── README.md                     readme 文件

名字叫 shop 的雲函數的具體目錄在cloud/functions/shop下，能夠見到有一個入口文件 index.js，還有其它的子函數。下面看具體代碼：

在這個例子中，筆者將一個雲函數當成一個模塊相關函數的入口，根據函數傳入的參數來決定調用哪一個函數。而被具體調用的函數，執行的是一些數據的操做，而後返回數據。也就是說，在這個 Demo 裏一個雲函數是一個數據模塊的入口，裏面引用了許多待被調用的具體函數，視入參而定。

以數據模塊爲單位分割雲函數，是筆者以爲比較好的作法。一來雲函數沒必要分割得太細，畢竟每一個雲函數都是獨立部署的，省去了一些繁瑣的操做；二來以數據模塊爲單位，就有點相似咱們傳統後端的 MVC 模式，易於開發者無縫接入。固然，這只是其中的一種雲函數代碼組織方式，並不表明就必定要遵循這樣的方式，具體狀況具體分析，仍是要結合業務的實際狀況。

而具體到小程序的調用，就更簡單了，只是將請求接口的操做改成調用雲函數的操做。好比：

能夠看到，僅僅是將調用 wx.request改成了調用 wx.cloud.callFunction，其它的地方並不須要改變太多。返回的數據也是能夠本身定義的，達到了與調用接口相同的效果。

不過雲函數有一個缺點，就是每次都要上傳部署後才能被小程序端調用，調試起來略顯麻煩。一個比較好的調試方法是添加一個測試函數，在本地環境中使用 Node.js 進行測試。

2.1【首頁】【商詳頁】後端邏輯處理

通過上一段落的講解，相信你們對於整個商城後端服務的搭建與處理邏輯已經有了基本瞭解。下面咱們看一下首頁和商詳頁的頁面結構。

首頁：

商詳頁：

實際上，上一段落中所舉例shop雲函數，即是處理首頁和商詳頁的後端邏輯。能夠看到，其邏輯只是簡單的根據id拉取數據並返回，由於總體也並無過多與用戶發生交互的部分，也沒有須要後端邏輯處理的部分，總的來講仍是比較簡單的，在這裏便不做過多介紹。

2.2【購物車】後端邏輯處理

購物車頁相較於首頁和商詳頁，其邏輯一定是複雜了不少，下面結合頁面結構及代碼分析一下。

上圖是商城demo的購物車截圖。能夠看到在購物車裏，小程序·雲開發端須要處理的邏輯有商品的選擇與反選、商品刪除、商品數量的更改、商品型號的更改等等。所以，咱們把購物車操做分類，獲得以下一個 map：

而後，在用戶執行相應的操做時，咱們便會執行到對應的操做函數：

在這裏，每一個操做函數的入參都是 oldCartInfo（舊的購物車裏的商品）、 skus（須要更改的 skus 數組）。而後返回處理後、最新的 newCartInfo （新的購物車裏的商品）。具體的操做函數的邏輯咱們便再也不闡述了，主要就是對數組進行遍歷而後根據相關操做處理數據。

接下來，根據最新 newCartInfo，來獲得完整購物車數據，完整的購物車數據結構以下所示：

更新完數據庫後，便會返回給前端最新的購物車數據。

總結下來，整個購物車後端邏輯的流程，能夠用以下的流程圖描述：

若是後續有新的購物車操做須要迭代，或者處理邏輯須要變動，咱們也只須要改變小程序·雲開發端執行函數 這一部分裏面的內容便可。

2.3【訂單頁】後端邏輯處理

一樣的，咱們先看一下訂單頁的結構。

訂單詳情頁：

訂單頁這塊主要處理的是生成訂單的邏輯。每一個用戶的購物車中，已勾選的商品數據都是存放在數據庫中的，因此當用戶點擊了去結算按鈕，觸發告終算請求時，後端會直接從用戶數據庫中的購物車數據，生成一份訂單。詳細的流程能夠用以下的流程圖描述：

下面咱們來看具體代碼：

從代碼中能夠看到，先是遍歷當前購物車中的商品，而後把已經勾選的商品存放到 payInfo中。接着根據 payInfo 生成訂單數據，同時除移購物車中已被結算的商品，並更新購物車數據庫。

總體來講，並無太複雜的操做，不過須要注意的是，由於存在不少異步的操做，因此會有使用不少 await 命令來進行同步書寫。

除了生成訂單以外，還有取消訂單、刪除訂單等操做。相較於生成訂單，這些就只是讀取訂單、更改狀態而已，便不贅敘。

總結

筆者做爲開發者，使用小程序·雲開發後，深感其便利性。私覺得有如下幾點優點：

• **便捷。**略去了後端部署、運維等步驟，能夠快速地構建所須要的後端應用，很是適合靈活輕便的小程序開發。
• 免費。目前小程序·雲開發提供了免費 2GB 的數據庫存儲和 免費 5 GB 的文件存儲，雖然存儲量並非很大，但對於我的開發者來講，這些存儲量綽綽有餘。
• 開發簡單。小程序·雲開發的使用，雲函數的開發都是很是簡單的，官方提供的API可讓咱們便捷地進行操做。只需掌握 JavaScript 和一些異步處理相關的知識，即可以快速上手。
• 一致性。小程序·雲開發是小程序官方推出的一種解決方案，與正常的小程序開發無縫鏈接，並且不用擔憂是否會繼續維護、升級迭代等的問題。

最後但願這篇文章對於看完的你有所幫助！