本文由雲+社群發表
2018年12月，騰訊相簿累計使用者量突破1億，月活1200萬，阿拉丁指數排行 Top 30，已經成為小程式生態的重量級玩家。
三個多月來，騰訊相簿圍繞【在微信分享相簿照片】這一核心場景，快速優化和新增一系列社交化功能，配合適當的運營，實現累計使用者量突破1億，大大超過預期。
可是，誰曾想到，這樣一個億級體量的小程式，竟然是一個開發做出來的？他又是有哪般“絕技”，可以一個人撐起一個使用者過億的小程式？
後臺人力緊缺，怎麼辦？
當我第一次見到騰訊相簿小程式的開發David（化名）時，他顯得憂心忡忡。
“年底的目標是要過千萬的使用者，但現在只有幾位前端和後臺開發。不僅如此，我們的後臺開發還不是百分百能夠投入到這個專案，大部分時間要抽身支援其它專案，人力非常緊缺。此外，原有後臺系統有不少歷史包袱，在原有架構上做新的社交化功能開發是不現實的。怎麼辦？
“要不試試'小程式·雲開發'吧，只需要前端就可以把小程式搞起，正好解決我們缺後臺的難題。”
於是，David作為騰訊相簿前端開發團隊的骨幹，擔當起用小程式·雲開發實現騰訊相簿小程式社交化功能的重任。
“第一次接觸到’小程式·雲開發‘時，覺得這個東西（小程式·雲開發）理念挺新穎的———小程式無服務開發模式。在一般的小程式開發中，有三大功能小程式開無法繞開後臺的幫助，它門分別是資料讀取、檔案管理以及敏感邏輯的處理（如許可權）。因此，傳統的開發模式，在小程式端都必須傳送請求到後臺進行鑑權，並且處理相關的檔案或者資料。即使使用 Node 來搭建後端服務，也需要耗費不少的搭基礎架構、後期運維的工作量。”
“而小程式·雲開發則釋放了小程式開發者的手腳，賦予了開發者安全、穩定讀取資料、上傳檔案和控制許可權的能力，其它的負載、容災、監控等，我們小程式開發者只需要關注業務邏輯，專注寫好業務邏輯即可，其他的事情完全可以不用操心了！本來我還一籌莫展，瞭解完’小程式·雲開發‘的產品原理以後，我瞬間心裡有譜了。”
二維碼掃不出來了
道路總是不平坦的 ，在騰訊相簿小程式通往使用者破億的道路上，困難重重。
由於騰訊相簿的二維碼需要帶上的資訊量過大，因此它的二維碼顯得密密麻麻。這種密集的二維碼在某些Android機型下，容易出現無法識別小程式的問題。
這嚴重製約了騰訊相簿小程式分享獲客的能力。
這個事情的解決並不難，只需後臺開發把資料先儲存到資料庫中，然後把資料id放到分享連結上，這樣，連結便可以轉化成32個字元的短連結，讓二維碼看起來沒有那麼密集了。
但由於後臺人力不足，於是前端開發David利用小程式· 雲開發的資料庫儲存能力，通過呼叫db.collection('qr').add介面，快速實現資料在資料庫中的儲存。
此外，騰訊相簿還借住小程式·雲開發的雲函式能力，生成辨識度更高的小程式碼（小程式碼文件），用以在朋友圈裡傳播分享。
2天上線評論點贊功能
騰訊相簿在微信端的核心應用場景是“在微信做分享相簿照片”，為了增強騰訊相簿使用者在微信裡的互動，提升使用者粘性和留存，騰訊相簿決定新增評論與點贊功能，並且把聊天評論就直接在微信聊天視窗裡面實現。
在這裡，騰訊相簿的David面臨了兩個選擇，一是按原開發模式（前臺開發-後臺開發-前後臺聯調）做這個功能，面臨的問題便是開發週期長、缺後臺、迭代速度慢；另一個就是藉助雲開發的能力，擼起袖子自己上。
為了加快產品迭代速度，David決定採取雲開發的開發方式。評論、點贊通過雲開發的資料庫插入和查詢介面，如db.collection('comment').add，很快就實現了。
但遇到棘手的問題是，對於一些敏感的操作比如刪除和編輯評論、點贊這些敏感操作，還需要到使用者的鑑權操作，而這些鑑權資訊，都在原有的後臺。此時，雲函式的路由功能便發揮出作用了。
使用者進行評論點讚的時候，會在小程式端發起請求呼叫雲函式並帶上 openid，雲函式用 openid 查詢原有的後臺服務看看該使用者是否有許可權進行操作，如果使用者具有許可權，則把評論和點讚的資料都寫入雲開發的資料庫中。
就這樣，借住小程式·雲開發的能力，騰訊相簿僅用2天時間，完成了在傳統開發模式下需要1周多工作量的開發工作。
| 原有開發模式 | 雲開發全棧開發 | |
|---|---|---|
| 工作量 | 後臺1周(微信登入態校驗+業務邏輯server開發)+ 前後臺聯調1天 | 1 - 2天，無需聯調 |
此文已由作者授權騰訊雲+社群釋出