平台型 Serverless 如何赋能中小开发者?

1 月 7 日的推文中,我有提到,「大公司的 Serverless 想要赢得时间的最佳方案,是通过内部资源的整合,将开发者彻底绑架在自己的平台战车之上」,对于很多人来说,如何理解这种内部资源的整合和它带来的赋能开发者?今天就用小程序 · 云开发最近开放的一个新能力 —— 短信跳小程序为例来聊一聊。

短信跳小程序这个能力其实背后是另外三个能力的组合:

  1. 微信最近开放的 URL Scheme ,我已经在 1 月 9 日的推文中写到了。
  2. 云开发的网站托管能力
  3. 腾讯云自有的短信推送能力

云开发基于上述的两个能力,辅以一些很低的开发工作量,实现了短信跳小程序这个能力。

其中,云开发的网站托管能力和短信推送能力,便是平台型 Serverless 产品内部资源整合而来的。

同样是一个 Serverless 团队要做这样的功能,作为小公司的 Serverless 就会面临:

  1. 短信服务供应商的选择和沟通
  2. 短信签名的审核和提交
  3. 底层代码拉通

但大公司的平台内往往已经自有短信推送的渠道,平台型 Serverless 只需要将底层代码拉通,就可以完成产品能力的对接。

这一点相比于小团队的重新选择供应商等,流程和耗时要少的多,要踩的坑也少的多

平台型 Serverless 团队借助于这样的很多内部能力,就可以轻松实现各种各样的能力,让开发者可以以最低的成本在自己的业务系统中加入产品能力。实际发布给开发者使用的产品,也就变得更加的简单易用。

就短信触达用户而言,云开发将这个能力做到了极简,你需要做的仅仅是将模板代码上传到静态网站托管中,并部署一个配套的云函数,就可以用cloud.openapi.cloudbase.sendSms触达你的用户,剩下的无需你操心,就自动完成了相关的功能。

const cloud = require('wx-server-sdk')
cloud.init()
exports.main = async (event, context) => {
  try {
    const result = await cloud.openapi.cloudbase.sendSms({
        env: 'online-12345678910',
        content: '发布了新的能力',
        path: '/index.html',
        phoneNumberList: [
          "+8612345678910"
        ]
      })
    return result
  } catch (err) {
    return err
  }
}

作为一个云开发的用户,我很期待有更多的同类型功能出现。

你可能感兴趣的