Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: How to support feature flags in queries. #900

Closed
john-twigg-ck opened this issue Nov 13, 2019 · 7 comments
Closed

Question: How to support feature flags in queries. #900

john-twigg-ck opened this issue Nov 13, 2019 · 7 comments
Labels
question Issues that have a question which should be addressed

Comments

@john-twigg-ck
Copy link

TL;DR
Question: Does anyone have any good methods of supporting Feature Flags for portions of the queries?

Problem:
We're using the apollo-codegen for both iOS and Android.
There is a tight coupling between the client and the server with respect to the schema.

Example:

  1. Schema is updated to v1.1
  2. Server is updated to v1.1
  3. Client is updated to v1.1 and starts querying for the new fields
  4. Server rolls back to v1.0

One option is to have a highly dynamic schema registry system on the server so as to not allow rollbacks. Let's table that idea for now.

Question: Does anyone have any good methods of supporting Feature Flags for portions of the queries?

Note: I know you can pass in parameters to switch off parts of the query but they don't work with fragments as there's no parameterized fragments ex: @skip(if: Boolean) doesn't work in fragments

Ideal Example might be

query {
   offers { 
       ...offer
   
   }
}

fragment offer on Offer {
   apr
@if global.flagApprovalOddsEnabled
   approvalOdds 
@endif 
}

Challenges

  • iOS and Android Code gen needs to be modified
@designatednerd
Copy link
Contributor

Ouch. Yeah I think the idea that your server would roll back to 1.0 once 1.1 had made it that far out the door is not something GraphQL is particularly designed to support. Lemme ping a couple folks.

@designatednerd
Copy link
Contributor

designatednerd commented Nov 13, 2019

One thing I did think of: You can use directives that determine whether to include a fragment. You'd have to write two fragments, one for each version, but then you should be able to use the @include directive to pick which of the fragments to use.

(edit: Here's an example of using @include with a fragment)

@designatednerd
Copy link
Contributor

@jbaxleyiii suggests trying something that defines the variable in the query and then uses it in the fragment, like:

query($showApproval: Boolean!) {
   offers { 
       ...offer
   }
}
fragment offer on Offer {
   apr
   approvalOdds  @include(if: $showApproval)
}

For what it's worth the spec for @include doesn't seem to have any prohibition on using it in a fragment.

@designatednerd
Copy link
Contributor

@john-twigg-ck Does this answer your question?

@john-twigg-ck
Copy link
Author

@designatednerd
I don't think this works, because showApproval is not visible inside fragment offer on Offer

(Please tell me I'm wrong, because I hope I am)

This falls under the category of "Fragment Variables" which is at best experimental feature in Apollo and GraphQL spec

https://github.com/apollographql/graphql-tag/blob/50a850e484a60d95ddb99801c39785031e55b7a2/README.md#experimental-fragment-variables

graphql/graphql-spec#204

I'm open to other ideas.

@designatednerd
Copy link
Contributor

I just tried this out using the fullstack tutorial server that we're using to build the new iOS tutorial, and it looks like this is doable. Here's an example query with a fragment and the passed-in boolean set to true, so the ID is returned:

Screen Shot 2019-12-04 at 1 31 19 PM

And then here's an example where it's set to false, so the ID is not returned:

Screen Shot 2019-12-04 at 1 31 38 PM

Does that help?

@designatednerd
Copy link
Contributor

I am going to close this out since there is an example of what @john-twigg-ck has requested provided. John, if you have further questions here, please feel free to reopen. Anyone else, please open a new issue. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Issues that have a question which should be addressed
Projects
None yet
Development

No branches or pull requests

2 participants