Merge branch 'master' into unresolved-entity

Author: mduesterhoeft

docs/package-lock.json

@@ -6,8 +6,8 @@
     "serve": "gatsby serve"
   },
   "dependencies": {
-    "gatsby": "2.21.9",
-    "gatsby-theme-apollo-docs": "4.2.2",
+    "gatsby": "2.22.9",
+    "gatsby-theme-apollo-docs": "4.2.3",
     "react": "16.13.1",
     "react-dom": "16.13.1"
   }

docs/package.json

@@ -198,7 +198,7 @@ type Query {
 Here's a valid query against that schema:
 
 ```graphql
-query {
+query GetBooksByLibrary {
   libraries {
     books {
       author {
@@ -325,7 +325,7 @@ server.listen().then(({ url }) => {
 If we now update our query to also ask for each book's `title`:
 
 ```graphql{4}
-query {
+query GetBooksByLibrary {
   libraries {
     books {
       title

docs/source/data/resolvers.mdx

@@ -182,7 +182,7 @@ extend type Product @key(fields: "upc") {
 Similar to the `reviews` relationship example above, the gateway fetches the required `upc` field from the `products` service and passes it to the `inventory` service, even if the query didn't ask for the `upc`:
 
 ```graphql
-query {
+query GetTopProductAvailability {
   topProducts {
     inStock
   }

docs/source/federation/entities.md

@@ -122,7 +122,7 @@ Queries across service boundaries will start off from the `_entities` root field
 For example, if we execute a query for the top product's `reviews`:
 
 ```graphql
-query {
+query GetTopProductReviews {
   topProducts {
     reviews {
       body

docs/source/federation/federation-spec.md

@@ -257,7 +257,7 @@ directive @uppercase on FIELD
 And here's an example of a query that uses that directive:
 
 ```graphql
-query {
+query GetUppercaseUsernames {
   users {
     name @uppercase
   }

docs/source/federation/gateway.mdx

@@ -189,7 +189,7 @@ were implemented as a single, monolithic service:
 
 ```graphql
 # A query that the gateway resolves by calling all three services
-query {
+query GetCurrentUserReviews {
   me {
     username
     reviews {

docs/source/federation/introduction.mdx

@@ -237,15 +237,15 @@ type Query {
 A query might look like this:
 
 ```graphql
-query {
+query GetAvatar {
   avatar(borderColor: RED)
 }
 ```
 
 To pass the enum value as a variable, use a string of JSON, like so:
 
 ```graphql
-query MyAvatar($color: AllowedColor) {
+query GetAvatar($color: AllowedColor) {
   avatar(borderColor: $color)
 }
 ```

docs/source/schema/scalars-enums.md

@@ -76,18 +76,18 @@ type Author {
 
 ### The `Query` type
 
-The `Query` type defines exactly which GraphQL queries (i.e., read operations) clients can execute against your data graph. It resembles an [object type](#object-types), but its name is always `Query`.
+The `Query` type defines all of the top-level **entry points** for queries that clients execute against your data graph. It resembles an [object type](#object-types), but its name is always `Query`.
 
-Each field of the `Query` type defines the name and return type of a different supported query. The `Query` type for our example schema might resemble the following:
+Each field of the `Query` type defines the name and return type of a different entry point. The `Query` type for our example schema might resemble the following:
 
 ```graphql
 type Query {
-  getBooks: [Book]
-  getAuthors: [Author]
+  books: [Book]
+  authors: [Author]
 }
 ```
 
-This `Query` type defines two available queries: `getBooks` and `getAuthors`. Each query returns a list of the corresponding type.
+This `Query` type defines two fields: `books` and `authors`. Each field returns a list of the corresponding type.
 
 With a REST-based API, books and authors would probably be returned by different endpoints (e.g., `/api/books` and `/api/authors`). The flexibility of GraphQL enables clients to query both resources with a single request.
 
@@ -98,12 +98,12 @@ When your clients build queries to execute against your data graph, those querie
 Based on our example schema so far, a client could execute the following query, which requests both a list of all book titles _and_ a list of all author names:
 
 ```graphql
-query {
-  getBooks {
+query GetBooksAndAuthors {
+  books {
     title
   }
 
-  getAuthors {
+  authors {
     name
   }
 }
@@ -114,13 +114,13 @@ Our server would then respond to the query with results that match the query's s
 ```json
 {
   "data": {
-    "getBooks": [
+    "books": [
       {
         "title": "Jurassic Park"
       },
       ...
     ],
-    "getAuthors": [
+    "authors": [
       {
         "name": "Michael Crichton"
       },
@@ -132,11 +132,11 @@ Our server would then respond to the query with results that match the query's s
 
 Although it might be useful in some cases to fetch these two separate lists, a client would probably prefer to fetch a single list of books, where each book's author is included in the result.
 
-Because our schema's `Book` type has an `author` field of type `Author`, a client could structure their query like so:
+Because our schema's `Book` type has an `author` field of type `Author`, a client could instead structure their query like so:
 
 ```graphql
-query {
-  getBooks {
+query GetBooks {
+  books {
     title
     author {
       name
@@ -150,7 +150,7 @@ And once again, our server would respond with results that match the query's str
 ```json
 {
   "data": {
-    "getBooks": [
+    "books": [
       {
         "title": "Jurassic Park",
         "author": {
@@ -165,9 +165,9 @@ And once again, our server would respond with results that match the query's str
 
 ### The `Mutation` type
 
-The `Mutation` type is similar in structure and purpose to the [`Query` type](#the-query-type). Whereas the `Query` type defines your data graph's supported _read_ operations, the `Mutation` type defines supported _write_ operations.
+The `Mutation` type is similar in structure and purpose to the [`Query` type](#the-query-type). Whereas the `Query` type defines entry points for _read_ operations, the `Mutation` type defines entry points for _write_ operations.
 
-Each field of the `Mutation` type defines the signature and return type of a different mutation. The `Mutation` type for our example schema might resemble the following:
+Each field of the `Mutation` type defines the signature and return type of a different entry point. The `Mutation` type for our example schema might resemble the following:
 
 ```graphql
 type Mutation {
@@ -182,7 +182,7 @@ This `Mutation` type defines a single available mutation, `addBook`. The mutatio
 Like queries, mutations match the structure of your schema's type definitions. The following mutation creates a new `Book` and requests certain fields of the created object as a return value:
 
 ```graphql
-mutation {
+mutation CreateBook {
   addBook(title: "Fox in Socks", author: "Dr. Seuss") {
     title
     author {