Update README.md

proof read and corrected mistakes

Author: evanmcneely

README.md

@@ -113,7 +113,7 @@ app.use(
 
 ## <a name="lists"></a> Notes on Lists
 
-The complexity for list types is not determined by the schema, but by the varibales passed to the field as slicing arguments or by directives
+The complexity for list types can be set in the schema with the use of directives, or in the query by the varibales passed to the field as slicing arguments.
 
 1. Slicing arguments: lists must be bounded by one integer slicing argument in order to calculate the comlexity for the field. This package supports the slicing arguments `first`, `last` and `limit`. The complexity of the list will be the value passed as the argument to the field.
 
@@ -124,31 +124,32 @@ The complexity for list types is not determined by the schema, but by the variba
 
 Rate-limiting is done by IP address.
 
-On server start, the GraphQL (GQL) schema is parsed to build an object that maps GQL types/feilds to values corresponding to the weights assigned to each GQL type/field. This object is used internally to cross refernce the fields queried by the user with the weight to apply that field when totaling the overall complexity of the query. 
+On server start, the GraphQL (GQL) schema is parsed to build an object that maps GQL types/fields to values corresponding to the weights assigned to each GQL type/field. This object is used internally to cross reference the fields queried by the user with the weight to apply that field when totaling the overall complexity of the query. 
 
-For each request, the query is parsed and traversed to total the overall complexity of the query based on the type/field weights configured on setup. This is done statically, before any resolvers are fired, to estimate the upper bound of response size of the request (a proxy for the work done by the server to build the response). The total complexity is then used to allow/block the request based on popular rate-limiting algorithms.
+For each request, the query is parsed and traversed to total the overall complexity of the query based on the type/field weights configured on setup. This is done statically (before any resolvers are called) to estimate the upper bound of response size of the request - a proxy for the work done by the server to build the response. The total complexity is then used to allow/block the request based on popular rate-limiting algorithms.
 
 If a user sends two request simustaneously, the trailing request will wait for the first one to complete any asyncronous work before being processed.
 
 Example (with default weights):
 
 ```javascript
 query { //  1
-   hero (episode: EMPIRE) { // 1,  total complexity: 1 (hero) + 3 (friends) = 4
+   hero (episode: EMPIRE) { // 1
       name // 0
       id // 0
       friends (first: 3) { // 3
          name // 0
          id // 0
       }
    }
-   reviews(episode: EMPIRE, first: 5) { // 5
+   reviews(episode: EMPIRE, limit: 5) { // 5
       stars // stars 0
       commentary // commentary 0 
    } 
 }
-// total complexity 10
+// total complexity of 10
 ```
+
 ## <a name="response"></a> Response
 
 1. Blocked Requests: blocked requests recieve a response with, 
@@ -162,7 +163,7 @@ query { //  1
 ```javascript
 {
    graphglGate: {
-      success: boolean, // true
+      success: boolean, // true when successful
       tokens: number, // tokens available after request
       compexity: number, // complexity of the query
       depth: number, // depth of the query
@@ -173,15 +174,15 @@ query { //  1
 
 ## <a name="error-handling"></a> Error Handling
 
--  Incoming queries are validated against the GraphQL schema. If the query is invalid, a response with status code `400` is returned along with the array of GraphQL Validation Errors that were found.
+-  Incoming queries are validated against the GraphQL schema. If the query is invalid, a response with status code `400` is returned along with an array of GraphQL Errors that were found.
 -  To avoid disrupting server activity, errors thrown during the analysis and rate-limiting of the query are logged and the request is passed onto the next middleware function in the chain.
 
 ## <a name="future-development"></a> Future Development
 
 -   the ability to use this package with other caching technologies or libraries
 -   implement "resolve complexity analysis" for queries
 -   implement leaky bucket algorithm for rate-limiting
--   experimint with performance improvments
+-   experiment with performance improvements
     -   caching optimization
 -   ensure connection pagination conventions can be accuratly acconuted for in comprlexity analysis