@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.
@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.