Update graphql-api.mdx

Author: idalithb

website/pages/en/querying/graphql-api.mdx

@@ -6,13 +6,13 @@ Learn about the GraphQL Query API used in The Graph.
 
 ## What is GraphQL?
 
-[GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
 
-- To understand the larger role that GraphQL plays, review [developing](/network/developing/) and [creating a subgraph](/developing/creating-a-subgraph/).
+To understand the larger role that GraphQL plays, review [developing](/network/developing/) and [creating a subgraph](/developing/creating-a-subgraph/).
 
 ## Queries with GraphQL
 
-In your subgraph schema you define types called `Entities`. For each `Entity` type, an `entity` and `entities` field will be generated on the top-level `Query` type.
+In your subgraph schema you define types called `Entities`. For each `Entity` type, an `entity` and `entities` fields will be generated on the top-level `Query` type.
 
 > Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
 
@@ -85,7 +85,7 @@ When querying a collection, it's best to:
 
 - Use the `first` parameter to paginate from the beginning of the collection.
   - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
-- Use The `skip` parameter to skip entities and paginate. e.g. `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
 - Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
 
 #### Example using `first`
@@ -118,7 +118,7 @@ Query 10 `Token` entities, offset by 10 places from the beginning of the collect
 
 #### Example using `first` and `id_ge`
 
-If a client needs to retrieve a large number of entities, it's best to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
 
 ```graphql
 query manyTokens($lastID: String) {
@@ -168,7 +168,7 @@ You can use suffixes like `_gt`, `_lte` for value comparison:
 
 #### Example for block filtering
 
-You can also filter entities by the `_change_block(number_gte: Int)`, which filters entities that were updated in or after the specified block.
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
 
 This can be useful if you are looking to fetch only entities which have changed, for example since the last time you polled. Or alternatively it can be useful to investigate or debug how entities are changing in your subgraph (if combined with a block filter, you can isolate only entities that changed in a specific block).
 
@@ -291,7 +291,7 @@ _change_block(number_gte: Int)
 
 You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
 
-- The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
 
 > Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
 
@@ -389,11 +389,11 @@ Graph Node implements [specification-based](https://spec.graphql.org/October2021
 
 ## Schema
 
-The schema of your `data source`, which is the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Langauge (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+The schema of your `data source`, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Langauge (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
 
 GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
 
-> **Note:** Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
 
 ### Entities