GraphQL 为什么国内很少用?权限如何处理?对参数的逻辑验证如何处理?

因为真的不好用，虽然我是前端是作为理论上的受益者

1. GraphQL 需要整个团队巨额的学习成本，相比整个用 GraphQL 重构不如糊个 BFF 层； GraphQL 的生态和普及度还比不上 RESTful ；

2. 权限处理和 RESTful 并无二致，在请求进来时判断用户权限，在查数据库时加额外条件；

3. 我个人理解拿到参数就能验证了，楼主可能在找一种更便捷的验证手段，推荐使用 GQLoom 框架( https://gqloom.dev/ )，天然集成 zod 、valibot 作为验证库，有完善的中文文档。

graphql 资深玩家，公司技术全走 graphql ，玩通了非常非常舒服（前后端全精通）。
国内生态确实不如国外，我们技

1. graphQL 为啥国内用的很少(可能个人目光短浅,看到的接口少)
graphql 学习门槛高，对业务其实没有很多帮助，没有经验的团队反而会降低开发效率。

ps:
但我的个人推荐使用的原因：graphql 可以改善技术债，强制无技术债
并且我的团队已经对 graphql 非常熟悉，我们还打算出一套自己的 graphql 框架。

2. GraphQL 的权限如何处理呢(特别是数据权限,例如某人只能看到自己部门的数据,GraphQL 好像没有标准支持)

后端拿到用户身份后，返回信息即可，如果你说意思说：A 部门返回的数据格式是 A 类型，B 部门返回的数据格式是 B 类型，这种需要后端定义 union

3. 对于突变 如何验证参数? 特别是逻辑上的验证 (例如 存在 xx 才能 xx)

定义不同的 input ，前端选填
前端后端 定义不同的验证规则



graphql 一定要玩注解、fragment 、union