Merge pull request #557 from tbroadley/fix-typos

docs: fix typos

CHANGELOG.md

@@ -181,7 +181,7 @@ Update to add support for `graphql@0.12`, and drop versions before `0.11` from t
 
 * Removed testing on Node 5 ([@DxCx](https://github.com/DxCx) in [#129](https://github.com/apollostack/graphql-tools/pull/129))
 
-* Changed GraphQL typings requirment from peer to standard ([@DxCx](https://github.com/DxCx) in [#129](https://github.com/apollostack/graphql-tools/pull/129))
+* Changed GraphQL typings requirement from peer to standard ([@DxCx](https://github.com/DxCx) in [#129](https://github.com/apollostack/graphql-tools/pull/129))
 
 * Change the missing resolve function validator to show a warning instead of an error ([@nicolaslopezj](https://github.com/nicolaslopezj) in [#134](https://github.com/apollostack/graphql-tools/pull/134))
 

designs/connectors.md

@@ -37,7 +37,7 @@ In this example, an author has multiple posts, and each post has one author.
 
 Here's an illustration for how connectors and models would look like for this example if Authors and Posts were stored in MySQL, but view counts in MongoDB:
 
-![Connectors are database-specfic, models are application-specific](connector-model-diagram.png)
+![Connectors are database-specific, models are application-specific](connector-model-diagram.png)
 
 
 The Posts model connects to both SQL and MongoDB. Title, text and authorId come from SQL, the view count comes from MongoDB.
@@ -60,7 +60,7 @@ Both batching and caching are more important in GraphQL than in traditional endp
 
 Models are the glue between connectors - which are backend-specific - and GraphQL types - which are app-specific. They are very similar to models in ORMs, such as Rails' Active Record.
 
-Let's say for example that you have two types, Author and Post, which are both stored in MySQL. Rather than calling the MySQL connector directly from your resolve funcitons, you should create models for Author and Post, which use the MongoDB connector. This additional level of abstraction helps separate the data fetching logic from the GraphQL schema, which makes reusing and refactoring it easier.
+Let's say for example that you have two types, Author and Post, which are both stored in MySQL. Rather than calling the MySQL connector directly from your resolve functions, you should create models for Author and Post, which use the MongoDB connector. This additional level of abstraction helps separate the data fetching logic from the GraphQL schema, which makes reusing and refactoring it easier.
 
 In the example schema above, the Authors model would have the following methods:
 ```

docs/source/resolvers.md

@@ -178,7 +178,7 @@ Modules and extensions built by the community.
 
 Composition library for GraphQL, with helpers to combine multiple resolvers into one, specify dependencies between fields, and more.
 
-When developing a GraphQL server, it is common to perform some authorization logic on your resolvers, usually based on the context of a request. With `graphql-resolvers` you can easily accomplish that and still make the code decoupled - thus testable - by combining multiple sigle-logic resolvers into one.
+When developing a GraphQL server, it is common to perform some authorization logic on your resolvers, usually based on the context of a request. With `graphql-resolvers` you can easily accomplish that and still make the code decoupled - thus testable - by combining multiple single-logic resolvers into one.
 
 The following is an example of a simple logged-in authorization logic:
 

docs/source/schema-stitching.md

@@ -112,7 +112,7 @@ You won't be able to query `User.chirps` or `Chirp.author` yet however, because
 
 So what should these resolvers look like?
 
-When we resolve `User.chirps` or `Chirp.author`, we want to delegate to the revelant root fields. To get from a user to its chirps for example, we'll want to use the `id` of the user to call `chirpsByAuthorId`. And to get from a chirp to its author, we can use the chirp's `authorId` field to call into `userById`.
+When we resolve `User.chirps` or `Chirp.author`, we want to delegate to the relevant root fields. To get from a user to its chirps for example, we'll want to use the `id` of the user to call `chirpsByAuthorId`. And to get from a chirp to its author, we can use the chirp's `authorId` field to call into `userById`.
 
 Resolvers specified as part of `mergeSchema` have access to a `delegate` function that allows you to delegate to root fields.
 
@@ -220,7 +220,7 @@ resolvers: mergeInfo => ({
 
 #### mergeInfo and delegate
 
-`mergeInfo` currenty is an object with one property - `delegate`. It looks like this:
+`mergeInfo` currently is an object with one property - `delegate`. It looks like this:
 
 ```js
 type MergeInfo = {