Apollo-tooling: How to configure `apollo.config.json` to multiple local schema files?

[oneroman]

Hi there,

I am using apollo codegen:generate to generate TypeScript types based on my queries; also I have configured apollo.config.json which points to local schema file. is there a way to configure code generator to look for multiple local schema files?

module.exports = {
  client: {
    includes: [__dirname+'/src/graphql/my_query/**'],
    service: {
      name: "my_name",
      localSchemaFile: "./src/graphql/my_schema.graphql" // how to configure to multiple schemas?
    }
  }
}

Thanks!

[acro5piano]

Maybe duplicated with this?

https://github.com/apollographql/apollo-tooling/issues/588

[mbinic]

This one talks about the newer config format.
Looking at the code of packages/apollo-language-server/src/config.ts (if that's the right file), it seems there's no way of configuring multiple schemas.

[JakeDawkins]

@oneroman @mbinic

The localSchemaFile only allows one schema definition, but as long as the additions to the schema can be picked up from the includes, it should automatically find the rest of the schema. That's actually how generation of local state types works.

---

For example, this project has a schema.graphql at the root of the project.

It defines an Origin type. src/extendedSchema.graphql extends that type and adds a name field. Since my apollo.config.js has an includes of ./src/**/*.graphql, it picks up that file in codegen and extends the localSchemaFile.

You can see the codegen results with the added field here

[JakeDawkins]

This should be solved, so I'll close this issue for now :)

[oneroman]

@JakeDawkins Thanks for sharing some samples.
How do I handle a case when I have some Queries defined inlocalSchemaFile the via

type Query {
     // my queries here
}

and then I want to add more queries into *.graphql included via includes section. Is that possible at all?

I am trying it via:

extend type Query {
     // my other queries here
}

and I am having this error:

Type "Query" already exists in the schema. It cannot also be defined in this type definition.

[oneroman]

@JakeDawkins I think I passed above issue. I am able to generate types and write multiple schema files using extend keyword. So far, so good.

But what about the case when the client needs to work with 2 or more independent schemas at all (for instance, GitHub API and Yelp and so on.). In this case these schemas are not necessarily extend each other; they are orthogonal to each other and also they can contain same types defined. In this case extend approach won't work. any ideas?

[Cherrier-Emerson]

I ran into an issue that could be worth to share here:
when the apollo.config.js file is not located at the root of the project you must take care that:

• the localSchemaFile path is relative from the root of the project
• the includes files path are relatives from the config file location.

[JakeDawkins]

@oneroman

But what about the case when the client needs to work with 2 or more independent schemas at all (for instance, GitHub API and Yelp and so on.). In this case these schemas are not necessarily extend each other; they are orthogonal to each other and also they can contain same types defined. In this case extend approach won't work. any ideas?

Sooo right now, I don't think we have a way to cleanly do that automatically. automatically extending types when duplicates are found would be pretty dangerous. I think the only option right now for that use case would be to manually build a schema file for your use case.

In an ideal world, graphql clients would only be communicating with one endpoint, and that endpoint would be a gateway of sorts to any 3rd party API's (graphql or otherwise). Having clients speak to more than one endpoint isn't uncommon, but it certainly makes tooling much more complicated

[veeramarni]

@JakeDawkins tried with three schemas and it is failing. Please check https://github.com/apollographql/apollo-tooling/issues/1211

[gunzip]

In an ideal world, graphql clients would only be communicating with one endpoint, and that endpoint would be a gateway of sorts to any 3rd party API's (graphql or otherwise). Having clients speak to more than one endpoint isn't uncommon, but it certainly makes tooling much more complicated

@JakeDawkins

i don't think it's uncommon. ie. i'm using a graphql endpoint AND apollo-link-rest (with a swagger-to-grapqhl converted schema) and actually cannot work with both schemas using apollo configuration.

[JakeDawkins]

@gunzip good point! I think the easiest thing to make this work quickly would be to add a build step that merges your schemas into one, and then pointing tooling at that composed schema. We don't support multiple distinct schemas right now.

For example, if your GraphQL endpoint had a User type defined, and so did your swagger-generated schema, there's no way for our tooling to merge those types safely and automatically. If In that User, we couldn't just support merging fields, because there could be overlap. User.id from your graphql endpoint could be a ID! and your generated schema could define User.id as ID or Int. There's no way for us to know how to handle those scenarios.

In your build process, you could (automatically or manually) transform and merge the two schemas manually and output a "safe" schema to use for tooling. Especially if your REST endpoint is a 3rd party endpoint or unlikely to change often, you could do this once and be fine for a while probably.

[andrew-humu]

@JakeDawkins Several server implementation (I'm using Ariadne now) encourage modularizing your schema declaration by splitting the definition across files.

I think in most cases their assumption is that you are simply writing a single schema but have split that definition across files, and therefore naively concatenating the files before parsing is enough.

i.e. If you declare the same type multiple times (without using an extend declaration) the server will not try to do any clever merging, but just throw a "failed to parse" error.

I think it'd be great for industry compatibility if this behaviour were supported by Apollo tools.

---

To make a concrete proposal:

I think that sort of naive concatenation approach might meet most users expectations if apollo.config.js supported multiple files passed to localSchemaFile:

module.exports = {
  client: {
    includes: [__dirname+'/src/graphql/my_query/**'],
    service: {
      name: "my_name",
      localSchemaFile: ["./src/graphql/my_schema1.graphql", "./src/graphql/my_schema2.graphql"]
    }
  }
}

[JakeDawkins]

@andrew-humu I think the confusion here is where these schema files are coming from. The client.service is intended to reference a complete schema to begin with. It's not meant to reference the source files of a service project that lives alongside a client project. In other words, the localSchemaFile that we have here in the config is meant to be a _generated_ file with all types extensions merged already. That's why there's this discrepancy.

I'd like to support this in future (major) versions of tooling with an overhaul of the config, but for now, I'd recommend using generated schemas or an endpoint