expose ApolloServerOptions interfaces

[axe-me]

Hi there,

I'm developing an in-house graphql framework wrapping around the apollo server. In the framework, I'm trying to create different types (gateway, subgraph or standalone) of apollo server based on some config. Thus the framework need access to all these interfaces.

Thanks for reviewing this PR.

Cheers.

[apollo-cla]

@axe-me: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/

[netlify]

❌ Deploy Preview for apollo-server-docs failed.

Built without sensitive environment variables

Name	Link
🔨 Latest commit	1cb8989
🔍 Latest deploy log	https://app.netlify.com/sites/apollo-server-docs/deploys/63c856bf40fa60000858518e

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 1cb8989:

Sandbox	Source
Apollo Server Typescript	Configuration
Apollo Server	Configuration

[trevor-scheer]

Thanks for the PR @axe-me!

Is it safe to assume the exported ApolloServerOptions union of all of the types you're interested in is sufficient but cumbersome to work with? I'm interested to know why you need the individual types (maybe your API needs to expose just a subset of this union to your users, or the types are useful internally?). Either way this seems pretty reasonable to me, especially given that we're already exporting the top-level union.

@glasser explicitly removed their exports before we landed v4 in this PR: #6551, motivation unclear (possibly just to limit the API surface area by default, then expose if needed later like now). I'd be interested to hear if he had any motivation to keep the types private.

[glasser]

I think it was just "felt internal". If it's genuinely useful, it's probably fine to add back (with a quick double-check-that-we-like-the-names-enough-to-commit pass).

[axe-me]

@trevor-scheer @glasser Thanks for reviewing this PR. My use case is like this:

export type CreateSubgraphServerOptions = Partial<ApolloServerOptions<AxeAppContext>> & {
  serverType: 'subgraph'
  // ...extra fields
};

export type CreateStnadaloneServerOptions = Partial<ApolloServerOptions<AxeAppContext>> & {
  serverType: 'standalone'
  // ....extra fields
};

export type CreateGatewayServerOptions = Partial<ApolloServerOptions<AxeAppContext>> & {
  serverType: 'gateway'
  // ...extra fields
};
export type CreateServerOptions = CreateSubgraphServerOptions | CreateStnadaloneServerOptions | CreateGatewayServerOptions;

in my create server function I have code to narrowing types and create different types of apollo servers:

switch (args.options.serverType) {
  case 'subgraph':
    server = await createSubgraphServer(args.options);
    break;
  case 'gateway':
    server = await createGatewayServer(args.options);
    break;
  case 'standalone':
    server = await createStandaloneServer(args.options);
    break;
  default:
    throw new Error('Unknown server type');
  }

Note that right now I have to wrap around ApolloServerOptions with Partial helper as a workaround to prevent ts complaining about the field missing. But this is not ideal. Ideally, I can do this:

interface CreateGatewayServerOptions extends ApolloServerOptionsWithGateway<Context> {
  serverType: 'gateway'
  // ... extra fields
}