Merge branch 'master' into patch-1

docs/_config.yml

@@ -33,6 +33,8 @@ sidebar_categories:
     - platform/integrations
 
   Resources:
+    - title: Principled GraphQL
+      href: https://www.principledgraphql.com
     - resources/graphql-glossary
     - resources/faq
 

docs/source/intro/platform.md

@@ -49,7 +49,7 @@ are:
 
  * **Schema registry** — a registry for GraphQL schemas that acts
    as a central source of truth for a schema, enriched with additional
-   metadata like field-level usage statisics.
+   metadata like field-level usage statistics.
 
  * **Client registry** — a registry to track each known consumer
    of a schema, which can include both pre-registered and ad-hoc clients.

docs/source/platform/client-awareness.md

@@ -64,10 +64,9 @@ Similarly to deprecation, additions to a GraphQL api often mean that clients wil
 ![druid cutover](../img/client-awareness/cutover.png)
 
 
-## Advanced Setup
+## Advanced setup
 
-Client awareness is a full stack solution that threads client information from
-the consumer to server, so we can configure the client and server.
+The _Setup_ section above should cover most use cases with no additional configuration, but if more precise control is necessary (for example, when using a non-Apollo client or server), the following examples should be useful.
 
 ### Client
 
@@ -75,20 +74,26 @@ The client or consumer of the GraphQL api is responsible for including the
 information in a way that the server understands. In this case, we add the
 client name and version to the http headers:
 
-```js line=8-11
-import { ApolloClient } from 'apollo-client';
-import { HttpLink } from 'apollo-link-http';
-import { ApolloLink } from 'apollo-link';
+```js line=8-16
+import { ApolloClient } from "apollo-client";
+import { HttpLink } from "apollo-link-http";
+import { ApolloLink } from "apollo-link";
 
 const client = new ApolloClient({
   link: new HttpLink({
-    uri: 'http://localhost:4000/graphql',
+    uri: "http://localhost:4000/graphql",
+    // As noted in the "Setup" instructions above, Apollo
+    // Server and Client handle this setup automatically.
+    // For advanced cases, rather than setting the `name`
+    // and `version` on `ApolloClient`, `headers`
+    // can be specified on the `HttpLink` directly.
     headers: {
-      'client-name': 'Web',
-      'client-version': '1',
-    },
-  }),
+      "client-name-for-advanced-use-cases": "Web",
+      "client-version-for-advanced-use-cases": "1"
+    }
+  })
 });
+
 ```
 
 ### Server
@@ -98,24 +103,30 @@ to a request. To provide metrics to the Apollo Platform, pass a
 `generateClientInfo` function into the `ApolloServer` constructor. The
 following checks the headers and provides a fallback.
 
-```js line=8-16
-const { ApolloServer } = require('apollo-server');
+```js line=8-22
+const { ApolloServer } = require("apollo-server");
 
 const server = new ApolloServer({
   typeDefs,
   resolvers,
   engine: {
-    apiKey: 'YOUR API KEY HERE',
-    generateClientInfo: ({
-      request
-    }) => {
-      const headers = request.headers;
+    apiKey: "YOUR API KEY HERE",
+    generateClientInfo: ({ request }) => {
+      // The default approach suggested in "Setup", which
+      // uses headers provided by Apollo Client, should work
+      // for most use cases, but advanced cases can use
+      // their own logic for determining the client name
+      // and version and return them from this function.
+      const {
+        clientName,
+        clientVersion
+      } = userSuppliedLogic(request);
       return {
-        clientName: headers && headers['client-name'] || 'Unknown Client',
-        clientVersion: headers && headers['client-version'] || 'Unversioned',
+        clientName,
+        clientVersion
       };
-    },
-  },
+    }
+  }
 });
 
 server.listen().then(({ url }) => {

docs/source/platform/editor-plugins.md

@@ -3,28 +3,26 @@ title: Editor plugins
 description: How to get the most out of your editor with Apollo
 ---
 
-By design, GraphQL has the ability to create incredible developer experiences thank's to its strongly typed schema and query language. The Apollo GraphQL Platform brings these possibilities to life with deep editor integrations. Currently only [VS Code](https://code.visualstudio.com/) is supported, but more are coming soon.
+GraphQL has the potential to create incredible developer experiences, thanks to its strongly typed schema and query language. The Apollo platform brings these possibilities to life by enhancing your editor with rich metadata from your graph API. Currently only [Visual Studio Code](https://code.visualstudio.com/) (VS Code) is supported, but more are coming soon.
 
-<h2 id="vscode">Getting started with Apollo and VS Code</h2>
+<img src="../images/editors/jump-to-def.gif" width="80%" style="margin: 5%" alt="Using jump to definition on a fragment">
+
+<h2 id="vscode">Apollo VS Code</h2>
 
 The [VS Code extension](https://marketplace.visualstudio.com/items?itemName=apollographql.vscode-apollo) for Apollo brings an all-in-one tooling experience for developing apps with Apollo.
 
-* Get instant feedback and intelligent autocomplete as you write queries
-* Seamlessly manage your client side schema alongside your remote one
-* See performance information inline with your query definitions
-* Loads GraphQL schemas and queries automatically from an Apollo Config file
-* Adds syntax highlighting for GraphQL files and gql templates inside JavaScript files
-* Code-completes fields, arguments, types, and variables in your queries
-* Detects and loads client side schemas and validates client side field usage in operations
-* Displays performance statistics from Engine inline with your queries
-* Jump-to-definition for fragments and schema types
-* Detects fragment references and shows them next to definitions
+- Add [syntax highlighting](#syntax) for GraphQL files and gql templates inside JavaScript files
+- Get instant feedback and [intelligent autocomplete](#autocomplete) for fields, arguments, types, and variables as you write queries
+- Seamlessly manage your client side schema alongside your remote one
+- [See performance information](#performance-insights) inline with your query definitions
+- Validate field and argument usage in operations
+- [Navigate projects](#navigating-projects) easier with jump-to and peek-at definitions and more
+- Manage [client-only](#client-only-schemas) schemas
+- [Switch schema tags](#commands) to work on upcoming features
 
-To get started, first install the extension by using this [link](https://marketplace.visualstudio.com/items?itemName=apollographql.vscode-apollo) or by searching `Apollo` in the VS Code extension marketplace. After installation, GraphQL syntax highlighting should be enabled for `.graphql`, `.gql`, `.js` and `.ts` file types.
+<h2 id="getting-started">Getting started</h2>
 
-<h2 id="linking-a-schema">Linking a schema</h2>
-
-To get all of the benefits of the VS Code experience, its best to link the schema that is being developed against. 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, 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:
 
 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
@@ -57,7 +55,7 @@ ENGINE_API_KEY=<enter copied key here>
 
 After this is done, VS Code can be restarted and the editor integration will start providing autocomplete, validation, and more!
 
-<h2 id="local-schemas">Local schemas</h2>
+<h3 id="local-schemas">Local schemas</h3>
 
 Sometimes it may make sense to link the editor to a locally running version of a schema to try out new designs that are in active development. To do this, the `apollo.config.js` file can be linked to a local service definition:
 
@@ -76,11 +74,11 @@ module.exports = {
 
 More information about configuring an Apollo project can be found [here](../platform/apollo-config.html)
 
-<h2 id="client-side-schemas">Client side schemas</h2>
+<h3 id="client-only-schemas">Client-only schemas</h3>
 
-One of the best features of the VS Code extension is the automatic merging of remote schemas and local ones when using integrated state management with Apollo Client. This happens automatically whenever schema definitions are found within a client project.
+One of the best features of the VS Code extension is the automatic merging of remote schemas and local ones when using integrated state management with Apollo Client. This happens automatically whenever schema definitions are found within a client project. By default, the VS Code extension will look for all files under `./src` to find both the operations and schema definitions for building a complete schema for the application.
 
-Client side schema definitions can be spread throughout the client app project and will be merged together to create one single schema. This can be controlled through the `apollo.config.js` at the root of he project:
+Client side schema definitions can be spread throughout the client app project and will be merged together to create one single schema. If the default behavior isn't ideal, this can be controlled through the `apollo.config.js` at the root of the project:
 
 ```js
 module.exports = {
@@ -92,18 +90,69 @@ module.exports = {
 }
 ```
 
-By default, the VS Code extension will look for all files under "./src" to find both the operations and schema definitions for building a complete schema for the application.
+<h3 id="get-the-extension">Get the extension</h3>
 
-<h2 id="performance-insights">Performance insights</h2>
+Once you have a config set up and a schema published, **install the Apollo GraphQL extension** by using this [link](https://marketplace.visualstudio.com/items?itemName=apollographql.vscode-apollo) or by searching `Apollo` in the VS Code extension marketplace. After installation, try opening a file containing a GraphQL operation.
 
-GraphQL operations provide incredible flexibilty in what data is requested from a service. This can sometimes lead to unknown performance characteristics of how an operation will run. Thanks to the trace wharehouse in the Apollo GraphQL Platform, teams no longer will be surprised by how long an operation takes.
+When a file open, clicking the status bar icon will open the output window and print stats about the project associated with that file. This is helpful when confirming the project is setup properly.
+
+<img src="../images/editors/stats.gif" width="80%" style="margin: 5%" alt="Clicking the status bar icon to open the output pane">
+
+<h2 id="features">Features</h2>
+
+Apollo for VS Code brings many helpful features for working on a GraphQL project.
+
+<h3 id="autocomplete">Intelligent autocomplete</h3>
+
+Once configured, editors have full knowledge of the schema clients are running operations against, including client-only schemas (for things like local state mutations). Because of this, editors have the ability to autocomplete fields and arguments as you type.
+
+<img src="../images/editors/autocomplete.gif" width="80%" style="margin: 5%" alt="vscode completing a field when typing">
+
+<h3 id="errors-and-warnings">Inline errors and warnings</h3>
+
+Editors can use local or published schemas to validate operations before running them. **Syntax errors**, **invalid fields or arguments**, and even **deprecated fields** instantly appear as errors or warnings right in your editor, ensuring all developers are working with the most up-to-date production schemas.
+
+<img src="../images/editors/warnings-and-errors.gif" width="80%" style="margin: 5%" alt="tooltip showing a field deprecation warning and error">
+
+<h3 id="field-type-info">Inline field type information</h3>
+
+Because of GraphQL's strongly-typed schema, editors not only know about which fields and arguments are valid, but also what types are expected. Hover over any type in a valid GraphQL operation to see what type that field returns and whether or not it can be null.
+
+<img src="../images/editors/type-info.png" width="80%" style="margin: 5%" alt="a tooltip showing a Boolean type for a field">
+
+<h3 id="performance-insights">Performance insights</h3>
+
+GraphQL's flexibility can make it difficult to predict the cost of an operation. Without insight into how expensive an operation is, developers can accidentally write queries that place strain on their graph API's underlying backends. Thanks to the Apollo platform's integration with VS Code and our trace warehouse, teams can avoid these performance issues altogether by instantly seeing the cost of a query right in their editor.
+
+To turn on tracing for your GraphQL server, please visit our [guide](./setup-analytics.html).
 
 The VS Code extension will show inline performance diagnostics when connected to a service with reported metrics in Engine. As operations are typed, any fields that take longer than 1ms to respond will be annoated to the right of the field inline! This gives team members a picture of how long the operation will take as more and more fields are added to operations or fragments.
 
-<h2 id="commands">Apollo commands</h2>
-The VS Code extension integrates with the VS Code command palate and provides two commands currently:
+<img src="../images/editors/perf-annotation.png" width="80%" style="margin: 5%" alt="Performance annotation next to a field">
 
-* switch schema tags
-* reload the schema and diagnostics
+<h3 id="syntax">Syntax highlighting</h3>
 
-These can be run by typing `cmd+shift+p` then typing `apollo` into thr prompt. That will show the two commands which can help teams stay on top of changes to the schema right in their editors
+Apollo's editor extension provides syntax highlighting for all things GraphQL, including schema definitions in `.graphql` files, complex queries in TypeScript, and even client-only schema extensions. Syntax highlighting for GraphQL works out-of-the-box for `.graphql`, `.gql`, `.js` and `.ts` file types!
+
+<h3 id="navigating-projects">Navigating projects</h3>
+
+Navigating large codebases can be difficult, but the Apollo GraphQL extension makes this easier than ever. Right-clicking on any field in operations or schemas gives you the ability to jump to (or peek at) definitions, as well as find any other references to that field in your project. Searching a project for any occurrence of a certain field is now a thing of the past!
+
+<img src="../images/editors/jump-to-def.gif" width="80%" style="margin: 5%" alt="Using jump to definition on a fragment">
+
+<h3 id="commands">Schema tag switching</h3>
+
+The Apollo GraphQL platform supports publishing multiple versions (tags) of a schema. This is useful for developing on a future development schema and preparing your clients to conform to that schema. To choose another schema tag, open the Command Palette (`cmd + shift + p` on mac), search "Apollo" and choose the "Apollo: Select Schema Tag" option.
+
+<h2 id="troubleshooting">Troubleshooting</h2>
+
+The most common errors are configuration errors, like a missing `.env` file or incorrect service information in the `apollo.config.js` file.
+There is more information about configuring an Apollo projects [here](../platform/apollo-config.html).
+
+Other errors may be caused from an old version of a published schema. To reload a schema, open the Command Palette (`cmd + shift + p` on mac), search "Apollo" and choose the "Apollo: Reload Schema" option.
+
+Sometimes errors will show up as a notification at the bottom of your editor. Other, less critical, messages may be shown in the output pane of the editor. To open the output pane and get diagnostic information about the extension and the current service loaded (if working with a client project), just click the "Apollo GraphQL" icon in the status bar at the bottom.
+
+<img src="../images/editors/stats.gif" width="80%" style="margin: 5%" alt="Clicking the status bar icon to open the output pane">
+
+If problems persist or the error messages are unhelpful, an [issue](https://github.com/apollographql/apollo-tooling/issues) can be opened on the `apollo-tooling` repository.

docs/source/platform/operation-registry.md

@@ -5,6 +5,8 @@ description: How to secure your graph with operation safelisting
 
 ## Overview
 
+> The operation registry is an Apollo Platform feature available on the [_Team_ and _Enterprise_ plans](https://www.apollographql.com/plans/).  To get started with the Apollo Platform, begin with [the documentation](https://www.apollographql.com/docs/).
+
 Any API requires security and confidence prior to going to production. During development, GraphQL offers front-end engineers the ability to explore all the data available to them and fetch exactly what they need for the components they're building. However, in production, it can be unnecessary and undesirable to provide this flexibility.
 
 The Apollo Operation Registry allows organizations to:
@@ -24,21 +26,28 @@ Operations defined within client applications are automatically extracted and up
   * To get started with Apollo Server, visit [its documentation](/docs/apollo-server/).
 * A client application which utilizes `gql` tagged template literals for its operations or, alternatively, stores operations in `.graphql` files.
 * An Apollo Engine API key.
-  * To grab a key, visit [Engine](https://engine.apollographql.com) and create a service.
+  * To obtain an API key, visit [Apollo Engine](https://engine.apollographql.com) and create a service.
 
 ### Installation steps
 
 > Make sure you've met the requirements for _Prerequisites_ above.
 
+These installation steps require access to both the client and server codebases to perform the following tasks:
+
+* The `apollo` CLI is used to search the client codebase for GraphQL operations and upload them to Apollo Engine.
+* Apollo Server is then configured with a plugin which fetches the manifest from Apollo Server and enforces safe-listing using that manifest.
+
+The following steps will walk through the steps necessary for both the client and server codebases.
+
 **1. Install the `apollo` command line tool as a development dependency of your client application:**
 
 ```
 npm install apollo --save-dev
 ```
 
-> Yarn users can run `yarn add apollo --dev`.
+> Yarn users should run `yarn add apollo --dev`.
 
-**2. Register the server's schema with Apollo:**
+**2. Push your schema to the Apollo schema registry:**
 
 > If this server's schema has already been registered using `apollo service:push`, you can skip this step. For additional options and details, see the [documentation for the schema registry](./schema-registry.html).
 
@@ -124,7 +133,7 @@ First, add the appropriate plugin to the Apollo Server's `package.json`:
 npm install apollo-server-plugin-operation-registry
 ```
 
-> Yarn uses run: `yarn add apollo-server-plugin-operation-registry`.
+> Yarn users should run: `yarn add apollo-server-plugin-operation-registry`.
 
 Next, the plugin must be enabled. This requires adding the appropriate module to the `plugins` parameter to the Apollo Server options:
 

docs/source/platform/schema-registry.md

@@ -44,7 +44,7 @@ To push a service, start the GraphQL server and run the following command, subst
 apollo service:push --key="<API_KEY>" --endpoint="https://example.com/graphql"
 ```
 
-> For accuracy, it's best to retrieve the schema from a running GraphQL server (with introspection enabled), though local files representing a schema can also be used. See the [configuration options](./platform/apollo-config.html) for more information.
+> For accuracy, it's best to retrieve the schema from a running GraphQL server (with introspection enabled), though local files representing a schema can also be used. See the [configuration options](../references/apollo-config.html) for more information.
 
 <h3 id="viewing-schema">Viewing a published schema</h3>
 

docs/source/platform/schema-validation.md

@@ -9,18 +9,17 @@ A GraphQL schema can change in a number of ways between releases and, depending
 
 By comparing a new schema to the last published schema, the Apollo Platform can highlight points of concern by showing detailed schema changes alongside current usage information for those fields. With this pairing of data, the risks of changes can be greatly reduced.
 
-
 <h2 id="versioning">Understanding schema changes</h2>
 
-Versioning is a technique to prevent necessary changes from becoming "breaking changes" which affect the existing consumers of an API.  These iterations might be as trivial as renaming a field, or as substantial as refactoring the whole data model.
+Versioning is a technique to prevent necessary changes from becoming "breaking changes" which affect the existing consumers of an API. These iterations might be as trivial as renaming a field, or as substantial as refactoring the whole data model.
 
-Developers who have worked with REST APIs in the past have probably recognized various patterns for versioning the API, commonly by using a different URI (e.g. `/api/v1`, `/api/v2`, etc.) or a query parameter (e.g. `?version=1`).  With this technique, an application can easily end up with many different API endpoints over time, and the question of _when_ an API can be deprecated can become problematic.
+Developers who have worked with REST APIs in the past have probably recognized various patterns for versioning the API, commonly by using a different URI (e.g. `/api/v1`, `/api/v2`, etc.) or a query parameter (e.g. `?version=1`). With this technique, an application can easily end up with many different API endpoints over time, and the question of _when_ an API can be deprecated can become problematic.
 
-It might be tempting to version a GraphQL API the same way, but it's unnecessary with the right techniques.  By following the strategies and precautions outlined in this guide and using Apollo tooling that adds clarity to every change, many iterations of an API can be served from a single endpoint.
+It might be tempting to version a GraphQL API the same way, but it's unnecessary with the right techniques. By following the strategies and precautions outlined in this guide and using Apollo tooling that adds clarity to every change, many iterations of an API can be served from a single endpoint.
 
 <h3 id="field-usage">Field usage</h3>
 
-Rather than returning extensive amounts of data which might not be necessary, GraphQL allows consumers to specify exactly what data they need.  This field-based granularity is valuable and avoids "over-fetching" but also makes it more difficult to understand what data is currently being used.
+Rather than returning extensive amounts of data which might not be necessary, GraphQL allows consumers to specify exactly what data they need. This field-based granularity is valuable and avoids "over-fetching", but also makes it more difficult to understand which parts of the schema are being used.
 
 To improve the understanding of field usage within an API, Apollo Server extends GraphQL with rich tracing data that demonstrates _how_ a GraphQL field is used and _when_ it's safe to change or eliminate a field.
 
@@ -34,13 +33,13 @@ We'll go over these two kinds of field rollovers separately and show how to make
 
 <h3 id="renaming-or-removing">Renaming or removing a field</h3>
 
-When a field is unused, renaming or removing it is as straightforward as it sounds: it can be renamed or removed.  Unfortunately, if a GraphQL deployment doesn't have per-field usage metrics, additional considerations should be made.
+When a field is unused, renaming or removing it is as straightforward as it sounds: it can be renamed or removed. However, if a GraphQL deployment doesn't have per-field usage metrics, additional considerations should be made. The following example demonstrates a safe approach to renaming a field.
 
 Take the following `user` query as an example:
 
 ```graphql
 type Query {
- user(id: ID!): User
+  user(id: ID!): User
 }
 ```
 
@@ -64,8 +63,8 @@ const getUserResolver = (root, args, context) => {
 const resolvers = {
   Query: {
     getUser: getUserResolver,
-    user: getUserResolver,
-  },
+    user: getUserResolver
+  }
 };
 ```
 
@@ -80,10 +79,10 @@ type Query {
 }
 ```
 
-GraphQL-aware client tooling, like GraphQL Playground and GraphiQL, use this information to assist developers in making the right choices.  These tools will:
+GraphQL-aware client tooling, like GraphQL Playground and GraphiQL, use this information to assist developers in making the right choices. These tools will:
 
-* Provide developers with the helpful deprecation message referring them to the new name.
-* Avoid auto-completing the field.
+- Provide developers with the helpful deprecation message referring them to the new name.
+- Avoid auto-completing the field.
 
 Over time, usage will fall for the deprecated field and grow for the new field.
 
@@ -125,7 +124,7 @@ If we wanted to leave the old `groupId` argument active, we wouldn't need to do
 
 Instead of supporting it, if we wanted to remove the old argument, the safest option would be to create a new field and deprecate the current `getUsers` field.
 
-Using an API management tool, like the Apollo platform, it’s possible to determine when usage of an old field has dropped to an acceptable level and remove it.  The previously discussed [field rollover](#field-rollover) section gives more info on how to do that.
+Using an API management tool, like the Apollo platform, it’s possible to determine when usage of an old field has dropped to an acceptable level and remove it. The previously discussed [field rollover](#field-rollover) section gives more info on how to do that.
 
 Of course, it’s also possible to leave the field in place indefinitely!
 
@@ -147,7 +146,33 @@ After analyzing the changes against current usage metrics, Apollo will identify
 2. **Warning**: There are potential problems that may come from this change, but no clients are immediately impacted.
 3. **Notice**: This change is safe and will not break current clients.
 
-The more [performance metrics](./performance.html) that Apollo has, the better the report of these changes will become.
+<h3 id="cli-advanced">Advanced CLI Usage</h3>
+
+Depending on the requirements of your application, you may want to configure the timeframe to validate operations against. You can do so by providing a `validationPeriod` flag to the CLI. The timeframe will always end at "now", and go back in time by the amount specified.
+
+```bash
+apollo service:check --validationPeriod=P2W
+```
+
+> Valid durations are represented in [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601#Durations). It can also be provided as a number in seconds, i.e. 86400 for a single day.
+
+Two other parameters for customizing the results of `service:check` are threshold values. For example, you may wish to drop support for an old version of an app in order to remove some deprecated fields. Using these parameters, you can decide what amount of breakage is acceptable before shipping any breaking changes.
+
+- `queryCountThreshold` - This flag will only validate the schema against operations that have been executed at least the specified number of times within the provided duration.
+- `queryCountThresholdPercentage` - Similar to `queryCountThreshold`, but expressed as a percentage of all operation volume.
+  > Note: these flags are compatible with each other. In the case that both are provided, an operation must meet or exceed both thresholds.
+
+If you have requests for other filtering or threshold mechanisms, we'd love to hear them! Please feel free to submit a [feature request](https://github.com/apollographql/apollo-tooling/issues/new?template=feature-request.md) or PR to the [apollo-tooling](https://github.com/apollographql/apollo-tooling/) repo.
+
+```bash
+apollo service:check \
+# Validate the schema against operations that have run in the last 5 days
+--validationPeriod=P5D \
+# Only validate against operations that have run at least 5 times during the 5 day duration
+--queryCountThreshold=5 \
+# Only validate against operations that account for at least 3% of total operation volume
+--queryCountThresholdPercentage=3
+```
 
 <h2 id="github">GitHub Integration</h2>
 

docs/source/tutorial/client.md

@@ -19,7 +19,7 @@ cd start/client && npm install
 
 Now, our dependencies are installed. Here are the packages we will be using to build out our frontend:
 
-- `apollo-client@alpha`: A complete data management solution with an intelligent cache. In this tutorial, we will be using the Apollo Client 3.0 preview since it includes local state management capabilities and sets your cache up for you.
+- `apollo-client`: A complete data management solution with an intelligent cache. In this tutorial, we will be using the Apollo Client 3.0 preview since it includes local state management capabilities and sets your cache up for you.
 - `react-apollo`: The view layer integration for React that exports components such as `Query` and `Mutation`
 - `graphql-tag`: The tag function `gql` that we use to wrap our query strings in order to parse them into an AST
 
@@ -93,7 +93,7 @@ _src/index.js_
 ```js line=1
 import gql from "graphql-tag";
 ```
-And add this code to the bottom of `index.js`: 
+And add this code to the bottom of `index.js`:
 
 _src/index.js_
 ```

docs/source/tutorial/introduction.md

@@ -67,6 +67,6 @@ TODO: Add in this section after Apollo VSCode works for server development
 
 <h3 id="help">Where can I get help?</h3>
 
-We know that learning a new technology can sometimes be overwhelming, and it's totally normal to get stuck! If that happens, we recommend joining the [Apollo Slack](https://www.apollographql.com/slack) community and posting in the relevant channel (either #apollo-server or #apollo-client) for some quick answers.
+We know that learning a new technology can sometimes be overwhelming, and it's totally normal to get stuck! If that happens, we recommend joining the [Apollo Spectrum](https://spectrum.chat/apollo) community and posting in the relevant channel (either #apollo-server or #apollo-client) for some quick answers.
 
 If something in the tutorial seems confusing or contains an error, we'd love your feedback! Just click the Edit on GitHub link at the bottom to open a new pull request or open an issue on the repository.