Is there a way to maintain "Connection Settings" in a variant via a CLI

[kmcrawford]

I am unable to find documentation on how to maintain the below via a CLI, is this possible?

[EverlastingBugstopper]

Hi @kmcrawford - thanks for the question. This is not something the CLI supports today but long term the development story will be a bit tidied up. I'm going to close this issue for now as it's not something that will be coming any time soon.

[kmcrawford]

@EverlastingBugstopper is it possible to add this functionality of SetVariantURLMutation to rover? I can create a pr if this exists?

[EverlastingBugstopper]

I don't think there's any existing surface area in the CLI that it would make sense to put this in. Would you mind sharing with me the workflow you envision?

[kmcrawford]

Adding it to publish graph as optional parameters would work.

[kmcrawford]

According to what the site uses it's a combination of PersistDefaultHeadersForGraphVariant & SetVariantURLMutation

rover graph publish mygraph@my-variant --schema ./schema.graphql \
 --endpoint=https://myserver.com \
 --additionalHeader myheader:value1 \
 --additionalHeader myheader2:value1

[EverlastingBugstopper]

Ah, that's interesting. So far most operations only do 1 mutation at a time, though it seems sending those other mutations in succession would do what you're looking for. I think since we have --routing-url for subgraphs, it may make sense to add this as an optional flag for graph publish. I'm going to ask @prasek to weigh in here as I'm not entirely sure what setting this endpoint actually does.

The long-term plan is to have a configuration file for this kinda stuff so you shouldn't have to worry about passing them in as flags.

[kmcrawford]

This would be great as our ci/cd system publishes feature branches as variants. It would be nice if the endpoints were all setup for our developers without them having to do an extra step. (We also use rover delete to automatically clean up the variants when the feature branch gets merged/deleted)

[abernix]

@EverlastingBugstopper

I'm not entirely sure what setting this endpoint actually does.

This solely configures the Apollo Studio Explorer's default headers which results in them being pre-populated when "Exploring" this graph variant. That is a nice feature, though I am curious if there is enough potential surface area here to have a set of rover explorer config <graphRef> ... commands. (My hunch is that there could be (including a rover explorer launch <graphRef> command, potentially?)

[kmcrawford]

Rover is used from our ci/cd system to create and maintain variants. I feel leaving this feature out makes it an incomplete cli tool, in which the entire process can’t be automated.

[abernix]

@kmcrawford To be clear, your use case seems completely valid; I'm not challenging the value of this to you and nothing I said above was meant to imply that we're not talking about this. Let me know if there was something that I said that made you feel otherwise!

What I am discussing is a possible approach for how we might make this available to users who need it — like yourself. To put it another way, adding --additionalHeader to an existing command (rover graph publish) that was purpose-built for a particular need isn't the only place to add new functionality, and there's a lot of other things that I can imagine you'll need to configure in Explorer. We also need to be considerate of Federated workflows (e.g., rover subgraph publish) whose commands roughly mirror rover graph publish.

If we could entertain my design consideration: in your CI, could you run the existing command as you do above (without the --additionalHeader flags you've imagined) and then immediately follow it up with a command that clearly sets Explorer-specific properties, like headers?:

$ rover graph publish mygraph@my-variant \
     --schema ./schema.graphql \
     --endpoint=https://myserver.com/
$ rover explorer config mygraph@my-variant \
    --defaultHeader 'myheader=myvalue'

Thoughts?

[kmcrawford]

@abernix That is fine, it seemed the launch suggestion above was for an interactive cli that developers would run and "launch" a studio session vs a setup that the CI/CD process can do in an automated fashion. Thank you for your consideration on this issue.

For completeness somethings like:

$ rover explorer config mygraph@my-variant \
    --endpoint https://myserver.com/graphql
    --includeCookies true
    --defaultHeader 'myheader=myvalue'
    --defaultHeader 'myheader=myvalue'

Or for Subscriptions: (not my use case but I'm sure others would require this too)

$ rover explorer config mygraph@my-variant \
    --subscriptions https://myserver.com/graphql
    --subscriptionImplementation <value>
    --includeCookies true
    --defaultHeader 'myheader=myvalue'
    --defaultHeader 'myheader=myvalue'

[abernix]

Ah, I see. My offering of rover explorer launch <graphRef> was just to offer a concrete suggestion of other rover explorer commands that might be worth considering. In this case, rover explorer launch <graphRef> would literally open a web-browser to Explorer. (And if you'd run rover explorer config then it'd have the headers set already!).

[niodice]

I'll add a +1 to this feature request. We have a similar use case to automate the creation of graph variants, and a key developer experience will be have an "out of the box" explorer that is properly configured to talk to the backend we spin up.

[vini-gorillas]

Hello, Is it possibel to configure the endpoint in the connection settings via the CLI? or someone managed it with some other tricky way? My current setup requires me to manually add this end point which defies using it in the CI tool. any hints?

[niodice]

I was able to set the endpoint using the mutation below:

        mutation SetGraphEndpoint($graphId: ID!, $variantName: String!, $endpoint: String) {
            graph(id: $graphId) {
                variant(name: $variantName) {
                    updateURL(url: $endpoint) {
                        url
                    }
                }
            }
        }

You can check out other operations you can do against their API here: https://studio.apollographql.com/sandbox/explorer

[vini-gorillas]

But in order to run a mutation wouldnt you want the endPoint to be set? When i try to run the Mutation from the explorer, it pops up to add the connection string. Along with the error

Cannot query field "graph" on type "Mutation".

Coudl you explain how you were able to add the connection string with the mutation.

[niodice]

But in order to run a mutation wouldnt you want the endPoint to be set? When i try to run the Mutation from the explorer, it pops up to add the connection string. Along with the error

Cannot query field "graph" on type "Mutation".

Coudl you explain how you were able to add the connection string with the mutation.

Which API endpoint are you invoking the request against?

Here is a bit of (python) code to get you started:

APOLLO_API_KEY = "<YOUR API KEY GOES HERE>"

def set_endpoint(graph, variant, endpoint):
    mutation = """
        mutation SetGraphEndpoint($graphId: ID!, $variantName: String!, $endpoint: String) {
            graph(id: $graphId) {
                variant(name: $variantName) {
                    updateURL(url: $endpoint) {
                        url
                    }
                }
            }
        }
    """

    variables = {
        "graphId": graph,
        "variantName": variant,
        "endpoint": endpoint
    }

    requests.post(
        "https://graphql.api.apollographql.com/api/graphql",
        json={
            "query": mutation,
            "variables": json.dumps(variables)
        },
        headers={
            "x-api-key": APOLLO_API_KEY
        }
    )