Docs
Launch GraphOS Studio

Configuring Apollo projects

How to configure Apollo VS Code and CLI with apollo.config.js


Apollo projects are configured using an apollo.config.js file at the root of your project. Many Apollo tools leverage your Apollo config, reducing the net amount of configuration you need to do in your project in the end.

If you're using one of our workflow tools like the Apollo CLI or the Apollo VS Code extension, you'll need to have an apollo.config.js project to get the features those tools bring.

There are two types of projects, client and service. When a client key is found in the config, a project is treated as a client project, and only client:* commands may be run against it. The same is true for service projects. The apollo.config.js file is meant to describe configuration for a single project only. If used in a monorepo with multiple projects, there should be a separate config file for each project.

This document describes all the options available in the Apollo config and defines which are required vs. optional.

Client projects

Client projects are configured through a top level client key in the config.

module.exports = {
client: { ... },
};

client.service

Required –– the CLI and VS Code extension rely on knowledge of your to show you "intellisense" (eg. autocomplete on s, metrics annotations, query validation).

There are a few different ways you can link your client to a :

  1. Use the Apollo schema registry
  2. With a remote endpoint (from a running server)
  3. With a local file

Option 1: Use the Apollo schema registry

To link your client to a through the Apollo , you'll need to have at least one version of your schema published to the registry.

With Studio set up, you can point your client directly to your graph's by specifying your graph's name in your Apollo config, like so:

module.exports = {
client: {
service: "my-apollo-service", // the name of your graph in Studio
},
};

Note: you must have a published schema for features like VS Code intellisense, which requires knowledge of your , to work properly.

If you're tracking different versions of your in the using graph s, you can link your client to a specific variant like so:

module.exports = {
client: {
service: "my-apollo-service@staging", // "staging" is the graph variant we're using
},
};

If a graph is not specified, Apollo tools will fall back to the default value of current.

Remote endpoints can be used to pull down a from a running service. This can be configured like so:

module.exports = {
client: {
service: {
name: "github",
url: "https://api.github.com/graphql",
// optional headers
headers: {
authorization: "Bearer lkjfalkfjadkfjeopknavadf",
},
// optional disable SSL validation check
skipSSLValidation: true,
},
},
};

In some cases you may have a locally generated file with your that you want to link. This can be either a .graphql file with the in form or a saved result in .json. To link your client project to a local file, configure it like so:

module.exports = {
client: {
service: {
name: "my-service-name",
localSchemaFile: "./path/to/schema.graphql",
},
},
};

client.includes

Optional –– by default, Apollo tools will look under a ./src directory to find all s and to extract.

Client projects often contain client-side definitions for local state with Apollo Client. To make sure the Apollo CLI and VS Code extension can find these files and read them correctly, you may need to tell Apollo which folders to look for your schema and queries in like so:

module.exports = {
client: {
includes: ['./imports/**/*.js'], // array of glob patterns
service: ...
},
};

client.excludes

Optional –– by default, Apollo tools will exclude **/node_modules and **/__tests___ when looking for your queries and files.

If you want Apollo to ignore any of your other folders when looking for queries and definitions, adjust your config like so:

module.exports = {
client: {
excludes: ['**/__tests__/**/*'], // array of glob patterns
service: ...
},
};

client.tagName

Optional –– custom tagged template literal.

When using GraphQL with JavaScript or TypeScript projects, it is common to use the gql tagged template literal to write out s. Apollo tools will be looking through your files for the gql tag to extract your queries, so if you use a different template literal, you can configure it like so:

module.exports = {
client: {
tagName: "graphql",
service: ...
}
};

client.addTypename

Optional –– Apollo will by default add the __typename to all your s automatically and to all your generated types during codegen.

GraphQL clients like Apollo Client often add the __typename to s automatically when they're sent over the wire. This can come in really handy for things like caching, but it can be turned off by adding addTypename: false to the client config:

module.exports = {
client: {
addTypename: false,
service: ...
}
};

Note: For consistency, we recommend that you keep this option consistent with how your ApolloClient is configured.

client.clientOnlyDirectives, client.clientSchemaDirectives

Optional –– By default, Apollo projects support the following client-side s:

  • @client for local state
  • @rest for using apollo-link-rest
  • @connection for custom pagination with Apollo Client
  • @type for dynamic type names with apollo-link-rest

Client side applications can use custom s on their queries that aren't meant to be sent to the server. Configuration of client side directives beyond the defaults listed above can be set up like so:

module.exports = {
client: {
clientOnlyDirectives: ["connection", "type"],
clientSchemaDirectives: ["client", "rest"],
service: ...
}
};

clientOnlyDirectives are s that should be stripped out of the before being sent to the server. An example of this is the @connection .

clientSchemaDirectives are s that indicate a portion of the that is not meant to be sent to the server. These directives are removed as well as the s they are placed on. An example of this type of directive is the @client .

Server projects

Server projects are configured through a top level service key in the config.

module.exports = {
service: { ... },
};

Defining a service key in your Apollo config will provide the CLI with the information it needs to perform commands like apollo service:push and apollo service:check. You can set up the for your service to load in one of two ways:

  1. Using a remote endpoint
  2. Using a local file

Option 1: Remote endpoint

Remote endpoints can be used to pull down a from a running service. This can be configured like so:

module.exports = {
service: {
endpoint: {
url: "https://api.github.com/graphql", // defaults to http://localhost:4000
headers: {
// optional
authorization: "Bearer lkjfalkfjadkfjeopknavadf",
},
skipSSLValidation: true, // optional, disables SSL validation check
},
},
};

Option 2: Local schema

In some cases you may have a locally generated file with your that you want to link. This can be either a .graphql file with the in form or a saved result in .json. To link your client project to a local file, configure it like so:

module.exports = {
service: {
localSchemaFile: "./path/to/schema.graphql",
},
};
Next
Home
Edit on GitHubEditForumsDiscord