Edits

Author: MichaelMacaulay

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

@@ -28,11 +28,11 @@ The Graph uses GraphQL to query Subgraphs.
 
 GraphQL queries in The Graph target entities defined in the Subgraph schema. Each `Entity` type generates corresponding `entity` and `entities` fields on the root `Query` type.
 
-Note: The `query` keyword is not required at the top level of GraphQL queries.
+> Note: The `query` keyword is not required at the top level of GraphQL queries.
 
 ### Single Entity Queries
 
-Query format for a single `Token` entity:
+Query for a single `Token` entity:
 
 ```graphql
 {
@@ -43,7 +43,7 @@ Query format for a single `Token` entity:
 }
 ```
 
-Note: Single entity queries require the `id` parameter as a string.
+> Note: Single entity queries require the `id` parameter as a string.
 
 ### Collection Queries
 
@@ -89,7 +89,7 @@ Collection queries support the following sort parameters:
 }
 ```
 
-Note: Nested sorting supports one-level-deep `String` or `ID` types on `@entity` and `@derivedFrom` fields.
+> Note: Nested sorting supports one-level-deep `String` or `ID` types on `@entity` and `@derivedFrom` fields.
 
 ### Pagination
 
@@ -207,7 +207,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 }
 ```
 
-**Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+**Syntactic sugar:** You can simplify the above query by removing the `and` operator and by passing a sub-expression separated by commas.
 
 ```graphql
 {
@@ -366,7 +366,7 @@ Metadata fields:
 - `block`: Latest block information
 - `hasIndexingErrors`: Boolean indicating past indexing errors
 
-> **Note**: When writing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use `and` operators instead of `or` whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+> Note: When writing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use `and` operators instead of `or` whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
 
 ### GraphQL Filter Operators Reference