We want to have a federated graphQL implementation that at the start will only have one subgraph. In order to get this working, we’ll need the gateway to have it’s own subgraph at the beginning. This doesn’t seem possible with managed federation (we don’t want to start out with serviceList). Has anyone run into this or found a workaround?
Hi, any success with this? We are trying the same approach
I am not sure what you are gaining by starting out with federation. If you have a single graph, run that way until you build a second, and then at that time build your gateway too. It will not change your graph paths.
Otherwise you need to setup federation as intended with a gateway and a separate sub-graph.
Yes, we did - we are using managed federation however. What we did is create a gateway and then create another apollo service that runs in the same pod as our gateway but is technically a second service. Then we have our first (independent) subgraph running elsewhere and they compose nicely. I can give more details if you’d like.
1 Like
Hello, apologies for the late followup, but this bootstrapping strategy sounds good! To my knowledge, it isn’t possible for a single instance of Apollo Server to function as both a gateway and a subgraph.
What we gain is the ability to understand how federation works and what is needed to set it up so that the rest of our organization can eventually adopt graphQL. There’s quite a bit to get to know about federation that affects other technology choices as it turns out so it was in our best interest to get all of that working first. After we POC this, the next team that wants to plug in a graph to our supergraph will have a whole lot less work to get up and running.
Managed federation promises better startup time than unmanaged federation. That would be my least concern. You could work across setting up subgraphs and associating with gateway. You team can work independently for both of the cases.
To answer your question, managed federation has nothing but “you” or “a cron job” running rover commands (for introspection) over subgraph stack and publishing to apollo graph registry. Gateway uses apis to fetch the supergraph sdl from apollo registry. Hence we are able to achieve faster runtimes. However, you will need to perform this “indirect composition” for every stage which will be used by gateway.
Thanks,
I’ve done something similar. Create a new Apollo service and pointed the federation gateway to it. Not the best but we can now have the legacy micro services that we can not touch of business reasons connected.
1 Like