Open ddcollins opened 3 years ago
Source level transforms are reflected to the in context sdk and encapsulation creates another level. Incontext sdk doesn't work well with deeper fields so I don't recommend you to use encapsulate transform in that way. We prefer to use encapsulate when we use Mesh as SDK instead of gateway. Prefix transform would be better choice for you.
We have a similar problem. As our mesh graph grew we decided to start encapsulating some parts. This however does not work with resolver composition because the nested fields are not present in the field map, as mentioned above. Is there any way encapsulation can work with resolver composition? Or is it planned to have something in that direction in future?
The alternative solution to use prefixes does not scale very well, in my opinion.
Describe the bug After encapsulating a json schema handler source, the "Api" functionality breaks.
I have a
Me
type with aninstructor
field which is resolved withTrainingAPI.api.instructor({id: user.crmId})
However, after encapsulating the TrainingAPI source I now get an error from the
TrainingAPI.api.instructor({id: user.crmId})
call:Environment:
Additional context
In
@graphql-mesh/runtime/index.cjs.js
the field name the functionality is looking for is not in the field map, as the field map now hastraining
as the query, so thefield
variable is left undefined.Console.log output: