GraphQL 一点都不新鲜了

【 在 ztysys () 的大作中提到: 】
: 比如一个系统，资源很简单，基本一两个表就完了，但是要完成的操作千变万化，什么合并资源、状态转来转去、组合资源状态转来转去、资源传递、还有成组很像但又不一样的动作，这时候怎么用 HTTP Method 搞定？
: 最好别为了解决这个问题又搞出一个更复杂的框架。。。。
: 还是 Restful 并不适合这类应用？
: ...................
--
FROM 122.59.181.*

jsonrpc

【 在 ztysys () 的大作中提到: 】
: GraphQL 不相关吧
: 资源数据关系很简单，没有层次关系，业务操作很多，但也都是平行关系，也就是很杂很多
: 几十上百种基本独立的操作，针对单层数据，需要 GraphQL 干什么？
: ...................
--
FROM 112.47.122.*

这已经是抽象过了的，业务已经整理过的，不存在业务不清晰的问题

但是 Restful 应对这种场景就是没有好的简单易行的办法，真严格按照 http method 来，就是不好处理。非要引入其它框架，又反而增加复杂度

【 在 cn62 的大作中提到: 】
: 不管用什么框架都不可能减少业务复杂性。
: 你这种问题根本上还是要梳理业务，业务层面先抽象好。
:
--
FROM 116.235.131.*

单 entrypoint 解决 rest 无数个 entrypoints 的问题
多 queries、mutations 解决多个 api 调用的问题

gql 本来就对应着 rest，既然有成熟的东西，当然拿来用比从头轮容易多了

【 在 ztysys () 的大作中提到: 】
: GraphQL 不相关吧
: 资源数据关系很简单，没有层次关系，业务操作很多，但也都是平行关系，也就是很杂很多
: 几十上百种基本独立的操作，针对单层数据，需要 GraphQL 干什么？
: ...................
--
FROM 122.59.181.*

一个 request 几十个 mutations 呗，有啥不理解的？

【 在 ztysys () 的大作中提到: 】
: 你这个好像并不能解决我的问题，不太理解
: 最简单的例子，一个表一条数据，但有几十种变更操作，操作类型也各不相同，你这一套会怎么解决？
--
FROM 101.98.83.*