Absinthe: Resolve one field before another (or dependencies between field resolvers)

[futpib]

Consider this query:

{
    issue {
        body
        bodyHTML
        bodyText
    }
}

Imagine body is not immediately available on the issue and has to be resolved.

Imagine we want to define resolvers for bodyHTML and bodyText based on the resolved value of body.

Absinthe does not provide a way to impose a resolution order on fields or dependencies between resolvers.

JS world has graphql-resolvers that does this.

[benwilson512]

Hi @futpib. In general please use the forums, slack, or other Elixir help locations to ask questions, the issue tracker is for issues. To your question, check out the https://hexdocs.pm/absinthe/Absinthe.Resolution.Helpers.html#batch/4 middleware, it will allow you to hand off resolution of the fields to a batch function that can look up the values in whatever order you want, and then return the data.

As a final note, I would perhaps consider an API that looked like: issue { body { html text } } Then you wouldn't need to worry about this at all!

[futpib]

I am using batch and dataloader to achieve this, but it feels more like a workaround (with significant boilerplate) rather than a first-class solution like graphql-resolvers.

[binaryseed]

From my understanding of the GraphQL spec:

1) Fields are _returned_ in the order they appear in the query, but execution order has no guarantees (also it could be done completely in parallel)
2) Resolution of a field has no knowledge of the sibling fields result, only the source object

Given that, this kind of behavior would be well suited for a custom middleware, but not something that we're likely to support inside Absinthe itself. Similarly, graphql-resolvers is an add-on library, not part of the graphql library.

Thanks for understanding!

[benwilson512]

Right, and as an additional note, the API to batch middleware is definitely verbose, but:
1) it is 100% first class, it's built into absinthe itself
2) It is verbose because it's generic, the idea is that you're supposed to create helper functions that simplify the API for your specific use case. So for example, batch loading of ecto associations is achieveable with a single function call as the main API.