fix typo.

Author: allmonday

readme-cn.md

@@ -2,7 +2,7 @@
 
 在构建 API 时, 数据的拼接和调整一直是比较头疼的问题. 
 
-过程式的数据处理对调整不友好, 循环和拼接容易产生不易维护的代码. GraphQL 带来的, 通过声明描述数据结构是一个好的方向.
+过程式的数据处理对调整不友好, 循环和拼接容易产生不易维护的代码. GraphQL 带来的通过声明描述数据结构是一个好的方向.
 
 GraphQL 的亮点是通过 Query 确定查询结构, 一层层驱动后端的 resolver 来构造数据.
 
@@ -13,12 +13,14 @@ GraphQL 的亮点是通过 Query 确定查询结构, 一层层驱动后端的 re
 - Query 语句在Schema 变化后有维护成本
 - 权限控制, 速率控制等问题, Schema 可能暴露过多信息.
 - Query 比较复杂的话, 性能问题不容易优化.
-- 无法对查询到达数据做比较精细的后期处理 (middleware 的入口是query 的顶层)
+- 无法对查询到的数据做比较精细的后期处理 (middleware 的入口是query 的顶层)
 - Schema 复杂之后, 容易出现复用代码的管理困难.
 
-对于一个有历史抱负的项目, 引入GraphQL 对前后端的改动成本也很客观. 
+对于一个有历史包袱的项目, 引入GraphQL 对前后端的改动成本也很可观. 
 
-另外, 从架构分层的角度来看, 引入 GraphQL 的代表着后端和前端的关系, 从以往多个确定的接口, 变成了不可预测使用场景的单一接口. 这就导致前端对后端之间的依赖关系变得不清晰了(失去了感知), 后端只能以面向一组"可能的查询组合" 为目标来做开发. 在这种对前端使用方式失去感知的情况下, 接口调整的成本会显著上升. 重构能力也就下降了.
+另外, 从架构分层的角度看, 引入 GraphQL 代表着前后端的关系, 从以往确定的多个接口, 变成了不可预测使用场景的单个接口. 
+
+这导致前端对后端之间的依赖关系变得不清晰了(失去了清晰感知), 后端只能以面向一组"可能的查询组合" 为目标来提供功能. 在这种失去细节感知的情况下, 接口调整的成本会显著上升. 重构能力也会下降.
 
 > 因此会看到有些GraphQL设计得就像一个个独立的API一样, 就是为了将各个接口之间区分开, 并且减少之间的深层schema 耦合. 
 >

resolve-vs-graphql-cn.md

@@ -11,9 +11,9 @@ graphql 优点
 
 graphql 缺点
 
-- 缺少层级之间进行数据聚合的能力
+- 缺少层级之间进行数据二次处理的能力. 比如上层无法在下层数据获取后进行额外操作.
 - 如果是全栈开发，后端和写 query 有重复劳动
-- 后端需要引入 graphql 相关框架
+- 前后端需要引入 graphql 相关框架
 - cache， authority, rate limit 控制起来不容易
 - 对后端不太友好
 
@@ -35,3 +35,19 @@ pydantic-resolve 缺点：
 - 查看组合类型需要通过 OpenAPI 查看 response 信息
 - 前后端分离的情况，没有后端一个万能接口来得方便
 - Friend -> Friend 的 graph 描述不方便
+
+
+### 使用 GraphQL 正确的姿势
+
+graphql 的使用思路有两种
+
+一种是根据数据的ER，构建关系型查询
+典型的比如github，jira 提供的graphql接口
+
+用户熟悉这种固定的ER，查询到规范的数据之后自己再做二次加工。换言之你哪怕有定制化的需求，也只能自己想办法处理，不可能向他们提出这种要求。
+
+另一种是面向业务，构建的是业务层的查询接口
+这种场景并不适合graphql，他对查询的数据定制化要求高，意味着通过通用接口拿到的数据往往需要根据业务做再加工，而且也会和后端商量，定制一些面向专用页面的graphql 接口。这也会慢慢变成常态，因为很多数据并不适合暴露到前端做二次处理。
+对于一整套业务，graphql 这样一个灵活的中间层反而对业务的整体清晰度造成了影响。
+
+结论就是，graphql 适合稳定的，轻业务概念的数据的组合查询。而不适合面向具体业务，高度定制化的场景。