Consider allowing clients to set response priority with @defer(order: Int).

[theengineear]

Has this forum considered allowing the client to specify an order? It would guarantee that data for order: N not be returned before data for order: M. The spec appears to leave prioritization up to the server. I think this control structure may be backwards.

query {
  search(text: "Han Solo") {
    name  # This cannot be deferred for desired UX.
    picture  # This cannot be deferred for desired UX.
    totalCredits: @defer(order: 1)  # This can be deferred, but should return second for desired UX.
    friends @defer(order: 2) {  # This can be deferred, but shouldn't return before "totalCredits" for desired UX.
      name
      picture
    }
  }
}

I really want to emphasize the “for desired UX” comments in the above snippet. I believe that the client is really the only entity which can truly know the right thing to do.

Disclaimers & Qualifications

This is a cross-post from graphql/graphql-wg#1077. I perused Enforcing delivery order of payloads and while I think those specifications make sense, I think they may not go quite far enough to enable clients.

I think it could be argued that via the label, a client could write custom code to manage this in the front-end — I’m suggesting that we should encode this in the server-side code (versus requiring that clients encode it themselves).

Please note that I haven't considered how this might interoperate with the @stream directive. I've also not considered validity checking on nested @defer or @stream directives — I'm just hoping to raise a potential concern about the core control structure here.

❤️ — Thanks very much for taking the time to read this. Apologies for any / all naivety and apologies if this has been covered (my initial searches didn't turn anything up).

[robrichard]

@theengineear thanks for your feedback. I think this is a good candidate for something that could be proposed after the initial defer & stream proposal is accepted. I don't think the current spec proposal would prevent something like this from being added in the future since we would still need to specify a default when order is not provided. What do you think?

[theengineear]

Makes sense to me! Is there additional work / championing I'd need to do, or would this discussion thread just get revisited later?

Thanks for taking a look @robrichard!

[yaacovCR]

If we allow a nested deferred fragment to defer relative to fields in the current fragment, we get fragment ordering without the need for "absolute" arguments.

See #43