请教，这种“数据中台”系统各位有见过或实践过的吗？有什么优缺点？

[abcbuzhiming]

说叫“数据中台”是因为我找不到比较好的名词来形容它。事情是这样的，公司来了一位从一线回来的前端，提到他在上海见过不少中小型公司都实现了这样一套系统，这个系统简单的说就实现了两个接口，后台对接一个固定的数据库；这两个接口一个能实现任意的表级 schema 操作，能够增加，修改，任意表和表字段（没有删除）。另外一个接口则是查询数据的，能查询任意表，能组合任意查询语句。他提出这个东西最大的好处就是一旦完成，后端就可以不用再管前端了，前端也不用找后端要接口了，可以统统自己搞定。我个人感觉他提出的这个东西，似乎和 graphql 有点像，但是似乎 graphql 并没有提供能随意修改表结构的方案。
有没有人实践过这样的系统？这样的系统有什么缺陷

[ben1024]

我对数据中台的理解是阿里的数据中心分发控制，来监视所有数据变化和异常。
这前端描述的确实是 GraphQL
动不动炒概念扯中台的都是坑

[whitev2]

页面写 sql ？

[exonuclease]

这个是 graphql 吧 想法不错 不过有安全和性能坑

[abcbuzhiming]

@whitev2 页面不写 sql，以接口来实现建表和修改操作


@ben1024
@exonuclease
我仔细翻了 graphql 的想法，但是我发现 graphql 并没有提供修改表 schema 的能力，graphql 只是提供了让使用者决定获取的数据结构的能力。新增表，修改表结构这样的能力 graphql 有提供过？

[Phuasheng]

如果分工合作是趋势的话，这个有点在开倒挡车。。。

业务逻辑一旦上来，就会涉及到多人合作开发，将数据与 UI 拆开分给两波不同的人并行开发，是个比较不错的选择。然后最终还是会演化成前后端分离

如果这个思路没问题的话，用了他这个系统
1.多人协作方面将会非常蛋疼
2.给前端这么大的权限，前端无隐私，如何保证数据安全（还增加了修改表结构）？
3.用了这个系统，两人变一人，肯定 996 ？


纯属猜想

[epkT6QJ3RSaz6AnJ]

其实就是把 mysql 封装了一层，对于一般业务来说确实减少了沟通成本，通过领域模型来设计实体。只适合读多写少和和没有锁的业务。

[murmur]

这东西挺好的，而且实际上企业开发用的非常多，比如今天要个用车，明天来个用船，后天来个用直升机，这几个东西逻辑差不多，流程差不多，就是字段不一样，干嘛重复开发，而且不要求并发，性能不存在问题

[micean]

什么样的前端业务还需要 DDL?

[VeryZero]

前端还得修改表结构？那还要后端干吗，全栈走起。。

[securityCoding]

谁动了我的表我会生气....

[abcbuzhiming]

@VeryZero 我也猜这人想的就是全栈（或者说诛心一点，侵蚀后端的空间），现在我不打算去考虑他内心真实想法，我只想考虑这东西有多大的负面性，毕竟这人看起来不是真的对后端很有理解，他自己也承认重业务还得后端来写，他想要的就是简单的 CRUD 不找后端。所以他想直接操作后端的表，我担心的就是将来如果后端出了技术问题，这个锅谁来背，坑有多大，如何解决

[xFan]

前面一家公司有数据中台这种概念，在分布式架构上每个业务模块只搞出所有数据查询的接口 中台只来组装所有数据面对前端。麻烦在事务控制。分页等查询。你可以问一下前端组装数据的分页怎么写···

[fe619742721]

有点意思，关注下，
这种东西强推肯定会受到抵触的，而且确实得好好评估下得失。
我是前端，如果我真的想搞这么个东西，肯定也是先在公司熟悉了以后，跟后端搞好关系后友好讨论下再来推进，刚进公司就搞这个，不得不怀疑动机啊

[prolic]

感觉会有安全性问题

[ben1024]

@abcbuzhiming
GraphQL mutations 吗？
https://graphql.org/graphql-js/mutations-and-input-types/

[q8164305]

还不如直接去学后端开发呢

[xwhxbg]

你这不是把 phpmyadmin 封装一下吗？就是个控制台说那么高大上

[lihongjie0209]

为什么不直连数据库?? N 年前的桌面开发不是搞过这种事情了吗

[xuanbg]

这个不就是那个 JSONAPI 还是 APIJSON 来着？

[dearxe2v]

@xuanbg #19 帮你 @TommyLemon 推广时间到啦😊