Is your feature request related to a problem? Please describe.
fyi @kcbabo @saiskee
A big part of the value proposition of GraphQL in envoy at edge or in the mesh with discovery is the automatic "one button" click to enable graphql in your entire org as a super graph.
The way this works is:
enable graphql discovery
a GraphQLApi CR is discovered and persisted for each microservice in the org
assume no type conflicts and thus manual type merging config is required...
a parent GraphQLApi CR references all these discovered CRs and any envoy (either edge or mesh) can now make GraphQL queries to the supergraph, a composition of all discovered GraphQLApis
This was likely an intentional decision in the first pass to ensure breaking changes and type conflict is simpler as new GraphQLApis are discovered / deleted over time.
Describe the solution you'd like
Support for complex label selectors on GraphQLApis, as well as a robust change management design doc to ensure we don't have any confusing behavior.
For example, we need to ensure that we have sane behavior for GraphQLApi breaks to schemas / merging, particularly in the case of rolling the control plane pods (i.e. just serving last known good config isn't good enough if we can't regenerate this last known good config from the CRs and label selectors)
This issue has been marked as stale because of no activity in the last 180 days. It will be closed in the next 180 days unless it is tagged "no stalebot" or other activity occurs.
Version
No response
Is your feature request related to a problem? Please describe.
fyi @kcbabo @saiskee
A big part of the value proposition of GraphQL in envoy at edge or in the mesh with discovery is the automatic "one button" click to enable graphql in your entire org as a super graph.
The way this works is:
GraphQLApi
CR is discovered and persisted for each microservice in the orgGraphQLApi
CR references all these discovered CRs and any envoy (either edge or mesh) can now make GraphQL queries to the supergraph, a composition of all discoveredGraphQLApi
sThe API today only allows a repeated list of refs to other
GraphQLApi
s, thus stitching cannot be automated org-wide: https://github.com/solo-io/gloo/blob/master/projects/gloo/api/v1/enterprise/options/graphql/v1beta1/graphql.proto#L275-L276This was likely an intentional decision in the first pass to ensure breaking changes and type conflict is simpler as new
GraphQLApi
s are discovered / deleted over time.Describe the solution you'd like
Support for complex label selectors on
GraphQLApi
s, as well as a robust change management design doc to ensure we don't have any confusing behavior.For example, we need to ensure that we have sane behavior for
GraphQLApi
breaks to schemas / merging, particularly in the case of rolling the control plane pods (i.e. just serving last known good config isn't good enough if we can't regenerate this last known good config from the CRs and label selectors)Describe alternatives you've considered
No response
Additional Context
No response