Rename Serving Requests to Fetching Data

apollographql · Sep 5, 2019 · b24c269 · b24c269
1 parent aef1e1c
commit b24c269
Show file tree

Hide file tree

Showing 10 changed files with 17 additions and 17 deletions.
diff --git a/docs/gatsby-config.js b/docs/gatsby-config.js
@@ -29,13 +29,24 @@ module.exports = {
             'schema/directives',
             'schema/creating-directives',
           ],
-          'Serving Requests': [
+          'Fetching Data': [
             'serving/data',
             'serving/data-sources',
             'serving/errors',
             'serving/file-uploads',
             'serving/subscriptions',
           ],
+          Federation: [
+            'federation/introduction',
+            'federation/concerns',
+            'federation/core-concepts',
+            'federation/implementing',
+            'federation/advanced-features',
+            'federation/errors',
+            'federation/migrating-from-stitching',
+            'federation/federation-spec',
+            'federation/metrics',
+          ],
           Testing: ['testing/mocking', 'testing/testing'],
           Performance: ['performance/caching', 'performance/apq'],
           Security: ['security/authentication', 'security/terminating-ssl'],
@@ -48,17 +59,6 @@ module.exports = {
             'deployment/azure-functions',
           ],
           Monitoring: ['monitoring/metrics', 'monitoring/health-checks'],
-          Federation: [
-            'federation/introduction',
-            'federation/concerns',
-            'federation/core-concepts',
-            'federation/implementing',
-            'federation/advanced-features',
-            'federation/errors',
-            'federation/migrating-from-stitching',
-            'federation/federation-spec',
-            'federation/metrics',
-          ],
           'API Reference': [
             'api/apollo-server',
             'api/apollo-federation',

diff --git a/docs/source/api/graphql-tools.md b/docs/source/api/graphql-tools.md
@@ -61,7 +61,7 @@ const jsSchema = makeExecutableSchema({
 
 - `typeDefs` is a required argument and should be a GraphQL schema language string or array of GraphQL schema language strings or a function that takes no arguments and returns an array of GraphQL schema language strings. The order of the strings in the array is not important, but it must include a schema definition.
 
-- `resolvers` is an optional argument _(empty object by default)_ and should be an object that follows the pattern explained in the [resolvers documentation](/serving/data/).
+- `resolvers` is an optional argument _(empty object by default)_ and should be an object that follows the pattern explained in the [resolvers documentation](/data/data/).
 
 - `logger` is an optional argument, which can be used to print errors to the server console that are usually swallowed by GraphQL. The `logger` argument should be an object with a `log` function, eg. `const logger = { log: e => console.log(e) }`
 

diff --git a/docs/source/serving/data-sources.md → docs/source/data/data-sources.md b/docs/source/serving/data-sources.md → docs/source/data/data-sources.md
diff --git a/docs/source/serving/data.md → docs/source/data/data.md b/docs/source/serving/data.md → docs/source/data/data.md
@@ -101,7 +101,7 @@ Every resolver function is called according to the nesting of the query. To unde
 
 The context is how you access your shared connections and fetchers in resolvers to get data.
 
-The `context` is the third argument passed to every resolver. It is useful for passing things that any resolver may need, like [authentication scope](https://blog.apollographql.com/authorization-in-graphql-452b1c402a9), database connections, and custom fetch functions. Additionally, if you're using [dataloaders to batch requests](/serving/data-sources/#what-about-dataloader) across resolvers, you can attach them to the `context` as well.
+The `context` is the third argument passed to every resolver. It is useful for passing things that any resolver may need, like [authentication scope](https://blog.apollographql.com/authorization-in-graphql-452b1c402a9), database connections, and custom fetch functions. Additionally, if you're using [dataloaders to batch requests](/data/data-sources/#what-about-dataloader) across resolvers, you can attach them to the `context` as well.
 
 As a best practice, `context` should be the same for all resolvers, no matter the particular query or mutation, and resolvers should never modify it. This ensures consistency across resolvers, and helps increase development velocity.
 

diff --git a/docs/source/serving/errors.md → docs/source/data/errors.md b/docs/source/serving/errors.md → docs/source/data/errors.md
diff --git a/docs/source/serving/file-uploads.md → docs/source/data/file-uploads.md b/docs/source/serving/file-uploads.md → docs/source/data/file-uploads.md
diff --git a/docs/source/serving/subscriptions.md → docs/source/data/subscriptions.md b/docs/source/serving/subscriptions.md → docs/source/data/subscriptions.md
diff --git a/docs/source/getting-started.md b/docs/source/getting-started.md
@@ -222,5 +222,5 @@ Apollo Server. Check out the following resources to learn more about the basics
 of schemas, resolvers, and deployment:
 
 * [Schema basics](/schema/schema/)
-* [Fetching data with resolvers](/serving/data/)
+* [Fetching data with resolvers](/data/data/)
 * [Deploying with Heroku](/deployment/heroku/)
diff --git a/docs/source/performance/caching.md b/docs/source/performance/caching.md
@@ -118,7 +118,7 @@ const server = new ApolloServer({
 });
 ```
 
-By default, the response cache plugin will use the same cache used by other Apollo Server features, which defaults to an in-memory LRU cache. When running multiple server instances, you’ll want to use a shared cache backend such as Memcached or Redis instead.  See [the data sources documentation](/serving/data-sources/#using-memcachedredis-as-a-cache-storage-backend) for details on how to customize Apollo Server's cache.  If you want to use a different cache backed for the response cache than for other Apollo Server caching features, just pass a `KeyValueCache` as the `cache` option to the `responseCachePlugin` function.
+By default, the response cache plugin will use the same cache used by other Apollo Server features, which defaults to an in-memory LRU cache. When running multiple server instances, you’ll want to use a shared cache backend such as Memcached or Redis instead.  See [the data sources documentation](/data/data-sources/#using-memcachedredis-as-a-cache-storage-backend) for details on how to customize Apollo Server's cache.  If you want to use a different cache backed for the response cache than for other Apollo Server caching features, just pass a `KeyValueCache` as the `cache` option to the `responseCachePlugin` function.
 
 If you have data whose response should be cached separately for different users, set `@cacheControl(scope: PRIVATE)` hints on the data, and teach the cache control plugin how to tell your users apart by defining a `sessionId` hook:
 

diff --git a/docs/source/why-apollo-server.md b/docs/source/why-apollo-server.md
@@ -40,7 +40,7 @@ server.listen().then(({ url }) => {
 });
 ```
 
-In the example above, we are describing the shapes of our data, how they relate to each other, and how to fetch what our client needs from our data source. Apollo Server uses simple functions called [resolvers](/serving/data/) to bring to life the schema described in SDL type definitions. When a request comes in to `/graphql`, Apollo Server will translate that request into what it takes to execute the query, will run the resolvers for you to load your data, and return the result in JSON so your app can render it out easily!
+In the example above, we are describing the shapes of our data, how they relate to each other, and how to fetch what our client needs from our data source. Apollo Server uses simple functions called [resolvers](/data/data/) to bring to life the schema described in SDL type definitions. When a request comes in to `/graphql`, Apollo Server will translate that request into what it takes to execute the query, will run the resolvers for you to load your data, and return the result in JSON so your app can render it out easily!
 
 Apollo Server takes care of every step of translating the query your client asks for into the data it needs. It is designed to give you maximum control over how you load the data while taking care of everything else for you! You don't need to worry about parsing the request, validating the query, delivering the response, or even profiling your app. Instead, all you have to do is describe the shape of your data and how to find it; Apollo Server does the rest! 💪
-Original file line number
+Diff line change
@@ Expand Up / @@ -118,7 +118,7 @@ const server = new ApolloServer({ @@
     });
     ```
-    By default, the response cache plugin will use the same cache used by other Apollo Server features, which defaults to an in-memory LRU cache. When running multiple server instances, you’ll want to use a shared cache backend such as Memcached or Redis instead.  See [the data sources documentation](/serving/data-sources/#using-memcachedredis-as-a-cache-storage-backend) for details on how to customize Apollo Server's cache.  If you want to use a different cache backed for the response cache than for other Apollo Server caching features, just pass a `KeyValueCache` as the `cache` option to the `responseCachePlugin` function.
+    By default, the response cache plugin will use the same cache used by other Apollo Server features, which defaults to an in-memory LRU cache. When running multiple server instances, you’ll want to use a shared cache backend such as Memcached or Redis instead.  See [the data sources documentation](/data/data-sources/#using-memcachedredis-as-a-cache-storage-backend) for details on how to customize Apollo Server's cache.  If you want to use a different cache backed for the response cache than for other Apollo Server caching features, just pass a `KeyValueCache` as the `cache` option to the `responseCachePlugin` function.
     If you have data whose response should be cached separately for different users, set `@cacheControl(scope: PRIVATE)` hints on the data, and teach the cache control plugin how to tell your users apart by defining a `sessionId` hook:
@@ Expand Down @@