feat: rover dev should extend a remote supergraph with a local subgraph

[EverlastingBugstopper]

I'm thinking we could take a similar plugin approach that we have with supergraph compose.

auto-download the correct router version that matches the composition version that Rover selects, and put it in ~/.rover/bin/router-v2.0.0. Rover could run the router with a call to execvp or something similar, may want to just use std::process::Command to make sure it works on Windows.

Biggest unanswered thing here is a good config story.

[EverlastingBugstopper]

To really follow the pattern here, will need to support downloading router binaries via Orbiter. This function provides rover.apollo.dev/tar endpoints that support versions and target triples.

switch statements in this file should be updated to support the router

[EverlastingBugstopper]

originally posted by @BrynCooke in #1130

It's be good to start discussing a basic subcommand for Apollo Router.

Things that we may want to do + questions:

• Scaffold a new router as a library project

  • Can we use https://github.com/iomentum/cargo-scaffold? (we can)
  • plugin-new (Create a new plugin)
  • plugin-search (List plugins on the marketplace)
  • plugin-add (Add an existing open source plugin)
  • How are plugins published?

• Run the router.

  • How is version of router pinned?
  • What if there's custom plugins?
  • In the case of custom code are we replicating cargo?
  • Do users have to have cargo installed?
  • How do we ensure minimum Rust version?

Part of the problem for us is that users who just want to run the Router binary will have very different wants and needs from those who are building their own version of the router.

[EverlastingBugstopper]

Part of the problem for us is that users who just want to run the Router binary will have very different wants and needs from those who are building their own version of the router.

As for initial scoping, we should not worry about how folks build their Router binaries. We should download the router at runtime just like we do for the supergraph plugin (and maybe even distribute it as a part of the supergraph plugin itself). Folks can then patch in their own binaries if they really need to right away but for a first pass, only officially distributed binaries will be supported.

[abernix]

As for initial scoping, we should not worry about how folks build their Router binaries.

agree.

Folks can then patch in their own binaries if they really need to right away but for a first pass, only officially distributed binaries will be supported.

yup. we don't need to focus on it for the first pass at this. we have a number of options as to how this can work and be configured and the build configuration is one of those ways.

[EverlastingBugstopper]

this will be exposed via rover subgraph dev, which will extend a remote supergraph schema with a local subgraph and provide a local router endpoint to run queries against. docs for this might look like this:

Develop your subgraph

You can make changes to your subgraph locally, and run rover subgraph dev to get a local router endpoint that you can use to test your subgraph's compatibility with the rest of the supergraph. This is useful for integration tests and for providing front-end developers with possible changes before they hit production.

$ rover subgraph dev --log debug
Reading contents of .apollo/project.yaml...
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
  }  
}
Checking status of http://localhost:4000/graphql...
DEBUG Detected apollo-server subgraph implementation
DEBUG Found router binary in ~/.rover/bin/router-v0.10.0
DEBUG Found composition binary in ~/.rover/bin/supergraph-v2.0.6
Composing 'my-subgraph' into 'my-supergraph@current'...
Starting graph router for 'my-supergraph@current' extended with local 'my-subgraph'...
Listening for requests at http://localhost:7777/graphql...

[ndintenfass]

I'd like to talk about the top level rover dev here - it may be better to let the contents of .apollo drive the behavior instead of making dev a verb under the core hierarchy.

[BrynCooke]

We should also talk about where the router config fits into all of this.

[EverlastingBugstopper]

I'd like to talk about the top level rover dev here - it may be better to let the contents of .apollo drive the behavior instead of making dev a verb under the core hierarchy.

Yup! This is essentially the plan but perhaps I did not make it super clear. My plan for rover subgraph init to create a .apollo/project.yaml with a project_type: subgraph field at the top level. rover init can then ask for a --project-type or prompt the user for what type of project they want to generate when running rover init and it will call the appropriate {project-type-verb} init command under the hood. So,

This pattern would then extend to rover publish, rover check etc - all based on the project_type key/value pair, making it a pretty powerful aliasing pattern that we can easily extend to "supergraph", "graph", and "client" projects in the future.

We should also talk about where the router config fits into all of this.

Agree, this needs solidifying. Long term I want to have a rover supergraph init and rover supergraph publish commands for more sophisticated router users, but Studio API folks say that is something that will be only really be possible later on in the year. As a first pass I believe the constraint here is that Rover cannot modify the router config locally (except maybe a few things like the port it's running on). when you run rover subgraph dev - it will pull down the router config from the studio api if it exists and use that for the local router binary. i'm interested in what exact config you think is absolutely necessary for a local dev experience like this.

[EverlastingBugstopper]

this got pretty stale and I think we strayed pretty far from implementation here. closing this and will re-open with a pruned description now that we've shipped the first version of rover dev.

[EverlastingBugstopper]

opened #1494