You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@nmaquet something for the v2 roadmap: I think the strategy of hiding boundary queries from the gateway schema is a good default, however it thwarts dog-fooding when there’s a query method explicitly intended to perform double-duty for both public and gateway traffic. This is particularly important when federating with locked API releases that forbid schema changes.
My suggestion would be to include an option for boundary accessors that opts them into the public schema. Conflicting public accessors would simply fail validation.
The text was updated successfully, but these errors were encountered:
@nmaquet something for the v2 roadmap: I think the strategy of hiding boundary queries from the gateway schema is a good default, however it thwarts dog-fooding when there’s a query method explicitly intended to perform double-duty for both public and gateway traffic. This is particularly important when federating with locked API releases that forbid schema changes.
My suggestion would be to include an option for boundary accessors that opts them into the public schema. Conflicting public accessors would simply fail validation.
The text was updated successfully, but these errors were encountered: