微信小程式+web資料庫的開發實踐

前言

生活中使用微信小程式的場景越來越多，它實現了用戶對於應用“觸手可及、用完即走”的理想需求。微信小程式的開發難度也低於APP的開發製作，使用它會更便利、低成本、高經濟效益。

但是要完成一個小程式涉及到的技術棧比較多，要開發的模塊也很多。比如：

1. 微信小程式端的開發

2. 小程式與後端介面的開發

3. 後端管理系統的開發

等等

今天就來介紹下如何使用web 資料庫（此處以kintone平臺為例）+小程式進行整合，實現包括從用戶授權認證，到整個O2O系統的開發。

小程式開發

首先談談小程式的優勢。它對於開發者友好，打破了平臺壁壘，安卓和ios，我們只需要開發一套代碼，就能在各種終端使用。用戶系統互通，都是依賴微信的生態。並且能獲得很多手機的開放能力，包括相機，音視頻等，來實現各種pc端無法實現的功能。

下麵就來詳細說下從前後臺完整實現一個小程式需要做哪些。

1.小程式框架

小程式客戶端的開發主要是使用微信官方提供的開發框架，也可以使用第三方的開發框架，比如uniapp，taro等等。

那為什麼要使用這些第三方框架呢？為了減少學習成本和開發成本！

因為我們的提供的服務往往是多終端的。比如說有小程式，有應用app，有h5等。因為平臺不同，開發語言也會不同，如果這些全部交給獨立團隊進行開發，那成本將非常高。而三方框架就是為瞭解決這個問題。使用一套工具，一套代碼完成多端開發，多端部署。一個團隊就能搞定啦！（理想中的，如果業務不太複雜，的確可以。）

uni-app 是使用 Vue.js 開發小程式的框架。市面上應該有一大半的小程式是使用uniapp來進行開發的。當然不僅是小程式，它還支持 H5、App 等多端開發。因為是基於 Vue.js的語法，加上國內使用vue的程式猿非常多，所以這樣可以減少我們的學習成本。

taro是使用react來進行小程式開發的框架。同樣的，因為react也是非常流行的前端框架，所以也是非常棒的第三方開發框架。

至於大家傾向於哪種框架，大家可以評論告訴我們，哈哈。

2.單純小程式客戶端難以解決的問題

單純只依靠小程式客戶端，還是有很多問題需要面對。

1. 每次業務的修改代碼都需要發佈一個版本。

   如果我們把業務的處理封裝成介面放在服務端後，只要介面的參數不變，我們都不需要進行小程式的重新發佈。

2. 無法獲取一些微信的能力，比如授權獲取用戶手機號。

   這些都是需要在服務端先通過獲取access token，再去調用微信的api去獲取用戶手機。像這種請求，都是不可以在客戶端完成的。或者說是不安全，且受限的。同時像業務邏輯的處理之後的數據落地，也需要在服務端進行。

3. 客戶端的運算能力有限。

   一些計算型的業務放在服務端比如ocr識別，ai語言模型的調用等等，使用服務端強大的算力來解決，加快運算速度。

所以一個功能完整的小程式開發一般還是需要用到中間的小程式服務層的。

3.小程式服務端開發

服務端開發可以使用雲原生的方式開發也可以使用自建伺服器進行開發。

其中unicloud（也是uniapp這家公司的）它提供了一個叫服務空間的解決方案。就是一種雲原生的開發方式。它依托雲服務商提供了一套雲端nodejs的運行時環境，還提供了對象存儲、mongodb資料庫、redis緩存資料庫等等。

然後雲服務商你又可以自行選擇阿裡雲，騰訊雲等。相當於原本你需要一個個配置的服務幫你打包賣給你，然後又提供了完整的介面去連接這些雲服務，從底層抹平了雲服務廠商間的差異。

事實證明，這套下來還是省去了很多開發成本以及雲原生開發的學習成本。當然如果你想使用其他語言進行後端開發，比如java、python、php等，那你也可以使用騰訊的雲托管，通過docker來進行部署。而uniapp+unicloud的開發相當於你只使用js來實現全棧的開發。

kintone的角色

在小程式開發之前，我們需要先實現一個後臺系統，或者叫後端的開發。

拿kintone開發社區小程式舉例。我們的開發社區小程式做了“每日一題”、“活動報名”、“積分商城”等功能。 在這個系統中存儲的數據部分來自於用戶，還有部分數據則來自於系統本身的運營。比如系統運營人員通過後臺添加活動，添加的每日答題等等。

所以我們希望通過後端完成以下工作：

• 資料庫的設計

• 後臺管理系統

• api介面的開發（供雲函數調用）

以此簡要說明下kintone的能力和定位。 我們逐個進行分析。

1. 首先是資料庫設計，我們需要根據業務需求，設計資料庫的結構，kintone通過拖拽就能實現。資料庫中常見的外鍵，也能通過lookup實現。

2. 然後是後臺系統的開發，我們需要根據業務實現包括且不限於增刪改查等等這些功能。而在kintone中我們在通過拖拽生成應用後，會自動實現增刪改查這些功能。其次是平臺自身能力。平臺系統本身也需要自己的用戶表，許可權表等等來滿足運營人員的管理。

3. 最後是通過api提供對外開放的能力，kintone提供rest api介面，提供包括各種語言的sdk，包括js、java、python、php等。通過這個介面我們就藉助雲函數實現數據和小程式的雙向流動了。

傳統開發，需要開發的東西非常多，成本大大增加。而kintone不僅提供了上述能力，還提供了流程審批，數據統計等等附加值業務。

案例分析

下麵我們以一個簡單的O2O系統的雛形為例，來講下小程式的開發。

1.登錄

小程式開發最基礎、通用的功能：登錄。做任何小程式想要識別用戶，第一步就是需要實現使用小程式登錄。也就是通過識別進入小程式的用戶。

如何實現識別用戶？

這部分包含2個部分：

• 小程式中用戶的唯一標識 open id 

• 授權獲取用戶的手機號

open id是小程式中的用戶的唯一標識。其實通過它就能實現用戶的自動識別與登錄。但是光有用戶的open id 往往是不夠的，為什麼呢？因為很多時候我們的系統是多端的，而pc端無法獲取用戶小程式的open id，所以並不能用它來區別用戶，所以往往還需要通過授權獲取用戶手機號這種做法來區別用戶。

2.微信服務認證 access token

但是想要獲取手機號，光授權還不夠，還需要配合服務端進行一些開發才能實現。它需要先通過小程式的appId、appSecret來獲取微信服務的access token，然後通過access token令牌來調用api獲取用戶手機信息。

access token如何保存？

access token的過期時間一般是2小時，而且官方也建議大家在token有效期內對這個access token進行緩存。所以一般的做法都是先存入redis，並且設置expire時間。每次要執行微信的api前先在緩存中獲取token，如果不存在就先去獲取access token並且存入緩存中。

在unicloud的開發中，他們的服務空間提供了另一種方法，就是通過使用定期觸發器，在token過期的時間內（比如說2小時）定時獲取token並且保存在redis中。這樣免去你在應用邏輯中遇到token過期，再去取token的情況。節約請求時間。

當然你也可以通過kintone來存儲token。（只需要設置過期時間，註意瀏覽許可權）

3.授權能力

除了授權獲取手機號，通過用戶授權還能獲得更多能力。比如常見的用戶的地理信息、通訊地址、發票信息等。這些都可以通過授權方式來獲取。不過這裡有些坑需要註意，授權的介面經常會做調整，比如之前常用的獲取通過wx.getUserInfo獲取用戶頭像昵稱的能力現在在新創建的小程式中已經無法使用了。

4.小程式客戶端與服務端之間的身份認證

我們不能每次發起請求就要跳一次登錄，所以需要將登錄狀態轉化為服務之間的身份認證。

小程式客戶端和小程式服務端的身份認證該如何去做呢？這塊可不是微信幫你做好的，需要你自己去做。

常見的身份認證方式還分兩種：

1. 一種是有狀態的身份認證，比如說session認證。
   session是需要在服務端保存的。會耗費服務端資源。

2. 還有一種是無狀態的身份認證。比如說jwt token。
   jwt token則是一種去中心化的認證。它通過非對稱加密來實現。所以不需要伺服器。

這兩者區別今天就不做展開分析。因為比較複雜。今天我們就主要以jwt  token認證來講講小程式如果使用它來做身份認證。

jwt 優點很多，去中心化、無狀態、不需要服務端存儲，只需要每次請求都在頭部中帶上認證信息。不過他也有個缺點，token如果泄露，你無法讓他失效。

我們可以使用一些用戶的信息（用戶名）通過私鑰來生成jwt token，以後小程式端每次只要帶上這個token就能實現身份認證了。

具體我們通過微信官方的圖來做一個解釋說明

小程式登錄 | 微信開放文檔 (qq.com)

微信登錄的流程是通過wx.login()來獲取用戶的open_id，其中open_id就是你在這個小程式中的唯一用戶id，可以用它來識別用戶。

身份認證信息如何使用？

在小程式端，一些需要身份認證的畫面，發起請求時都會帶上token。然後在雲函數端會對token校驗，如果校驗成功則去kintone發起rest api請求獲取數據。失敗，則返回報錯信息。

如果服務端不做認證的識別，那請求很容易被偽造。以一個業務請求舉例，比如參加活動、答題等請求。請求參數是用戶id、積分。那你只需要偽造這個請求，帶上這個用戶id和偽造一個很大的積分，如果服務端不加識別就接受，是不是這個用戶的積分就能被隨意篡改了？

5.refresh token 機制

此時我們發現只用access token來進行用戶身份認證會遇到一個問題。如果把token時間設置的過長，那就有token泄漏的風險。而你又無法主動將客戶端的token失效。（除非服務端將jwt  token持久化下來，然後主動讓他失效。但是存儲下來這就違背了jwt token去中心化、無狀態的設計初衷了）。但你將token時間設置的過短，則會出現用戶需要頻繁登錄的問題，影響用戶體驗。此時我們經常會採用access  token + refresh token的方式來進行驗證。具體是怎麼做的呢？用一張圖來做解釋，其實這也是淘寶、京東這些客戶端如何實現永久登錄的一個方法。

此時，根據refresh token的失效時間，只要在失效時間段內登錄，比如每周、每月登錄一次，就能換取新的access token和refresh token。這樣就實現了永遠登錄狀態。不需要重新登錄了。

最後是token的客戶端保存。我們需要用到手機端存儲storage。但是每次進入小程式，都需要從storage中取出token，然後將token放入全局狀態管理（vuex或pinia）。以便每個頁面都能判斷用戶登錄狀態。所以推薦使用小程式上的一個pinia持久化插件”pinia-plugin-unistorage”，通過它可以實現小程式初始化時會自動從storage中獲取，而數據更新時，又會自動同步到storage中。保持了數據在storage和pinia中的一致性。

6.小程式服務端框架

在小程式端向服務端發起請求時，服務端身份校驗的這部分代碼可以以中間件形式的方式進行開發。在小程式端也有類似koa的分層開發框架。（koa是nodejs端常用的web開發框架）比如uni-cloud-router，可以實現mvc方式進行開發，同時它也提供了中間件的方式，可以用它來實現用戶身份認證，許可權校驗等功能。

7.簡單的O2O系統設計

剛纔我們講了我已經通過微信授權獲取到了用戶的手機號，同時也通過自己設計token實現了小程式端和服務端的認證連接，那接下來的就來設計一個實例，如何開發一個小程式來實現O2O功能。O2O大家應該很熟悉，比如在抖音、大眾點評上進行團購、線上消費、生成二維碼、線下商家掃碼核銷買單等。今天我們拿類似的功能做類比。比如：

• 通過小程式進行線上報名參加學習會，報名後返回一個參會二維碼。

• 參會那天，工作人員可對此二維碼進行掃碼核銷。

• 核銷後，自動給此小程式賬號增加積分。

• 後期可以進行積分兌換獎品。

那我們分析下，要實現這樣的功能有哪些要做的，又有哪些註意點呢？

首先通過例圖來分析我們需要做什麼？

8.kintone應用構建

接下來我們需要在kintone上進行應用的設計，相當於傳統開發中的資料庫設計：

1.  用戶表：用來存儲小程式端授權登陸的用戶。 

2. 活動表：管理員可以通過增刪改查上線一些我們的學習會。  

3. 活動參與表：用戶的報名數據被記錄到這張表裡。

4. 積分表：記錄用戶的積分。用戶報名成功，以及參加活動後後臺核銷成功都會更新積分。

5. 積分變更履歷表：來跟蹤用戶所有的積分變化。這樣出現程式問題或者惡意漏洞，被修改積分時，做到有跡可循。

其中活動參與表、積分表，都可以設計一個lookup欄位來和用戶表進行微信openid的關聯。實現外鍵的關聯。

這幾張表通過簡單的拖拽就實現了。

​

小程式開發中常用插件及用法

更多代碼參考：微信小程式+kintone的開發實踐 

​