如何迁移、或兼容微信云开发云函数？

[maslow]

引用微信云开发用户的需求：

要是能兼容两边的接口就好了，我们也可以只维护一套代码，想用wx云开发、laf的都可以

这个帖子目的是收集和讨论，如何更便捷的迁移甚至兼容微信云开发的代码，罗列关键点、讨论可行性，集思广益。

当前两者主要差异在什么地方？

[djun]

个人感觉微信魔改过的那套还是有点奇葩，建议尽量兼容开源项目中的用法，比如Laf使用了MongoDB做云数据库，那么db操作直接跟MongoDB的兼容就可以了（也可以另外加一套ORM的，以后可以支持其他类型数据库作为“云数据库”，感觉会更好）

[maslow]

有道理，当前 laf 云函数中是可以直接使用 MongoDb API 的（cloud.mongo），提供100% mongo 原生API。
laf 也同时提供了类微信云开发的ORM（cloud.database()），这个主要是给前端访问库使用的， 在 laf 中其实这个 ORM 已经支持了 SQL 的转译。

[shenghanqin]

微信云开发的云存储该如何迁移呢？

[maslow]

微信云开发 有没有提供 导出文件的功能？

[maslow]

laf 云函数的接口和 微信云开发 差异：

1. 云函数入参不同
2. 数据库操作 ORM 入参也有一定区别，如 update ({ data: {} }) 接口 wx 是多了一层 data 字段
3. wx 深度绑定了 auth / openid
   等等

如果修改 laf 现存接口，会影响 laf 现有应用，同时兼容两种接口 情况比较复杂，也会影响 laf 接口的纯粹性。

一个比较容易接受的方式是， 专门为微信云开发 提供一个 runtime（app-service），比如名为： app-service-tcb，
开发者在创建应用的时候，可选择不同的 runtime。

这样可延伸到 laf 的架构调整问题—— laf 支持多 runtime 的方案，如：

• app-service-nodejs （default）
• app-service-tcb
• app-service-golang
• app-service-java
• app-service-python
• app-service-deno

这个架构应该是可扩展的，在私有部署 laf 的场景下，用户还可以使用自己定制的 runtime。

后面这部分内容可参考：#178

[yenche123]

直接交由社区实现🙉 https://github.com/yenche123/all-serverless