Apollo-tooling: Apollo VS Code to accept an array of client objects

[ZenSoftware]

I am unsure of how to handle multiple GraphQL endpoints for a monolithic repo. Would it be possible to allow Apollo VSCode extension to accept an array of client objects?

example of an apollo.config.js

module.exports = {
  client: [
    {
      name: 'main-app',
      service: {
        url: 'http://localhost:4200/API/GQL'
      },
      includes: ['libs/**/*.gql'],
      excludes: ['libs/admin']
    },

    {
      name: 'admin-app',
      service: {
        url: 'http://localhost:4200/API/AdminGQL'
      },
      includes: ['libs/admin/**/*.gql']
    }
  ]
};

[jbaxleyiii]

@ZenSoftware the current design was setup for multiple apollo.config.js to exist within a monorepo and to setup a workspace with projects for each of them within vscode. We definitely do want to support great monorepo development so we it may be worth revisiting / improving this!

The current design allows for something like this:

- workspace root
-- main-app
---- apollo.config.js
-- admin-app
---- apollo.config.js

where you would setup a vscode workspace with project roots in the main-app and admin-app folders.

I'm wondering if it may be better to support an array of configs vs array of clients:

module.exports = [
  {
    client: {
      name: "main-app",
      service: {
        url: "http://localhost:4200/API/GQL"
      },
      includes: ["libs/**/*.gql"],
      excludes: ["libs/admin"]
    }
  },
  {
    client: {
      name: "admin-app",
      service: {
        url: "http://localhost:4200/API/AdminGQL"
      },
      includes: ["libs/admin/**/*.gql"]
    }
  }
];

[ZenSoftware]

Thanks for the response.

This seems to be a bit of an issue for certain style of mono repos, where everything resides under one VS Code root project folder. For example, there is a popular Angular extension called Nrwl Nx where they setup the mono repo under one VS Code root project folder. It's actually what we are using currently, and it is limiting our use of Apollo VS Code extension.

It would be ideal if we could have some method of explicitly defining multiple clients in one apollo.config.js. Allowing for an array of clients might be a sensible solution. ^_^

[rovansteen]

I would love to see this feature as well as we have two graphql endpoints in one project, one public to register/login etc. and one for the application itself.

[RobertWSaunders]

@jbaxleyiii Has there been much thought around mono repos that contain both the service (i.e. the GraphQL server) and the client? I currently have a mono repo that is managed with Lerna with the file structure:

- packages
-- client
--- ...
-- server
--- ...

One reason we chose to use a mono repo is because we want to share tooling between projects however its proving pretty difficult to get all the benefits of the Apollo VSCode extension for both the client and server. On the client we want the auto completion, tracing etc and on the server we would like to put service information in a config so we can run apollo service:push without needing to add flags. One big bottleneck here is the environment variable. ENGINE_API_KEY because each package manages their own environment variables by way of their own .env. Any ideas that could help us?

[JakeDawkins]

@ZenSoftware is this still an issue? We did some work with the earlier versions of vscode-apollo to properly support monorepos with multiple config files opened at once within vscode.

[ZenSoftware]

@JakeDawkins This is no longer an issue for us with the use of multiple config files. You can go ahead and close this issue. The limitations that we were facing before with our monorepo has been addressed, and we are no longer in need of this proposed feature. Thanks!

[RobertWSaunders]

@JakeDawkins my comment may be appropriate for another issue because it doesn't relate specifically to clients but it does still apply to mono-repos in general and is still an issue.

[JakeDawkins]

@RobertWSaunders for sure! I _think_ most of that functionality works. The fullstack tutorial repo is a monorepo (although not managed by lerna or anything) with the final folder having both a client and service project.

Unfortunately, they do both need their own .env files, since the extension/cli treats them completely separately and uses the config path to find those .env files, but if you added that variable to your env manually, you wouldn't need those files (I think).

If there are any specific issues/suggestions around how to better handle those use cases though, another issue would be perfect. Thanks for the feedback, everyone :)