Resolve-order

[annitya]

Hi!

Is there any way for async resolvers to depend on each other? I have this situation here popping up all over the place: https://gist.github.com/annitya/fd156bc98976219c1e108f3267560ec6

eventsOwnerIds depends on the result from the asset-resolver, but it is unavailable.

A lot of the fields on the various entities are results of async api-calls.
It's a shame that I'm unable to use half of my objects :-/

Would it be possible to create a "dependsOn" decorator using this library or something similar: https://github.com/lucasconstantino/graphql-resolvers?

[MichalLytek]

This is a really nice feature that would be very useful to add! ❤️

Please create a dedicated feature request, with a proposed API and some details of the goal you would like to achieve 😉

[annitya]

I'm so glad that you feel that way :) I'm still somewhat new to the GraphQL scene, so I will have to give it a little more thought before I submit the request.

[annitya]

Feature request: #898

[backbone87]

what you could do is something like this:

@Resolver(() => GraphTimeseries)
export default class GraphTimeseriesResolver implements ResolverInterface<GraphTimeseries> {
    @FieldResolver()
    async asset(@Root() timeseries: GraphTimeseries, @Ctx() source: Source) {
        timeseries.asset ??= source.getAssetById(timeseries.assetId);

        return timeseries.asset;
    }
    
    @FieldResolver()
    async eventsOwnerIds(@Root() timeseries: GraphTimeseries, @Ctx() source: Source, @Info() info) {
        timeseries.asset ??= source.getAssetById(timeseries.assetId);

        const asset = await timeseries.asset;
    }
}

you can also create a resolver decorator for this:

@Resolver(() => GraphTimeseries)
export default class GraphTimeseriesResolver implements ResolverInterface<GraphTimeseries> {
    @FieldResolver()
    @FetchAsset(({ root }) => root.assetId)
    async asset(@Root() timeseries: GraphTimeseries, @Ctx() source: Source) {
        return timeseries.asset;
    }
    
    @FieldResolver()
    @FetchAsset(({ root }) => root.assetId)
    async eventsOwnerIds(@Root() timeseries: GraphTimeseries, @Ctx() source: Source, @Info() info) {
        const asset = await timeseries.asset;
    }
}

[ZackMitkin]

When both field resolvers get called, it'd still fetch twice

[MichalLytek]

Move the caching responsibility to the upper level - getAssetById() layer should handle returning cached data when requested earlier.

[ZackMitkin]

That seems like more work, managed to get it to call once by placing the promise in ctx instead

[backbone87]

When both field resolvers get called, it'd still fetch twice

No it wont be fetched twice. The assignment timeseries.asset ??= source.getAssetById(timeseries.assetId); is sync. Only after the assignment you await the promise.

You can verify this easily by adding a counter or log statement to getAssetById

[ZackMitkin]

I managed to get this working by modifying @backbone87 answer. I just put the Promise into ctx state

export default class GraphTimeseriesResolver implements ResolverInterface<GraphTimeseries> {
    @FieldResolver()
    async asset(@Root() timeseries: GraphTimeseries, @Ctx() ctx: Source) {
        ctx.state.asset ??= source.getAssetById(timeseries.assetId);

        return ctx.state.asset;
    }
    
    @FieldResolver()
    async eventsOwnerIds(@Root() timeseries: GraphTimeseries, @Ctx() source: Source, @Info() info) {
       ctx.state.asset ??= source.getAssetById(timeseries.assetId);

        const asset = await ctx.state.asset;
    }
}

[MichalLytek]

The order of execution is determined by graphql-js. It may just call eventsOwnerIds and after that asset.

[MichalLytek]

Your workaround "works" for you, and that's ok. But do not recommend wrong, hacky "solutions" to others.

Your schema design is not GraphQL idiomatic and grouping, batching and caching should be done on the data-fetch layer, not in the resolvers.

[ZackMitkin]

Should be parallel though right? If they're placed in a Promise.all I should still see root's change

[ZackMitkin]

Your workaround "works" for you, and that's ok. But do not recommend wrong, hacky "solutions" to others.

Your schema design is not GraphQL idiomatic and grouping, batching and caching should be done on the data-fetch layer, not in the resolvers.

I agree, just trying to fix up old code. Thanks for the feedback though I will approach it from the data fetch layer.

[backbone87]

Should be parallel though right? If they're placed in a Promise.all I should still see root's change

JS is not parallel. It may execute only 1 piece of code at a time. What JS can do is break the current execution context if there is async work to be done and continue on another piece of code until the async work is ready.