「如果能快速产出不同类型的活动且这个过程不需要开发参与，完全由运营或 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」**模版化后的活动，只需要模版化后的第一个活动需要测试，以后就不需要再无休止的测试同个活动啦！
模版化后的活动无形中限制了运营针对每次活动的**「定制化的」「仅使用一次」**的修改，如果改模版将更加慎重的考虑今后的复用性，减少了脑洞大开或抽风的奇葩需求产生的概率！
借力云开发，猫眼在活动模版化和可定制化方面已经初见成效，小程序方面抽象出独立的活动插件项目并在小程序插件中使用云开发来完善我们的活动可定制化项目也已在规划中。也希望云开发能推出更多好用的服务，服务更多的前端开发人员。