Merge pull request #7897 from apollographql/docs/update-router-terminology

docs: update router terminology

Author: Meschreiber

docs/source/api/plugin/subscription-callback.mdx

@@ -4,15 +4,15 @@ api_reference: true
 minVersion: 4.9.0
 ---
 
-This document covers the usage of the subscription callback plugin for use in Apollo Federation with Apollo Router. For more information about the protocol itself, see the [subscription callback protocol](/router/executing-operations/subscription-callback-protocol).
+This document covers the usage of the subscription callback plugin for use in Apollo Federation with GraphOS Router. For more information about the protocol itself, see the [subscription callback protocol](/router/executing-operations/subscription-callback-protocol).
 
 > ⚠️ **Note**: The subscription callback protocol is currently in [preview](/resources/product-launch-stages#preview). Breaking changes might be introduced during the preview period.
 
 ## Using the plugin
 
 This article documents the options for the `ApolloServerPluginSubscriptionCallback` plugin, which you can import from `@apollo/server/plugin/subscriptionCallback`.
 
-This plugin enables your GraphQL server to respond to [subscription operations](/apollo-server/data/subscriptions/) using the [subscription callback protocol](https://www.apollographql.com/docs/router/executing-operations/subscription-callback-protocol/#initialization).  Apollo Router uses this protocol to execute subscription operations and receive updates at a URL specified by the router.
+This plugin enables your GraphQL server to respond to [subscription operations](/apollo-server/data/subscriptions/) using the [subscription callback protocol](https://www.apollographql.com/docs/router/executing-operations/subscription-callback-protocol/#initialization).  GraphOS Router uses this protocol to execute subscription operations and receive updates at a URL specified by the router.
 
 This feature can only be enabled by providing an `ApolloServerPluginSubscriptionCallback` instance to your `ApolloServer` constructor:
 
@@ -58,7 +58,7 @@ The subscription plugin implementation inherently bypasses Apollo Server's reque
 </td>
 <td>
 
-Optionally configure the heartbeat interval in milliseconds. The default is 5 seconds, which is the interval that Apollo Router expects. Lengthening this interval may cause Apollo Router to invalidate existing subscriptions frequently and is not recommended. You may want to shorten this interval if you have latency issues between your GraphQL Server and Apollo Router.
+Optionally configure the heartbeat interval in milliseconds. The default is 5 seconds, which is the interval that GraphOS Router expects. Lengthening this interval may cause GraphOS Router to invalidate existing subscriptions frequently and is not recommended. You may want to shorten this interval if you have latency issues between your GraphQL Server and GraphOS Router.
 
 </td>
 </tr>
@@ -86,7 +86,7 @@ Optionally provide a [`Logger`](https://www.npmjs.com/package/@apollo/utils.logg
 </td>
 <td>
 
-This plugin uses the `async-retry` module to retry failed requests to Apollo Router. You can optionally provide an `Options` object to configure the retry behavior. The configuration options for `async-retry` can be found in the [README](https://www.npmjs.com/package/async-retry).
+This plugin uses the `async-retry` module to retry failed requests to GraphOS Router. You can optionally provide an `Options` object to configure the retry behavior. The configuration options for `async-retry` can be found in the [README](https://www.npmjs.com/package/async-retry).
 
 The default configuration provided by this plugin is:
 ```ts

docs/source/api/plugin/usage-reporting.mdx

@@ -8,7 +8,7 @@ api_reference: true
 
 Apollo Server's built-in usage reporting plugin gathers data on how your clients use the operations and fields in your GraphQL schema. The plugin also handles pushing this usage data to [GraphOS](/graphos/), as described in [Metrics and logging](../../monitoring/metrics/).
 
-This plugin is designed to be used in an Apollo Gateway or in a monolithic server; it is not designed to be used from a subgraph. In a supergraph running Apollo Federation, the Apollo Gateway or Apollo Router will send usage reports to Apollo's cloud. Subgraphs don't need to also send usage reports to Apollo's cloud; instead, they send it to the Router via [inline traces](./inline-trace/) and the Router combines execution information across all subgraphs and sends summarized reports to the cloud.
+This plugin is designed to be used in an Apollo Gateway or in a monolithic server; it is not designed to be used from a subgraph. In a supergraph running Apollo Federation, the Apollo Gateway or GraphOS Router will send usage reports to Apollo's cloud. Subgraphs don't need to also send usage reports to Apollo's cloud; instead, they send it to the Router via [inline traces](./inline-trace/) and the Router combines execution information across all subgraphs and sends summarized reports to the cloud.
 
 ## Default installation
 

docs/source/migration.mdx

@@ -1808,7 +1808,7 @@ new ApolloServer({
 
 ### Usage reporting plugin is off by default on subgraphs
 
-In an Apollo Federation supergraph, your Apollo Gateway or Apollo Router sends [usage reports](./api/plugin/usage-reporting/) to Apollo's servers; information about what happens inside individual subgraph servers is sent from the subgraphs to the Gateway or Router via [inline traces](./api/plugin/inline-trace/). That is to say: the usage reporting plugin is *not* designed for use in federated subgraphs.
+In an Apollo Federation supergraph, your Apollo Gateway or GraphOS Router sends [usage reports](./api/plugin/usage-reporting/) to Apollo's servers; information about what happens inside individual subgraph servers is sent from the subgraphs to the Gateway or Router via [inline traces](./api/plugin/inline-trace/). That is to say: the usage reporting plugin is *not* designed for use in federated subgraphs.
 
 In Apollo Server 3, if you provide an Apollo API key and graph ref and do not explicitly install the `ApolloServerPluginUsageReporting` or `ApolloServerPluginUsageReportingDisabled` plugins, the `ApolloServerPluginUsageReporting` plugin will be installed with its default configuration, even if the server is a subgraph.
 

docs/source/security/authentication.mdx

@@ -12,7 +12,7 @@ Your GraphQL API probably needs to control which users can see and interact with
 
 <Tip>
 
-Apollo Router can now provide authentication and authorization for your entire supergraph. While it may make sense to re-apply auth checks at a subgraph level or in a monolith graph, the Apollo Router has built and provided standard JWT checks that can be setup with a simple YAML configuration and enforce this in a central location for all subgraphs:
+GraphOS Router can now provide authentication and authorization for your entire supergraph. While it may make sense to re-apply auth checks at a subgraph level or in a monolith graph, the GraphOS Router has built and provided standard JWT checks that can be setup with a simple YAML configuration and enforce this in a central location for all subgraphs:
 
 https://www.apollographql.com/blog/centrally-enforce-policy-as-code-for-graphql-apis
 

docs/source/using-federation/api/apollo-gateway.mdx

@@ -5,7 +5,7 @@ api_reference: true
 
 This API reference documents the exports from the `@apollo/gateway` package. This package enables you to use Apollo Server as a gateway for a federated supergraph. For more information, see [Implementing a gateway with Apollo Server](../apollo-gateway-setup).
 
-> We recommend that all supergraphs use the Apollo Router instead of this Node.js-based gateway. See [Choosing a router library](/federation/building-supergraphs/router/#choosing-a-router-library).
+> We recommend that all supergraphs use the GraphOS Router instead of this Node.js-based gateway. See [Choosing a router library](/federation/building-supergraphs/router/#choosing-a-router-library).
 
 ## `class ApolloGateway`
 

docs/source/using-federation/apollo-gateway-setup.mdx

@@ -9,9 +9,9 @@ After you set up at least one federation-ready [subgraph](/federation/building-s
 
 <FederationArchitecture />
 
-> 📣 In the majority of cases, **we recommend using [the Apollo Router](/federation/building-supergraphs/router) as your graph router.** It's faster to configure, it's more performant (especially with high request loads), and it rarely requires writing custom code.
+> 📣 In the majority of cases, **we recommend using [the GraphOS Router](/federation/building-supergraphs/router) as your graph router.** It's faster to configure, it's more performant (especially with high request loads), and it rarely requires writing custom code.
 
-In certain cases, you might need to use Apollo Server as your graph router if your subgraphs use a custom authentication method that is currently difficult to configure with the Apollo Router.
+In certain cases, you might need to use Apollo Server as your graph router if your subgraphs use a custom authentication method that is currently difficult to configure with the GraphOS Router.
 
 Regardless of which graph router library you start with, you can swap to the other without making any changes to other parts of your supergraph.