Merge pull request #42 from Jeff-Tian/patch-1

docs: fix typos

Author: swalkinshaw

lang/TUTORIAL_SIMPLIFIED_CHINESE.md

@@ -105,7 +105,7 @@ type CollectionMembership {
 尽管只有四个对象和一个接口，但乍看之下已经相当复杂。而且，它似乎并没有完全地满足业务需求，
 例如我们需要使用这样的 API 来完成移动端 App 上的合集功能似乎就不太够用了。
 
-让我们先缓缓好好的思考一下，用一个由多个对象和数十个字段揉杂在一起所构成的 Graphql API 来实现某一业务需求往往是混乱和错误的开端。你应该首先从更高的抽象层级进行思考，并着眼于类型（GraphQL Type）及各个类型之间的关系，而非数据库层面的具体字段或对 CRUD 接口进行简单罗列。从[实体关系模型（Entity-Relationship model）](https://zh.wikipedia.org/zh-hans/ER%E6%A8%A1%E5%9E%8B)开始思考会是一个好的选择。如果我们像这样收敛和简化一下范围，我们将得到以下结果：
+让我们先好好的思考一下，用一个由多个对象和数十个字段揉杂在一起所构成的 Graphql API 来实现某一业务需求往往是混乱和错误的开端。你应该首先从更高的抽象层级进行思考，并着眼于类型（GraphQL Type）及各个类型之间的关系，而非数据库层面的具体字段或对 CRUD 接口进行简单罗列。从[实体关系模型（Entity-Relationship model）](https://zh.wikipedia.org/zh-hans/ER%E6%A8%A1%E5%9E%8B)开始思考会是一个好的选择。如果我们像这样收敛和简化一下范围，我们将得到以下结果：
 
 ```graphql
 interface Collection {
@@ -610,7 +610,7 @@ input CollectionInput {
 
 尽管这样一来 `create` 时的 `title` 也变成了允许为空，但如果需要的话我们完全可以在 `create` 的 resolver 中再行验证。
 
-*规则二十一： 结构化 Mutation 的 Inpute 以减少重复，即使是以在类型层面上放宽对于某些字段的要求性约束为代价。*
+*规则二十一： 结构化 Mutation 的 Input 以减少重复，即使是以在类型层面上放宽对于某些字段的要求性约束为代价。*
 
 ### Mutation 的返回值
 
@@ -669,7 +669,7 @@ type CollectionUpdatePayload {
 - 规则十八： 仅将真的必填的字段在 Input 中设为必填。
 - 规则十九：当 Input 类型比较复杂导致客户端进行验证过于复杂时，可以将之弱化成更通用的类型以便于由服务器进行验证。例如用 `string` 标量 替代 `email` 标量，然后在服务器端进行验证并将所有的错误提示一次性返回给客户端。
 - 规则二十：当输入的格式可能有歧义而且客户端验证并不困难的时候，应该有限考虑使用强类型（例如 `DateTime` 优于 `string`）。
-- 规则二十一： 结构化 Mutation 的 Inpute 以减少重复，既是是以在类型层面上放宽对于某些字段的要求性约束为代价。
+- 规则二十一： 结构化 Mutation 的 Input 以减少重复，既是是以在类型层面上放宽对于某些字段的要求性约束为代价。
 - 规则二十二： Mutation的中应该包含一个标识业务层面错误的数组。
 - 规则二十三：大多数的 Payload .字段都应该是可以为空的，除非确保其在错误的情况下也有返回值。