Merge pull request #409 from apollographql/adam/19/4/some-typos

typos

docs/source/intro/platform.md

@@ -33,7 +33,7 @@ are:
    queries as part of UI components; the client manages all the hairy
    details of binding query results to the UI, managing consistency,
    caching, and so on. Apollo Client also supports an
-   exceptionally elegant approach to state managment by *extending* the
+   exceptionally elegant approach to state management by *extending* the
    GraphQL schema inside the client with additional structure. Apollo Client
    includes integrations for React, React Native, Vue, Angular, and
    other view layers.

docs/source/platform/editor-plugins.md

@@ -22,7 +22,7 @@ The [VS Code extension](https://marketplace.visualstudio.com/items?itemName=apol
 
 <h2 id="getting-started">Getting started</h2>
 
-To get all of the benefits of the VS Code experience, its best to link the schema that is being developed against **before** installing the extension. The best way to do that is by [publishing a schema](./schema-registry.html#publish) to the Apollo schema registry. Once that is done, two steps are needed:
+To get all of the benefits of the VS Code experience, it's best to link the schema that is being developed against **before** installing the extension. The best way to do that is by [publishing a schema](./schema-registry.html#publish) to the Apollo schema registry. Once that is done, two steps are needed:
 
 1. Create an `apollo.config.js` at the root of the project
 2. Copy an API key from the Engine dashboard of the published service

docs/source/platform/integrations.md

@@ -6,7 +6,7 @@ description: Integrate Apollo tools with the existing parts of your workflow
 One of our fundamental beliefs is that our Apollo workflows should hook into and enhance the workflows you're already using. As such, we've built a number of integrations into third-party services that are common in the developer world:
 
 1. [**GitHub**](#github) –– Ensure the safe evolution of your GraphQL schema by adding schema change validation directly to your continuous integration and GitHub checks.
-1. [**Slack**](#slack) –– Get a daily summary of key information from your server, including the overall request rate, error rate, and performance latenty. Set up notifications for noteworthy events in your service, like increases in errors or particularly slow response times for important queries.
+1. [**Slack**](#slack) –– Get a daily summary of key information from your server, including the overall request rate, error rate, and performance latency. Set up notifications for noteworthy events in your service, like increases in errors or particularly slow response times for important queries.
 1. [**Datadog**](#datadog) –– Forward the key metrics and performance data available in the Engine UI to Datadog as well.
 
 <h2 id="github">GitHub</h2>
@@ -62,7 +62,7 @@ jobs:
           fi
 ```
 
-> **Note:** Your `apollo service:check` command needs a source to from which to fetch your schema. This is most commonly provided as a URL to a running server (with introspection enabled), but can also be provided as a path to a file with your shcema in it. See other options [here](/docs/platform/schema-registry.html#setup).
+> **Note:** Your `apollo service:check` command needs a source to from which to fetch your schema. This is most commonly provided as a URL to a running server (with introspection enabled), but can also be provided as a path to a file with your schema in it. See other options [here](/docs/platform/schema-registry.html#setup).
 
 The `apollo schema:check` command checks for differences in your schema between what's on your current branch and the last version you uploaded to Engine. If you've removed or changed any types or fields, it will validate that those changes won't break any of the queries that your clients have made recently. If your changes do break any queries, the check will fail.
 
@@ -105,7 +105,7 @@ We've constructed the report provided to give you an actionable summary of what'
 
 <h3 id="slack-notifications">Notifications</h3>
 
-In the Engine UI you can configure notifications that are triggered on the performance data of your service, like error percentages and request latencies. This is particularly useful for detecting anomolies, especially around releases. Notifications can be configured to monitor the following metrics for either your entire GraphQL service or individual operations:
+In the Engine UI you can configure notifications that are triggered on the performance data of your service, like error percentages and request latencies. This is particularly useful for detecting anomalies, especially around releases. Notifications can be configured to monitor the following metrics for either your entire GraphQL service or individual operations:
 
 - **Request rate:**  requests per minute
 - **Request duration:** p50/p95/p99 service time

docs/source/platform/operation-registry.md

@@ -95,7 +95,7 @@ npx apollo client:push              \
     --includes="src/**/*.{ts,js,graphql}"
 ```
 
-When succesfull, the output from this command should look similar to the following:
+When successful, the output from this command should look similar to the following:
 
 ```
 ✔ Loading Apollo project

docs/source/platform/setup-analytics.md

@@ -70,7 +70,7 @@ As mentioned, this batch of traces and context is encoded via protobuf. The sche
 
 As a good starting point, we recommend implementing an extension to the GraphQL execution that creates a report with one trace, as defined in the `Trace` message of [the protobuf schema](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-engine-reporting-protobuf/reports.proto#L9). The next step will be to batch multiple traces into a single report, which we recommend batches of 5-10 seconds while limiting reports to a reasonable size (~4MB).
 
->Many server runtimes already have support for emitting tracing information as a [GraphQL extension](https://github.com/apollographql/apollo-tracing), which involves hooking into the request pipeline and capturing timing and error data about each resolver's execution. These implmentations include runtimes in [Node](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-engine-reporting/src/extension.ts), [Ruby](https://github.com/uniiverse/apollo-tracing-ruby), [Scala](https://github.com/sangria-graphql/sangria-slowlog#apollo-tracing-extension), [Java](https://github.com/graphql-java/graphql-java/pull/577), [Elixir](https://github.com/sikanhe/apollo-tracing-elixir), and [.NET](https://graphql-dotnet.github.io/docs/getting-started/metrics/). If you're working on adding metrics reporting functionality for one of _these languages_, reading through that tracing instrumentation is a good place to start and to plug into. For _other languages_, we recommend reading through the Apollo Server instrumentation [here](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-engine-reporting/src/extension.ts) as reference.
+>Many server runtimes already have support for emitting tracing information as a [GraphQL extension](https://github.com/apollographql/apollo-tracing), which involves hooking into the request pipeline and capturing timing and error data about each resolver's execution. These implementations include runtimes in [Node](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-engine-reporting/src/extension.ts), [Ruby](https://github.com/uniiverse/apollo-tracing-ruby), [Scala](https://github.com/sangria-graphql/sangria-slowlog#apollo-tracing-extension), [Java](https://github.com/graphql-java/graphql-java/pull/577), [Elixir](https://github.com/sikanhe/apollo-tracing-elixir), and [.NET](https://graphql-dotnet.github.io/docs/getting-started/metrics/). If you're working on adding metrics reporting functionality for one of _these languages_, reading through that tracing instrumentation is a good place to start and to plug into. For _other languages_, we recommend reading through the Apollo Server instrumentation [here](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-engine-reporting/src/extension.ts) as reference.
 
 An example of a FullTracesReport message, represented as JSON, can be found below*
 
@@ -112,7 +112,7 @@ query AuthorForPost {
 }
 ```
 
-Even though this concept lacks definition, it's important to decide on how queries shoudld be grouped together when tracking metrics about GraphQL execution. The concept of a **"query signature"** is what we use at Apollo to group similar operations together even if their exact textual representations are not identical. The query signature, along with the operation name, are used to group queries together in the `FullTracesReport`.
+Even though this concept lacks definition, it's important to decide on how queries should be grouped together when tracking metrics about GraphQL execution. The concept of a **"query signature"** is what we use at Apollo to group similar operations together even if their exact textual representations are not identical. The query signature, along with the operation name, are used to group queries together in the `FullTracesReport`.
 
 The TypeScript reference implementation uses a default signature method and allows for that signature method to also be overridden by the user. The [implementation of the default](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-engine-reporting/src/signature.ts) drops unused fragments and/or operations, hides String literals, ignores aliases, sorts the tree deterministically, and ignores whitespace differences. We recommend using the same default signature method for consistency across different server runtimes.
 

docs/source/references/engine-proxy-1.0-migration.md

@@ -74,7 +74,7 @@ Notable differences:
 For full details including an API reference, see [the Node setup guide](./setup-node.html).
 
 
-<h3 id="behind-the-schenes">Behind the scenes</h3>
+<h3 id="behind-the-scenes">Behind the scenes</h3>
 
 The old API was based on "double proxying". If your web server was supposed to serve on port 4000, you would tell Express (or your other web framework) to listen on port 4000. The `Engine` class would start an instance of the Engine Proxy running on an ephemeral port (say, 4321). You would add a special middleware to your framework which redirects GraphQL requests to `127.0.0.1:4321`. The Engine Proxy would then make GraphQL requests back to your Node server on port 4000.  The middleware used a special header to differentiate between the initial request from an external client and the nearly-identical internal request from Engine. So GraphQL requests are routed `client -> Node -> Engine Proxy -> Node` and non-GraphQL requests are routed `client -> Node`.
 

docs/source/references/engine-proxy-release-notes.md

@@ -73,7 +73,7 @@ Features that used to depend on a caching store definition now are on by default
 * The public full-query response cache is enabled by default. Only responses annotated with the `cache-control` extension are cached.
 * The private full-query response cache is enabled by default if `sessionAuth` is configured. Only responses annotated with the `cache-control` extension are cached.
 * Automatic persisted queries are on by default.
-* If `sessionAuth` is configured with a `tokenAuthUrl`, verifications are cacheed by default.
+* If `sessionAuth` is configured with a `tokenAuthUrl`, verifications are cached by default.
 If you don't like these defaults, you can set each store name field to `"disabled"` to turn off the relevant feature. If you want to change the default cache size in bytes, add `stores: [{inMemory: {cacheSize: 123456}}]` to your Engine config (ie, the argument to `new ApolloEngine()`). If you want to change the default cache to memcached, add `stores: [{memcache: {url: ["localhost:1234"]}}]` to your Engine config.
 
 Starting with v1, the Docker container releases use the same version numbers as the `apollo-engine` npm releases. The following changes are mostly relevant to users of the Docker container:

docs/source/resources/graphql-glossary.md

@@ -109,8 +109,7 @@ type User {
 A file or request string that contains one or multiple definitions of a GraphQL type system and can be interpreted by a GraphQL execution engine.
 
 <h2 id="extensions">Extensions</h2>
-
-Special fields in the Graphql response that allows you to attach extra metadata. [Apollo tracing](https://github.com/apollographql/apollo-server/tree/master/packages/apollo-tracing) is an example of an extension.
+Special fields in the GraphQL response that allows you to attach extra metadata. [Apollo tracing](https://github.com/apollographql/apollo-server/tree/master/packages/apollo-tracing) is an example of an extension.
 
 <h2 id="field">Field</h2>
 

docs/source/tutorial/resolvers.md

@@ -5,7 +5,7 @@ description: Learn how a GraphQL query fetches data
 
 Time to accomplish: _15 Minutes_
 
-Up until now, our graph API hasn't been very useful. We can inspect our graph's schema, but we can't actually run queries against it. Now that we've built our schema and data sources, it's time to leverage all of our hard work by calling our data sources in our graph API's resolver functions to possibly trigger business logic and/or to fetch and/or update data. 
+Up until now, our graph API hasn't been very useful. We can inspect our graph's schema, but we can't actually run queries against it. Now that we've built our schema and data sources, it's time to leverage all of our hard work by calling our data sources in our graph API's resolver functions to possibly trigger business logic and/or to fetch and/or update data.
 
 <h2 id="resolver-api">What is a resolver?</h2>
 
@@ -47,7 +47,7 @@ Apollo Server will automatically add the `launchAPI` and `userAPI` to our resolv
 
 <h2 id="query">Write Query resolvers</h2>
 
-First, let's start by writing our resolvers for the `launches`, `launch`, and `me` fields on our `Query` type. We structure our resolvers into a map where the keys correspond to the types and fields in our schema. If you ever get stuck remembering which fields are on a type, you can always check your graph API's schema. 
+First, let's start by writing our resolvers for the `launches`, `launch`, and `me` fields on our `Query` type. We structure our resolvers into a map where the keys correspond to the types and fields in our schema. If you ever get stuck remembering which fields are on a type, you can always check your graph API's schema.
 
 Navigate to `src/resolvers.js` and paste the code below into the file:
 
@@ -162,7 +162,7 @@ type LaunchConnection { # add this below the Query type as an additional type.
 
 You'll also notice we've added comments (also called docstrings) to our schema, indicated by `"""`. Now, the `launches` query takes in two parameters, `pageSize` and `after`, and returns a `LaunchConnection`. The `LaunchConnection` type returns a result that shows the list of launches, in addition to a `cursor` field that keeps track of where we are in the list and a `hasMore` field to indicate if there's more data to be fetched.
 
-Open up the `src/utils.js` file in the repo you cloned in the previous section and check out the `paginateResults` function. The `paginateResults` function in the file is a helper function for paginating data from the server. Now, let's update the necessary resolver functions to accomodate pagination.
+Open up the `src/utils.js` file in the repo you cloned in the previous section and check out the `paginateResults` function. The `paginateResults` function in the file is a helper function for paginating data from the server. Now, let's update the necessary resolver functions to accommodate pagination.
 
 Let's import `paginateResults` and replace the `launches` resolver function in the `src/resolvers.js` file with the code below:
 
@@ -274,7 +274,7 @@ Access control is a feature that almost every app will have to handle at some po
 Here are the steps you'll want to follow:
 1. The context function on your `ApolloServer` instance is called with the request object each time a GraphQL operation hits your API. Use this request object to read the authorization headers.
 2. Authenticate the user within the context function.
-3. Once the user is authenticated, attach the user to the object returned from the context function. This allows us to read the user's information from within our data sources and resolvers, so we can authorize whether they can access the data. 
+3. Once the user is authenticated, attach the user to the object returned from the context function. This allows us to read the user's information from within our data sources and resolvers, so we can authorize whether they can access the data.
 
 Let's open up `src/index.js` and update the `context` function on `ApolloServer` to the code shown below:
 
@@ -367,7 +367,7 @@ Both `bookTrips` and `cancelTrips` must return the properties specified on our `
 
 <h3 id="mutation-playground">Run mutations in the playground</h3>
 
-It's time for the fun part - running our mutations in the playground! Go back to the playground in your browser and reload the schema with the little return arrow at the top on the right of the address line. 
+It's time for the fun part - running our mutations in the playground! Go back to the playground in your browser and reload the schema with the little return arrow at the top on the right of the address line.
 
 GraphQL mutations are structured exactly like queries, except they use the `mutation` keyword. Let's copy the mutation below and run in the playground: