graphQL应用场景分析

#graphQL

参考

https://www.pupboss.com/post/2021/experience-sharing-of-graphql-backend/

graphQL

GraphQL要解决的问题: 优化客户端向服务器请求数据的过程.

  • 对于同样的业务需求, REST API可能要请求多个endpoints, GraphQL可以用一个请求.
  • 数据形式是客户端定义的, 只取想要的数据, 不会取多余的数据, 减小了数据传输量.
  • 各个前端可以访问自己想要的数据.
  • 快速开发, feature快速迭代. 升级改动时, 可能不需要后端改动.

优点

  • 避免请求冗余和数据冗余 可以提升开发效率,可以提升性能. 减少前端请求次数(事实上我不知道这有什么意义)

  • 文档维护方便

  • 开发效率

  • 适合微服务 通过定义schema,自动从各个微服务中获取数据.

缺点

  • 迁移成本 debug和test麻烦. graphql侵入性大, 耦合性高. 现有系统迁移成本很高. 只有一个URI,所以权限控制/限流/网关/等等与URI相关的功能,都要重新实现. 对URI的颠覆式使用,让graphql的使用成本也是颠覆式的.

  • 性能 通过"最大查询深度、查询复杂度加权、避免递归或持久查询"来避免性能问题. 但graphql性能优化很难, 一个接口应对多种场景. 而restful一个接口对应一个场景,可以针对性的优化. 系统的瓶颈往往在数据库. 通过graphql可以减少前端请求次数,只是稍微方便了前端开发, 却带来了问题. 大部分时候,我们是希望通过异步加载来优化性能的.

前端自由查询,复杂度转移给了后端, 但后端难以对查询进行优化, 查询深度限制只是限制最低标准, 并不是最优, 如果前端导出都卡着这个限制来查询, 数据库压力会很大, 数据库压力大, 也就意味着成本的增加. 后端开发者应该对数据库性能负责, 但是graphql导致后端开发者无法全力负责, 这是矛盾的. 数据库的优化是要自始至终 细小甚微的.

  • 缓存优化困难.

  • 主要的技术栈是nodejs, 其他语言支持度不高.

  • 限流 在 REST API 中，你可以简单地指定我们一天只允许这个数量的请求，但在 GraphQL 中，很难指定这种类型的语句。

总结

我只是想让接口提供的字段更灵活, 但是graphql让我重写整个架构. 解决了一个小问题, 却带来了更大的问题. 大部分的系统,需要"灵活多变的查询"的场景并不多, 为了解决小问题, 要引入graphql, 会带来更多的成本的风险控制.

适用场景

  • 大量的灵活查询. 如果你的系统大部分查询字段是固定的, 没必要使用. elasticSearch很适合.
  • 不使用异步加载, 希望前端请求次数减少.()
  • 希望公开API, 但是又不想频繁修改API
  • 开发新产品,而不是维护老产品

对外开放的平台

  1. 对外开放, 外部开发者可以自由的查询数据, 我们不需要对接口进行频繁修改.
  2. resource单一, 复杂查询少, 这样可以避免性能问题.
  3. 文档维护简单, 阅读起来清晰.

backend for frontend 在微服务场景中, BBF使用graphql可以提高开发效率,自动聚合各服务的资源. graphql与restful在一个项目中结合使用,扬长避短.

从编码的角度

service和persistence层没有明显变化. 通过schema建立模型关系, 通过resolver来获取数据, 进而自动聚合数据. 通过schema定义灵活的model, 可以自动聚合出各种模型的数据.