「如果能快速産出不同類型的活動且這個過程不需要開發參與，完全由營運或PM獨立完成小程式營運活動的建立，是營運PM與開發共同的願望。」
近年小程式逐漸流行起來，各公司為吸引更多使用者來使用其公司小程式，越來越多營運活動的開發成為常見的場景和趨勢。
作為第一批開發微信小程式的我司——貓眼電影，如今使用者量與日俱增，基于小程式營運活動的需求也随之增長。
『 以下對話改編自真實案例 』
營運&PM：春節快要到了，我們能不能複用一下之前七夕的活動？這次活動頁面的顔色，頭圖，tab文案，提示文案等統統都要換。還有我們希望改版一下這裡的排版，再加一個xx功能，首頁再加一個xx提醒，這個活動之前做過，這次我們複用的話很快吧？明天能上線嗎？
前端開發：......這個活動之前沒有說過要複用，是一次性的，我們如果這次還想上這個活動，需要前端來改動代碼，将你說的與之前活動不同的地方（顔色，頭圖，文案等等）在代碼中更換掉。你說的xx功能和這個xx提醒是需要後端開發來支援的，我們相當于是在原有頁面的基礎上二次開發，而且後端也有開發量，需要拉上後端一起來評估一下，明天上線是不可能的！
營運&PM：這個需求很簡單，怎麼實作我不管，明天上線！
前端開發：......
『 活動複用之痛 』
之前某些一次性的活動，由于效果較好，會被要求再次複用。
「如果每次都在原有活動基礎上改動代碼及一些配置并重新上線顯然是浪費人力且不可持續的」而且事實證明，每次這種被要求再次上線的活動，除了改動一些本次活動相關的圖檔文案之外，往往還需要增加額外一些“簡單”優化和功能。
「為了複用這種活動，活動模版化便被提上了日程。」
如果采用傳統的解決方案：在已有B端系統，添加該活動配置項，同時需要後端開發接口将活動配置項存在資料庫中，而依賴後端會有一系列問題産生。
1. 後端資源緊缺，時間成本高
這種與主流程不太相關的需求通常優先級比較低，如果後端無法及時配合上線時間很難保證。前後端聯調的時間成本也是比較高的。
2. 不靈活
前後端PM需要溝通協調配置項的問題，一旦确定可配置項都有哪些，表結構确定之後就難再輕易改動，如果有需求的變更需要PM和前後端讨論并周知到前後端相關開發人員，改資料庫改前後端代碼，費人力費時間。
3. 需求與後端關系不大
活動模版化存儲的活動配置項資料與後端其他邏輯幾乎無關聯，隻是為了配合前端而做的簡單存儲，存儲在後端就意味着後端要為前端提供增删改查的接口。後端心理上也比較排斥這種與後端其他業務邏輯毫無關聯隻是為配合前端而做的需求。
『 如何用雲開發解決活動複用之痛 』
為解決活動複用之痛，正值小程式雲開發剛剛推出，這種serverless的開發模式正好是我們做活動複用所需要的，何不用雲開發來幫助我們解決這個問題呢？
于是，我們建立了一個「小程式營運工具」（代号：唐圖）的背景管理系統項目。
「營運可以通過唐圖進行活動資料、狀态管理，如：建立、編輯、檢視、删除、上線、下線、置頂、設為模版等操作」
前端開發根據不同的活動類型為營運提供不同活動模版（目前為前端根據營運PM的需要設計可配置項模版的表結構并存儲在雲開發的雲資料庫中，之後計劃開發為營運提供可視化配置可通過拖拽模版元件動态生成活動模版，同時活動資料的編輯也将提供可視化編輯功能）。
唐圖産生的活動資料、活動模版資料、權限/身份資料等涉及到圖檔檔案與文字資訊的存取，是以使用了小程式·雲開發的「資料庫」能力與「存儲」能力，使用小程式·雲開發的Node端SDK支援該背景系統。
『 小程式端的模版化 』
「小程式營運工具」中産生的每個活動資料，都有活動類型與活動id辨別，小程式端通路該活動時帶上必要參數在小程式端通路雲開發的雲資料庫拿到對應活動配置資料來渲染頁面，即實作了使用一套模闆建立不同活動的目的。
『 問題、思考與解決方案 』
當然在通過小程式·雲開發實作唐圖使用的過程中，我們遇到了一些值得思考的問題。以下給大家分享一下我們的經驗：
1. 不同環境資料存取政策
當開發一個新活動模版化時，小程式開發版将使用雲開發test環境，線上版将使用雲開發prod環境。
1.1 資料的存取
唐圖線上的活動配置項由營運來配置，如果線上配置的活動配置隻在prod環境存儲的話，意味着小程式開發版将拿不到活動配置項資料，然而開發需要驗證不可能等到上線之後。是以唐圖中儲存政策在考慮後确定為：會将資料同時儲存到兩個不同環境中，這樣線上線下的配置項資料可保證為一緻利于開發與測試。
1.2 圖檔的存儲與使用
唐圖中很多活動配置項為圖檔檔案，上傳檔案即時上傳并傳回fileid。通過fileid拿到圖檔的連結，存儲配置項字段時将包含圖檔資訊的object（fileid和url）存為value。
小程式雲中如果權限是私有的，url會是臨時的url，如果權限是公開的（所有使用者可讀）url不變。我們的活動配置權限設定為公開資料，url不變，是以此處我們将圖檔url直接存入資料庫中以供小程式使用
「小程式雲上的存儲管理也是按照環境隔離的。」如果也按照資料的存取政策來執行，将同一份資料上傳到不同環境，圖檔資料會變得很備援，且沒有必要，是以決定上傳圖檔隻存儲到prod環境，傳回的連結儲存在兩個不同環境的資料中。
調用上傳檔案接口之前必須要轉譯一下檔案名，因為檔案名将直接作為圖檔連結的一部分。如果檔案名包含漢字或特殊字元且沒有被轉譯可能導緻上傳失敗，或是生成的連結不可用（如果該圖檔是分享給好友時的分享圖，帶有漢字連結的圖檔将在分享的時候不可用）。
在上傳之前先查找一下有無與目前檔案名相同的檔案，如果有需将該檔案拼接一些随機字元串再上傳。或不查找檔案，直接用随機字元串替換掉之前的檔案名。（但我們需求場景該檔案名也許有含義是以沒有直接替換掉）。
2. 使用短連結生成貓眼小程式碼
在活動可定制化之後，營運可以自己生成活動了！但是生成完活動之後，營運同學需要投放該活動的入口，不清楚目前活動的連結位址與對應的小程式碼，還需要找前端同學提供。
我們預料到了這種情況在唐圖事先添加了個可檢視連結和小程式碼的功能。
使用的是getWXACodeUnlimit api生成小程式碼，這種小程式碼的優點是永久有效、數量暫無限制，但是所傳遞的參數scene最大為32個可見字元，scene參數需要傳遞的資訊至少包括活動id與活動type，當時實作該功能時小程式雲資料庫預設的_id辨別長度為20位，參數長度總和勉強沒超限，但是也隻能支援掃碼進入目前活動頁，如果想實作先跳轉到貓眼小程式首頁再跳轉到活動頁（目的是希望使用者可以傳回到小程式首頁）這種需求就顯得力不從心。
為解決這個問題，我們利用雲開發的雲資料庫，存儲了活動連結（長連結）并傳回新增這條資料後小程式雲生成的唯一辨別_id，隻将_id作為參數當作scene字段的值。
存儲在雲資料庫中的資料如下：
但不久後就發現出現了新的問題，通過唐圖調用小程式雲的Node端SDK存儲長連結傳回的唯一辨別_id從原來的20位變成了32位！我們才意識到原來這個預設_id位數是有可能會變化的，是不可以依賴預設_id作為該場景下（嚴格要求位數）使用的。我們通過在Node端生成随機字元串并在建立資料時将該随機字元串指定給_id而不是使用預設的_id。
這個功能非常實用，上線後，營運再也不用來問前端：“xx情況下的路徑應該填啥”“求生成一個小程式碼”。
『 雲開發讓營運活動需求不再難以實作 』
目前已實作最常用活動模版化，并自唐圖一期上線以來（2月初上線）至今（5月初）已支援5個線上活動，收益顯著。
對于營運來講
「想上就上」同類型的活動上線不再需要開發，建立一個活動的複雜度降低，效率大幅提高。
「想改就改」營運可随心所欲通過唐圖建立并修改活動資料。
「想在哪兒上就在哪兒上」營運可以通過唐圖檢視目前活動的小程式連結及目前活動的小程式碼（用于入口投放）
對于開發來講
「前端開發啟動活動模版化不再依賴後端，面對模版化時随時可能被新加入的新字段或新功能，也能從容應對」小程式·雲開發的雲資料庫基于mongo，自己就能改表結構而且代價不大，如果改動頻繁也可以自己先mock一個json，等穩定了再将json檔案上傳到資料庫，so easy！媽媽再也不用擔心我的加班！
「後端開發擺脫苦海」後端不再需要配合前端做這些改來改去無聊的存儲工作，有時間去做更重要的事了！
「解放QA」模版化後的活動，隻需要模版化後的第一個活動需要測試，以後就不需要再無休止的測試同個活動啦！
模版化後的活動無形中限制了營運針對每次活動的「定制化的」「僅使用一次」的修改，如果改模版将更加慎重的考慮今後的複用性，減少了腦洞大開或抽風的奇葩需求産生的機率！
借力雲開發，貓眼在活動模版化和可定制化方面已經初見成效，小程式方面抽象出獨立的活動插件項目并在小程式插件中使用雲開發來完善我們的活動可定制化項目也已在規劃中。也希望雲開發能推出更多好用的服務，服務更多的前端開發人員。