We’re standing up managed federation right now and while it’s very early I can already see that we’re going to need to manage local development flow. It seems that for the most part you should never have to run more than a gateway and two subgraphs to develop locally. That’s not so bad but now we need to effectively manage ports in startup scripts or docker containers to make sure that there aren’t annoying collisions when running two or more subgraphs. Maybe that’s the best we can do? Maybe we’ll always have to manage unique ports on our subgraphs.
What I’m wondering is if there is a way to point our gateway to a deployed graph and override one or more subgraphs to point to local addresses. This would be way more flexible for developers who just want to do something like extend a type.
I’ve had some discussions with folks at other companies and one mentioned they had developed a custom gateway solution like this with direct help from Apollo. I’d love to hear what people are doing and if there is best practice around local dev flow.
Hello! After confirming with our Solutions team, it sounds like the recommended strategy is to use non- managed federation specifically for local development, and use the Rover CLI to generate a supergraph schema for your locally running gateway.
The config file you provide Rover’s supergraph compose command specifies the routing_url for each subgraph. The routing_urls for the subgraphs you’re modifying locally can be localhost URLs, while the rest can point to subgraphs in your cloud environment.
To make sure you’re always using the latest registered subgraph schemas for your locally composed supergraph schema, you can use rover subgraph fetch to fetch each schema from Apollo Studio before performing composition.
I hope this helps, and please feel free to post any followup questions!
1 Like
Alrighty, thanks for the info.
I built some tooling around this and it works relatively well. I think we’re still going to have to manage unique ports across the subgraphs otherwise folks will need to modify local startup scripts every time they want to run more than one graph locally. For now I’m trying to manage ports by publishing subgraphs to a local variant, then using rover to pull in the urls for the local variants and use those to override subgraphs that i’m pulling from our QA variant. This way devs can just modify their env files with the names of the subgraphs that they want to override and everything just works.
We can make lots of improvements from here but for now this will get us up and running. Thanks again!
I’d like to make this work, but the Securing Your Subgraphs guidance is to not expose your subgraphs directly to clients; it seems like my localhost gateway won’t be able to access the subgraphs running in our cloud environment (not exposed to the public, using internal kubernetes routing). Do you have any advice on how to set this up? Thanks!
@ericbock If possible, use a VPN to hit your subgraphs that are secured behind your cloud network infrastructure. That’s what we’re doing on AWS.
1 Like
Or if your using kubernetes and have a dev cluster you could do port forwards and connect to those deployed subgraphs that way
Hi Adam, we are exactly looking for getting our local development workflow up and running and were wondering if you would consider sharing with us this tool of yours? Maybe sharing it on github so we could do some collaboration to make it better?