Reorganize Server docset information architecture

docs/gatsby-config.js

@@ -16,29 +16,24 @@ module.exports = {
           1: 'version-1',
         },
         sidebarCategories: {
-          null: ['index', 'getting-started', 'whats-new'],
-          Essentials: [
-            'essentials/schema',
-            'essentials/server',
-            'essentials/data',
+          null: [
+            'index',
+            'getting-started',
+            '[Changelog](https://github.com/apollographql/apollo-server/blob/master/CHANGELOG.md)',
           ],
-          Features: [
-            'features/caching',
-            'features/mocking',
-            'features/errors',
-            'features/data-sources',
-            'features/subscriptions',
-            'features/metrics',
-            'features/graphql-playground',
-            'features/scalars-enums',
-            'features/unions-interfaces',
-            'features/directives',
-            'features/creating-directives',
-            'features/authentication',
-            'features/testing',
-            'features/apq',
-            'features/health-checks',
-            'features/file-uploads',
+          'Defining a Schema': [
+            'schema/schema',
+            'schema/scalars-enums',
+            'schema/unions-interfaces',
+            'schema/directives',
+            'schema/creating-directives',
+          ],
+          'Fetching Data': [
+            'data/data',
+            'data/data-sources',
+            'data/errors',
+            'data/file-uploads',
+            'data/subscriptions',
           ],
           Federation: [
             'federation/introduction',
@@ -51,20 +46,18 @@ module.exports = {
             'federation/federation-spec',
             'federation/metrics',
           ],
-          // 'Schema stitching': [
-          //   'features/schema-stitching',
-          //   'features/remote-schemas',
-          //   'features/schema-delegation',
-          //   'features/schema-transforms',
-          // ],
+          Testing: ['testing/mocking', 'testing/testing', 'testing/graphql-playground'],
+          Performance: ['performance/caching', 'performance/apq'],
+          Security: ['security/authentication', 'security/terminating-ssl'],
+          Integrations: ['integrations/middleware'],
           Deployment: [
-            // 'deployment/index',
             'deployment/heroku',
             'deployment/lambda',
             'deployment/now',
             'deployment/netlify',
             'deployment/azure-functions',
           ],
+          Monitoring: ['monitoring/metrics', 'monitoring/health-checks'],
           'API Reference': [
             'api/apollo-server',
             'api/apollo-federation',

docs/source/api/apollo-server.md

@@ -7,7 +7,7 @@ This API reference documents the exports from the `apollo-server` package.
 
 ## `ApolloServer`
 
-The core of an Apollo Server implementation. For an example, see the [Building a server](/essentials/server/) section within "Essentials".
+The core of an Apollo Server implementation. For an example, see the [getting-started article](/getting-started/).
 
 ### `constructor(options)`: <`ApolloServer`>
 

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](/essentials/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) }`
 

docs/source/essentials/data.md → docs/source/data/data.md

@@ -46,20 +46,20 @@ const resolvers = {
 
 With the resolver map above, the query, `{ author { books } }`, will call the `Query.author` resolver first and pass its result to `Author.books`. The query result will contain the return value of `Author.books` nested under `data.author.books`.
 
-Note that you don't have to put all of your resolvers in one object. Refer to the ["modularizing resolvers"](https://www.apollographql.com/docs/apollo-server/essentials/data/#modularizing-resolvers) section to learn how to combine multiple resolver maps into one.
+Note that you don't have to put all of your resolvers in one object. Refer to the ["modularizing resolvers"](#modularizing-resolvers) section to learn how to combine multiple resolver maps into one.
 
 ## Resolver type signature
 
 In addition to the parent resolvers' value, resolvers receive a couple more arguments. The full resolver function signature contains four positional arguments: `(parent, args, context, info)` and can return an object or [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises). Once a promise resolves, then the children resolvers will continue executing. This is useful for fetching data from a backend.
 
 The resolver parameters generally follow this naming convention and are described in detail:
 
-1. `parent`: The object that contains the result returned from the resolver on the parent field, or, in the case of a top-level `Query` field, the `rootValue` passed from the [server configuration](/essentials/server/). This argument enables the nested nature of GraphQL queries.
+1. `parent`: The object that contains the result returned from the resolver on the parent field, or, in the case of a top-level `Query` field, the `rootValue` passed from the server configuration. This argument enables the nested nature of GraphQL queries.
 2. `args`: An object with the arguments passed into the field in the query. For example, if the field was called with `query{ key(arg: "you meant") }`, the `args` object would be: `{ "arg": "you meant" }`.
 3. `context`: This is an object shared by all resolvers in a particular query, and is used to contain per-request state, including authentication information, dataloader instances, and anything else that should be taken into account when resolving the query. Read [this section](#context-argument) for an explanation of when and how to use context.
 4. `info`: This argument contains information about the execution state of the query, including the field name, path to the field from the root, and more. It's only documented in the [GraphQL.js source code](https://github.com/graphql/graphql-js/blob/c82ff68f52722c20f10da69c9e50a030a1f218ae/src/type/definition.js#L489-L500), but is extended with additional functionality by other modules, like [`apollo-cache-control`](https://github.com/apollographql/apollo-server/tree/master/packages/apollo-cache-control).
 
-In addition to returning GraphQL defined [scalars](/essentials/schema/#scalar-types), you can return [custom scalars](/features/scalars-enums/) for special use cases, such as JSON or big integers.
+In addition to returning GraphQL defined [scalars](/schema/schema/#scalar-types), you can return [custom scalars](/schema/scalars-enums/) for special use cases, such as JSON or big integers.
 
 ### Resolver results
 
@@ -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](/features/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.
 

docs/source/features/subscriptions.md → docs/source/data/subscriptions.md

@@ -145,10 +145,6 @@ The example above validates the user's token that is sent with the first initial
 
 In case of an authentication error, the Promise will be rejected, which prevents the client's connection.
 
-## Securing Subscriptions with WSS
-
-Similar to how the `https://` scheme offers an [SSL/TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security)-encrypted version of `http://`, the subscriptions WebSocket transport can be encrypted using _WebSockets over SSL/TLS_ (WSS). See the [example server setup](/essentials/server/#ssltls-support) for more details.
-
 ## Subscription Filters
 
 Sometimes a client will want to filter out specific events based on context and arguments.

docs/source/federation/implementing.md

@@ -50,7 +50,7 @@ server.listen(4001).then(({ url }) => {
 });
 ```
 
-If you're already familiar with [setting up an Apollo Server](/essentials/server/#creating-a-server), this should look pretty familiar. If not, we recommend you first take a moment to get comfortable with this topic before jumping in to federation.
+If you're already familiar with [setting up an Apollo Server](/getting-started/), this should look pretty familiar. If not, we recommend you first take a moment to get comfortable with this topic before jumping in to federation.
 
 Now, let's see what this looks like as a federated service: