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

• 資深大佬 : fdd

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

• 資深大佬 : superrichman

  看起来是把 graphql 封装了一层

• 資深大佬 : airyland

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

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

• 主 資深大佬 : king888

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

• 資深大佬 : liuxu

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

• 資深大佬 : geebos

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

• 資深大佬 : mogg

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

• 資深大佬 : eason1874

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

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

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

• 資深大佬 : airyland

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

• 資深大佬 : mogg

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

• 資深大佬 : christin

  他们自己用这个技术了么

• 主 資深大佬 : king888

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

• 資深大佬 : jhdxr

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

• 資深大佬 : zjsxwc

  还好那个蓝人不会来了，

  滑稽

• 資深大佬 : xuanbg

  @jhdxr 你信了他的鞋。。。

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

• 資深大佬 : opengps

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

• 資深大佬 : GreyYang

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

• 資深大佬 : hyper2k

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

• 資深大佬 : Jooooooooo

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

• 資深大佬 : bz5314520

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

• 資深大佬 : 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

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

• 資深大佬 : liuxey

  莫非没搞过“真正的”需求？ 稀奇古怪的对接和产品需求能把这些云 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 封装么

• 資深大佬 : cooker498

  前端惨了

• 資深大佬 : TomVista

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

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

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

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

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

• 資深大佬 : TimPeake

  这个问题差不多相当于： 以后 AI 智能发展了 还需要程序员这个职业吗？

• 資深大佬 : TimPeake

  数据后端数据操作跟前端代码糅合 这个想法还是蛮有创意的

• 資深大佬 : xiaotianhu

  https://zhuanlan.zhihu.com/p/126189048

  掘金这么干过,因为老板是前端

  后来换回去了.

• 資深大佬 : airplayxcom

  分分钟被人脱裤？？

• 資深大佬 : brust

  我这也有人吹,但我觉得他不懂代码

• 資深大佬 : jmyz0455

  看上去就是微信的云开发吧？

• 資深大佬 : xushanli

  程序员一直在做可以取代程序员的事情

• 資深大佬 : guyeu

  让前端学习一种基于 JSON 的 DSL 去编写后端代码，这是不用写服务器代码的意思吗

• 資深大佬 : stevenkang

  不用开发？云开发？

  不如开个 FTP 服务，弄个 excel 表，注册用户=新建 FTP 账号，要修改数据自己登录 FTP 账号上去改，还能生成各种图表，岂不美哉？连 JS 都不用写了

• 資深大佬 : GreyYang

  @jhdxr 对的，我不觉得这个可以叫做不用写代码 🙂

• 資深大佬 : GreyYang

  @no1xsyzy 是的哈