proposal: create a `dev` plugin

[EverlastingBugstopper]

trafficstars

after talking with @BrynCooke this morning, we have come up with a potential development workflow that could work for any router running anywhere (without tunnels).

the idea goes something like this:

1. acme-corp has infrastructure for "dev" subgraphs, say products, films, and users. they all have dev databases and servers backed by heroku.
2. acme-corp has published these subgraphs to Apollo Studio and associated them with the acme-corp@dev graph variant
3. acme-corp has a router deployed to https://dev.acmecorp.com with the dev plugin enabled, and this endpoint is stored in the "connection settings" for a graph ref
4. mara want to make a change to the products subgraph
5. mara goes to the products subgraph on her local machine, and runs rover dev acme-corp@dev --name products --schema ./products.graphql --url http://localhost:4001
6. rover dev requests a session ID from https://dev.acmecorp.com, which is auto-generated by the dev plugin
7. rover dev connects to the dev router via a websocket connection, which it initializes by sending the session ID
8. rover dev sends the products subgraph definition (name, url, sdl) to the dev router over the websocket
9. the dev router receives the incoming subgraph definition over the websocket, and creates an "alternative" supergraph schema associated with the session ID
10. if composition succeeds, the router sends an "ok ready" message over the websocket, if it fails, it sends the composition error over the websocket
11. the router starts to listen for incoming requests that include an X-Apollo-Dev-Session-ID header.
12. once rover dev has received the "ok ready", it spins up a local proxy server at http://localhost:3000
13. this proxy server sends all incoming requests to https://dev.acmecorp.com along with the session ID
14. any time the router receives an incoming request with a session ID header, it executes a query plan using the supergraph schema for that session
15. the query planner itself may need to route requests to the local machine, in this scenario, the request payload should be sent over the websocket to rover dev which will pass along the request to the subgraph
16. the local subgraph resolves incoming requests from the query planner, and rover dev returns a regular HTTP response to the request coming from the query planner
17. the router receives the subgraph response, and aggregates its data along with the data received from the other deployed dev subgraphs, which it then sends back as the HTTP response to the initial HTTP request
18. rover dev will watch the local subgraph for any changes, and if they are found it will send the subgraph definition over the websocket again, requiring the router dev session to recompose and reload
19. if another rover dev session is established with the same graph ref on a different machine, a new dev session id is created for it
20. if you run another rover dev session on the same machine with the same graph ref, it will start sending its own subgraph updates on the same websocket connection as the first session
21. if you start a session on one machine and note the session ID, you can run rover dev on a completely different machine with a --session-id, which will start sending its own subgraph updates on the same websocket connection as the first session

[EverlastingBugstopper]

re: implementation details, this could be a router plugin or it could be a sidecar. i imagine the sidecar would be something like rover supergraph dev which would take care of re-composing from the incoming subgraph definitions.

i do not think we should have the subgraph developer session in charge of composition as it will require much larger messages over the wire, and selecting a composition version would be up to the subgraph developer (or the version would also need to be sent over the wire).

co-locating the composer with the router also allows us to create dev "sessions" that can be attached to from multiple different machines.

[EverlastingBugstopper]

i've just updated the top-level comment to interface more directly with apollo studio, but i don't think it changes the implementation of the router dev plugin at all.

[EverlastingBugstopper]

closing: taking a different approach