Merge branch 'master' into adam/19/4/client-id-ep

docs/source/intro/platform.md

@@ -22,7 +22,7 @@ are:
 
  * **Apollo Server** is a JavaScript GraphQL server for defining a
    *schema* and a set of *resolvers* that implement each part of that
-   *schema. Typically  Apollo Server is extensible: plugins can hook in to each stage of the
+   schema. Typically  Apollo Server is extensible: plugins can hook in to each stage of the
    request pipeline and server's own lifecycle, making it possible to
    implement custom behaviors in add-on packages. Apollo Server supports
    AWS Lambda and other serverless environments.

docs/source/platform/schema-registry.md

@@ -1,11 +1,15 @@
 ---
-title: Tracking schema change history
-description: Connect to the Apollo schema registry and track changes in your schema over time
+title: Tracking your GraphQL schema
+description: A central hub for your GraphQL API
 ---
 
-As GraphQL scales in an organization, teams often find that growing and evolving their schema over time becomes difficult to manage. Product teams want to move fast with GraphQL, but they also want reassurance that their code changes won't break existing clients. At scale, you might have hundreds of clients querying against a single schema. How can we ensure that adding or removing a field, type, or argument won't break existing clients and cause a service outage?
+Apollo includes a schema registry that serves as a [central hub](https://principledgraphql.com/integrity#3-track-the-schema-in-a-registry) for tracking your GraphQL schema. Adopting a shared schema registry for your project has many benefits:
 
-The [Apollo platform](/docs/intro/platform.html) includes a free schema registration service to help teams of all sizes easily evolve their API over time. Just like it's important to track source code in a version control system, it's a [best practice](https://principledgraphql.com/integrity#3-track-the-schema-in-a-registry) to track the definition of your graph in a schema registry. Once a team registers its schema with Apollo, developers have visibility into when a change was made, who made the change, and the type of change. The registry also supports tracking multiple variants of the graph (for example, staging vs. production).
+- Unlike introspection, which provides a snapshot of a particular server's current schema, the registry serves as a global source of truth for the schema. In small projects this frees you from always needing a running server to access the schema. At scale, it avoids issues related to running multiple servers that may not always be in sync (eg, rolling updates).
+- Much like a source control system, Apollo's schema registry tracks a full history of a schema and how it changed over time. This is valuable for understanding and collaborating on a GraphQL API, especially as your team grows.
+- Having a registry allows you to disable introspection in production – a recommended best practice for good security.
+- Tools like the [Apollo VS Code extension](https://marketplace.visualstudio.com/items?itemName=apollographql.vscode-apollo) automatically fetch schema definitions from the registry.
+- Apollo's registry lets you track related _variants_ of a schema, like staging or alpha versions. It's helpful to have these schema definitions handy without having to juggle running servers that implement them.
 
 <h2 id="setup">Using the Schema Registry</h2>
 

docs/source/references/engine-proxy.md

@@ -3,6 +3,8 @@ title: Apollo Engine proxy (deprecated)
 description: Configuring and running the Engine proxy
 ---
 
+> DEPRECATED: The engine proxy is not maintained, and to integrate with the Apollo platform's metrics, we recommend using Apollo Server's native reporting functionality. To integrate a non-Node server, take a look at our guide [here](https://www.apollographql.com/docs/platform/setup-analytics#other-servers)
+
 ## Background
 
 The Apollo Engine proxy is a small process that can be run in front of your GraphQL server. Its primary functions are:
@@ -10,11 +12,10 @@ The Apollo Engine proxy is a small process that can be run in front of your Grap
 1. Proving a **full query caching** layer, which is controlled using the [`cacheControl`](https://github.com/apollographql/apollo-cache-control) directive and configured to be either in-memory or shared through Memcache.
 1. Automatically **persisting queries** through a caching layer that can map query IDs to full query strings, allowing clients to send just query IDs over the wire.
 
-The proxy has been **deprecated since Apollo Server 2** was released. Apollo Server 2+ has [metrics reporting](https://www.apollographql.com/docs/apollo-server/features/metrics.html), [data source caching](https://www.apollographql.com/docs/apollo-server/features/data-sources.html), and [persisted queries](https://www.apollographql.com/docs/apollo-server/whats-new.html#Automatic-Persisted-Queries) as built-in features, and using it allows you to forego running the proxy. The newest features in Apollo Engine are not supported in the Engine proxy and we recommend that all Node users use Apollo Server 2+ instead running the proxy.
+The proxy has been **deprecated since Apollo Server 2** was released. Apollo Server 2+ has [metrics reporting](https://www.apollographql.com/docs/apollo-server/features/metrics.html), [data source caching](https://www.apollographql.com/docs/apollo-server/features/data-sources.html), [persisted queries](https://www.apollographql.com/docs/apollo-server/whats-new.html#Automatic-Persisted-Queries), and [full query caching](https://github.com/apollographql/apollo-server/blob/release-2.5.0/docs/source/features/caching.md) (strarting at Apollo Server 2.5) as built-in features, and using it allows you to forego running the proxy. The newest features in Apollo Engine are not supported in the Engine proxy and we recommend that all Node users use Apollo Server 2+ instead running the proxy.
 
 That said, the proxy is still a good option for getting set up with Engine in a few **specific** circumstances:
 1. You are not using Apollo Server, your server has an [`apollo-tracing`](https://github.com/apollographql/apollo-tracing) plugin, and you want to get **performance metrics** insights.
-1. You are relying on **full query caching** in your infrastructure.
 1. You are not using Apollo Server and you want to use Apollo's **automatic persisted queries**.
 
 ## Setup
@@ -74,7 +75,7 @@ Option 1: Running the proxy with Apollo Server
 
 The two cases where you should be running the Engine proxy with Apollo Server are:
 1. You are using Apollo Server 1 and want the Apollo platform features that Engine brings.
-1. You are using Apollo Server 2+ and want full query caching using the Engine proxy.
+1. You are using Apollo Server >2 & <2.5+ and want full query caching using the Engine proxy.
 
 > **Note:** If you're using Apollo Server but neither of these conditions apply to you, you should be using the built-in features of Apollo Server 2+ instead of the Engine proxy.
 
@@ -307,7 +308,7 @@ If you've got a proxy running and successfully configured to talk to your cloud
 
 ## Feature configuration
 
-The following proxy features require specific setup steps to get working. Full query caching is the only proxy feature that hasn't been built-in to Apollo Server 2.
+The following proxy features require specific setup steps to get working.
 1. [Automatically **persisting** your queries](#automatic-persisted-queries)
 1. [**Caching** full query responses](#caching)
 1. [Integrating with your **CDN**](#cdn)

docs/source/tutorial/local-state.md

@@ -249,6 +249,12 @@ export default function LogoutButton() {
     </ApolloConsumer>
   );
 }
+
+const StyledButton = styled("button")(menuItemClassName, {
+  background: "none",
+  border: "none",
+  padding: 0
+});
 ```
 
 When we click the button, we perform a direct cache write by calling `client.writeData` and passing in a data object that sets the `isLoggedIn` boolean to false.