所谓的不用写服务器代码了！老哥们是怎么看的？

[king888]

https://uniapp.dcloud.io/uniCloud/clientdb
https://uniapp.dcloud.io/uniCloud/schema
https://gitee.com/dcloud/opendb

其实就是 uniapp 推出的一套开发规范跟开发解决方案？有没有开发体验过的老哥，聊下使用情况，这是巨坑还是真香？我不知道，只知道这是真的 all in js 啊，对前端能力要求是越来越高，看了下文档，感觉学习成本也蛮高的，整熟他们的规范，然后在 json 文件定义权限、校验逻辑，如果遇到那种上百个表的业务，每个集合整一份 json，不敢想象，不敢想象 \狗头

[miv]

如果想云开发，建议小程序那一套不要 uniapp 。

[Felldeadbird]

理念上来说没毛病呀。传统模式还要多请一个 后端来做数据层。既然前端层可以确保（渲染后）业务安全，那么直接前端来操作 DB 也没什么问题呀。

唯一不好就是，这种深度绑定的工具，性能调优如何？还要和平台深度绑定………只怕后续业务升级，调整 成本剧增。可以参考一下 各种云服务业务。 一旦深度绑定了，你用 5 年前的配置，续费时结果可以买几份新的配置了。。

[muzuiget]

巨坑，反正这种开发方式我是不敢用的，把一些东西变黑箱，再说，谁说服务端只是写数据库？

[zhbzhbzhbz]

这个很早就有啊，算是 BAAS ？比如 Leancloud，几年前就是用 JS 操作云端的数据库了。

[zhbzhbzhbz]

补充，leancloud： https://leancloud.cn/docs/leanstorage_guide-js.html 很早的技术

[msg7086]

你确定不是仅仅把服务器代码搬到了前端？
该写的逻辑不还是要写么。

[Valid]

如果你想你的所有东西所有权在别人手中的话

[dayeye2006199]

看着和 firebase 和 parser 像

[wulin]

产品经理呵呵一笑，提了个需求

[auin]

莫非没搞过“真正的”需求？ 稀奇古怪的对接和产品需求能把这些云 API 打出 shi

[winglight2016]

基本上，现在的低代码、无代码平台，还不如代码生成那一套靠谱，至少代码还能改，这玩意一碰到坑就是没法解决，谁敢用啊

[watzds]

很多年前就有

[hehezhang]

说真的，实际业务真的能和架构设计完全分离？我是真不信

[agee]

parse-server 比这个香吧。各种 sdk 也都有，完全开源。

[agee]

国内 leancloud 什么的全是照着 parse-server 的 api 做的，代码是不是用的开源的不好说，api 几乎是完全一样，他们自己加了点点东西而已。

[jhdxr]

@GreyYang 只要这种配置还需要程序员去写，我觉得就不太能称作『不用写代码』。否则 css 这种描述性的都不算了。。。。

[no1xsyzy]

@GreyYang 配置实现实质还是 DSL 代码……
但凡学过 Lisp （代码即数据）都不会搞出这么生硬的区分。

[no1xsyzy]

跟服务商重度绑定的后果，Parler 是前车之鉴，亿万富翁都救不回来

[fkdog]

看标题就知道这是啥玩意了。
这些东西弄来弄去本质就是将客户端-服务端之间职责可以为交集的部分进行二次改写整活。
搞一堆的 schema 有时候还不如后端直接写代码便于维护。

这玩意除了给不会写后端的前端们搞点小玩具以外，毫无价值。。

[NUT]

这不就是 mongodb 的 api 封装么