Open EverlastingBugstopper opened 2 years ago
this recent refactor starts laying the ground work for this I think
docs for rover subgraph init
should look something like this:
Run rover subgraph init
to create a new subgraph and answer the questions provided by the wizard. Below is an example of bootstrapping a supergraph with a single subgraph. Debug statements are included to show some of what's happening behind the scenes including what the config file will look like.
$ rover subgraph init --log debug
Are you extending a pre-existing supergraph? (Y/N)? N
DEBUG no supergraph exists, prompt to create one
What is the name of the supergraph you would like to create? my-supergraph
What is the name of the subgraph you would like to create? my-subgraph
What is the endpoint for developing 'my-subgraph' locally? http://localhost:4000/graphql
What is the endpoint 'my-subgraph' will be deployed to? https://my-subgraph.apollo.dev/graphql
Where can the schema for 'my-subgraph' be found?
> * Local filesystem
* Introspection
* Apollo Studio
What is the path to the schema for 'my-subgraph'? ./my-subgraph.graphql
Creating .apollo/project.yaml for 'my-subgraph'...
DEBUG ApolloConfigDir {
ApolloConfigYaml {
project_type: subgraph
supergraph:
id: my-supergraph
default_variant: current
subgraphs:
my-subgraph:
schema:
file: ./my-subgraph.graphql
variants:
current:
routing_url: https://my-subgraph.apollo.dev/graphql
dev:
routing_url: http://localhost:4000/graphql
}
}
Successfully initialized 'my-supergraph' and 'my-subgraph'.
You can run `rover subgraph dev` to test 'my-subgraph' locally, or you can publish 'my-subgraph' to Apollo Studio by running `rover subgraph publish`.
If you pass a --variant
to rover subgraph init
after already initializing your configuration directory, Rover will automatically insert the new configuration for that variant. This configuration will be used when publishing your subgraph to Apollo Studio.
$ rover subgraph init --variant staging --log debug
Reading contents of .apollo/project.yaml...
DEBUG ApolloConfigDir {
ApolloConfigYaml {
project_type: subgraph
supergraph:
id: my-supergraph
default_variant: current
subgraphs:
my-subgraph:
publish:
variants:
current:
routing_url: https://my-subgraph.apollo.dev/graphql
dev:
routing_url: http://localhost:4000/graphql
}
}
What is the endpoint 'my-subgraph@staging' will be deployed to? https://staging.my-subgraph.apollo.dev/graphql
Creating 'subgraphs.my-subgraph.publish.variants.staging' in .apollo/project.yaml...
DEBUG ApolloConfigDir {
ApolloConfigYaml {
project_type: subgraph
supergraph:
id: my-supergraph
default_variant: current
subgraphs:
my-subgraph:
schema:
file: ./my-subgraph.graphql
publish:
variants:
current:
routing_url: https://my-subgraph.apollo.dev/graphql
staging:
routing_url: https://staging.my-subgraph.apollo.dev/graphql
dev:
routing_url: http://localhost:4000/graphql
}
}
Successfully initialized 'my-subgraph@staging'.
You can run `rover subgraph dev --variant staging` to test 'my-subgraph@staging' locally, or you can publish 'my-subgraph@staging' to Apollo Studio by running `rover subgraph publish --variant staging`.
@EverlastingBugstopper noting down the discussion we had about keys/env vars.
Since users are expected to commit .apollo
, it'd be good to think about how we'd like to handle any secrets, especially in CI contexts. While it's likely not pertinent for the current implementation, I think it's good to keep that in mind. If it seems like there is a possibility of .apollo
containing secrets, we should make sure to write up a guide for our users as to how they can use env vars or something else to keep their .apollo
secure.
Yes - we should probably support environment variable expansion just like the router config does. Docs for that are here, and it looks like @BrynCooke recently worked on improving its functionality in this PR. It looks like the envmnt
crate provides some utilities that we could use here.
rover should recognize a
.apollo
directory and allow required arguments to become optional if they are specified in config.implementation:
we should closely map configuration keys to their associating flags/arguments. config options should be resolved to a single struct (may need to do some refactoring to enable this and also work with environment variables)