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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 1348 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

第 1 条附言 · 2021-04-06 10:07:25 +08:00

总结老哥们的看法：

深度依赖绑定，存在迁移成本
需对服务提供方的道德100%信任，没有人做坏事
按量计费，到一定程度还没固定计费划算
业务都在前端代码里，以后只招前端即可，大前端：）
小打小闹项目可用，正式项目需要慎重考虑好实际情况

发现这平台在举办插件比赛活动 https://ask.dcloud.net.cn/article/38878

30w奖金池，中奖范围88个人，插件包销制，第一次看到这种玩法
“插件包销”，是指获奖插件通过插件市场销售，平台兜底包销
以特等奖的5万元包销为例，如果获奖插件在插件市场1年内销售额没有达到5万元，则由平台付差额给获奖者进行兜底

so，这个一年内是一年整，还是一年内那个时间点没看到，我估计是一年时间给你包销结清
如果中奖的话，加油老哥们！我只能帮你们到这了。

JSON

狗头

uniapp

开发

53 条回复 • 2021-04-07 23:29:20 +08:00

fdd

2021-04-04 20:24:09 +08:00 via iPhone

跟小程序的云开发差不多吧

superrichman

2021-04-04 20:26:56 +08:00 via iPhone

看起来是把 graphql 封装了一层

airyland

2021-04-04 20:29:23 +08:00

宣传肯定是标题党，在前端写后端查询只是位置变了，没有所谓的不需要写服务器代码。

每个表一份表结构 json 配置并没有什么问题，上百个表的业务在传统开发形式中至少也需要有一个定义文件。

king888

2021-04-04 20:34:20 +08:00

@airyland 还是有区别的吧，他那个规范 json 要定义好权限问题，毕竟前端梭哈，考虑到安全问题

liuxu

2021-04-04 20:41:08 +08:00

ddos 是打不起，cc 看看你有多少钱

geebos

2021-04-04 20:45:05 +08:00

看了一下文档，类似于把模板放到前端渲染了，真正的业务逻辑还是要通过云函数来实现。

mogg

2021-04-04 20:50:03 +08:00

看他的成功案例就知道了，做做宣传页面和收集问卷这种简单业务应该挺方便的。
自定义复杂功能，云函数，不还是 node 写服务端，只是帮你省了服务器配置？

eason1874

2021-04-04 20:51:46 +08:00

搞点小玩意就真香，不用配置和维护服务器，正经业务不敢用。

ALL IN JS （一种开源编程语言）不是问题，ALL IN ONE （一个商业平台）才是问题。

用这玩意儿开发的产品深度依赖他们的平台，迁移成本太高了。

airyland

2021-04-04 20:53:14 +08:00

@king888 我理解它的 schema 和数据应该都在服务端，不在前端。

mogg

2021-04-04 20:57:45 +08:00

翻了一下首页, "一套代码编到 10 个平台，这不是梦想"，整无语了，5 年后再看 233

christin

2021-04-04 21:02:17 +08:00 via iPhone

他们自己用这个技术了么

king888

2021-04-04 21:03:28 +08:00

@mogg 你还别无语，忘了在那看的消息了记不太清，好像他们说当初是腾讯团队找上他们，没合作还是啥，然后腾讯搞的小程序出来，看一个小程序就整多少平台了腾讯，阿里，百度，头条，360...

jhdxr

2021-04-04 21:06:20 +08:00

简单逻辑的确可以。但是稍微复杂一点，比如：一个论坛程序，每个用户只能修改自己的发言，我想知道『只能修改自己的』这一点可以做到吗？客户端的提交始终应当被认为是不可信的，所以在省略了服务端的情况下，这种逻辑如何处理？

zjsxwc

2021-04-04 21:21:25 +08:00 via Android

还好那个蓝人不会来了，

滑稽🤪

https://www.v2ex.com/t/544424

xuanbg

2021-04-04 21:54:21 +08:00

@jhdxr 你信了他的鞋。。。

要说前端拖拖控件不要写代码我信，后端不写代码能行？就算上 serverless 那一套，无非就是运维交给云，也少不了写代码啊。

opengps

2021-04-04 22:08:19 +08:00

这种设计的目的是让手里缺后端的公司，拿前端当后端用

GreyYang

2021-04-04 22:21:29 +08:00

我觉得宣传可能是有点过，但是思路没太大差错，做 MVP 快速迭代上线很方便，真需要大流量等的时候，业务应该也不差钱了，正常招团队重新迁移就行。
另外 @jhdxr “只能修改自己的”这个需求他们还真用配置就能实现：），当然还有很多复杂的逻辑是无法实现的，需要用到云函数，就是正常写 js 后端。

hyper2k

2021-04-04 22:29:21 +08:00

前端调试和后端调试比那个难度大？

Jooooooooo

2021-04-04 22:46:24 +08:00

研究这种东西的人似乎从来没有参与过大型项目的长期开发迭代工作.

bz5314520

2021-04-04 22:57:31 +08:00

serverless 也说是无状态的业务可以丢上去节约成本,

miv

2021-04-04 22:59:31 +08:00 via iPhone

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

Felldeadbird

2021-04-04 23:12:06 +08:00

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

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

muzuiget

2021-04-05 01:03:14 +08:00

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

zhbzhbzhbz

2021-04-05 01:27:56 +08:00

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

zhbzhbzhbz

2021-04-05 01:29:08 +08:00

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

msg7086

2021-04-05 02:04:50 +08:00 via Android

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

Valid

2021-04-05 02:07:08 +08:00

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

dayeye2006199

2021-04-05 07:15:50 +08:00

看着和 firebase 和 parser 像

wulin

2021-04-05 09:19:31 +08:00

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

liuxey

2021-04-05 10:55:25 +08:00

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

winglight2016

2021-04-05 11:15:49 +08:00

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

watzds

2021-04-05 13:40:59 +08:00 via Android

很多年前就有

hehezhang

2021-04-05 13:49:03 +08:00

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

agee

2021-04-05 14:14:05 +08:00 via iPhone

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

agee

2021-04-05 14:18:29 +08:00 via iPhone

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

jhdxr

2021-04-05 15:08:10 +08:00

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

no1xsyzy

2021-04-05 17:01:19 +08:00

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

no1xsyzy

2021-04-05 17:06:35 +08:00

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

fkdog

2021-04-05 17:08:22 +08:00

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

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

NUT

2021-04-05 18:55:40 +08:00

这不就是 mongodb 的 api 封装么

cooker498

2021-04-05 20:08:54 +08:00

前端惨了

TomVista

2021-04-05 21:42:57 +08:00

我想，我有发言权
hasura / postgreset / parse-server /小程序云开发重度使用者，

这是上一家的技术选型，可以快速 curd，前端用 ui 点几下建表，然后直接 curd 起飞。

优点：
确实可以承载绝大多数常见业务，
开发速度非常快效率非常高
curd 接口不会出错
代码量下降

缺点：
数据鉴权困难
锁事务 acid 数据聚合可用性基本为 0
无法重构
不适合团队协作，业务都在前端代码里，对前端代码质量 /工程化程度要求很高
极大的提升了项目的复杂度，
我后端理解不多，优点里没提到的，就都是缺点了

总结
建议作为单一 curd 服务给后端使用，提升开发速度，不使用其他功能