Why we need to duplicate fields for different labels?

[IvanGoncharov]

Following #52 (reply in thread) by @yaacovCR it seems we adding a lot of complexity and workarounds to allow duplicating defer fields with different labels.

Given this query:

{
  ... @defer(label: "a") {
    someField
  }
  ... @defer(label: "b") {
    someField
  }
  someField
}

we need to send value of someField 3 times.

Why do we need this?

Solution:

I want to solve this separately from #52, so the solution is entirely based on the current proposal and doesn't include any ideas from #52.
I propose to treat incremental items as a path and follow the "merge patch" approach (an idea is borrowed from RFC 7386)
Given query:

{
  ... @defer(label: "a") {
    f2
    f3
  }
  ... @defer(label: "b") {
    f2
    f4
  }
  f1
}

I suggest following response format:

{
  "data": {
    "f1": 1
  },
  "hasNext": true
}

{
  "incremental": [
    {
      "path": [],
      "data": {
        "f2": 2
      },
    }
  ],
  "hasNext": true
}

{
  "incremental": [
    {
      "path": [],
      "fullfiledLabels": ["b"],
      "data": {
        "f4": 4
      },
    }
  ],
  "hasNext": true
}

{
  "incremental": [
    {
      "path": [],
      "fullfiledLabels": ["a"],
      "data": {
        "f3": 3
      },
    }
  ],
  "hasNext": false
}

Benefits

• Smaller payload
• Simple mental model of "partial response followed by optional series of patches" without any semantic overhead of response branching on "label"s
• Ability to defer individual fields without the overhead.

Complex example1

{
  ... @defer(label: "a") {
    f2 { a b c { d e f { h i } } }
  }
  ... @defer(label: "b") {
    f2 { a b c { d e f { h j } } }
  }
}

{
  "data": {},
  "hasNext": true
}

{
  "incremental": [
    {
      "path": [],
      "data": {
        "f2": {
          "a": "a",
          "b": "b",
          "c": {
            "d": "d",
            "e": "e",
            "f": [
              {
                "h": "h",
              }
            ]
          }
        }
      },
    }
  ],
  "hasNext": true
}

{
  "incremental": [
    {
      "path": ["f2", "c", "f", 0],
      "fullfiledLabels": ["a"],
      "data": {
        "i": "i",
      },
    },
    {
      "path": [],
      "fullfiledLabels": ["a"],
    },
  ],
  "hasNext": true
}

{
  "incremental": [
    {
      "path": ["f2", "c", "f", 0],
      "fullfiledLabels": ["a"],
      "data": {
        "j": "j",
      },
    },
    {
      "path": [],
      "fullfiledLabels": ["b"],
    },
  ],
  "hasNext": true
}

[glasser]

In your first example, it seems like the "state" between messages 2 and 3 (when we have f2 but not f3 or f4) does not correspond to any specific set of deferred fragments being resolved. That seems wrong to me? It seems like the whole point of putting defer at the fragment level is so that when doing codegen etc you can say "at any given time, either an entire deferred fragment is available or it's all missing (other than nested defers/streams/etc)". Which this breaks? I mean I think I like the overall concept, but I'd want to see f2 only come in with either f3 or f4.

[robrichard]

This proposal has evolved and is now being discussed here: #65 (comment)