Adding a new directive on a federated graph

Help
, , ,
1

I’ve two part question, I tried searching around, no avail.

Now, say I already have a federated graph, I want to introduce a new directive: @authorize which basically ensures a user is logged in. This obviously isn’t available for frontend to call.

But unfortunately my graphql server exports this on the _sdl of schema when I do federation.

I was able to remove only that directive, BUT I couldn’t get rid of actual usage of @authorize, which means the SDL is actually invalid (directive not found) if tried to parse.

If I can solve that issue it’s done, but in case I can’t, I want to be able to add directive, but last time I tried, apollo graphql said if you have directive @authorize in 1 subgraph, you will need that in all subgraph.

Then how do you actually deploy a new service which introduces a directive then?

2

I think I kinda have an answer, I’d love to validate this with someone who actually knows this.

So @authorize would be a type system directive and not an executable directive. Which will probably be ignored when checking. If this is the case, my problem is partially solved.

Now moving on to executable directives,

What’s enforced is that if 1 subgraph has a executable directive, then all subgraphs need to have that directive, say a subgraph A and subgraph B are in different release cycle, how exactly would I deploy a new directive for example: @upper if deploying at the same time is NOT an option?

3

Hey @cyberhck, it looks like you’ve figured out the type system vs. executable directives bit - that’s great!

In case it’s not clear, we treat these differently due to the client side implications. A client shouldn’t need to know which fields specifically it’s allowed to apply directives to, so we require every service to at least have knowledge of this directive (even if it chooses to do nothing with it) for validation purposes.

In order to roll this out, you will need to trigger multiple failed compositions in a row. We offer some guidance around this in our managed federation docs. The idea is that you will publish each subgraph even amidst validation errors - but once you resolve the final error, the new supergraph will compose successfully and your gateways will finally update.

4

Thanks trevor,
That answers all my questions :slightly_smiling_face:

1 Like