CCN’s ? can save normalized caches from null bubbling corruption about nullability-wg HOT 4 CLOSED

in an ideal world, would Relay have GraphQL inline the error rather than returning it in a separate errors list?

I see that you answered your own question regarding that particular encoding scheme, but to answer your question more broadly, I think you're spot on. With explicit error handling, Relay is going to start thinking of the response as a single tree that just happens to encode errors in a look-aside array for the purposes of unambiguous JSON encoding. Relay's runtime is sufficiently sophisticated to be able to, in essence, perform that transformation on the client.

So, for us, the only advantage of a server response that actually was a single tree, would just be some slight performance advantages when interpreting the server response.

from nullability-wg.

It would be wise for Relay to not only add ? to every non-null field, but to nullable fields to in case the schema evolves (since changing a nullable output field to non-nullable is generally seen as non-breaking). Perhaps a shortcut could be to place a ? after the operation name: query Foo? {…}

from nullability-wg.

Good point about schema changes! Ultimately what a client like Relay wants, both for the purpose outlined in this post as well as the True Nullability Schema goal outlined in #19, is an option to opt out of null bubbling globally, exactly as you propose.

A global flag like this more elegantly describes what Relay, and other sufficiently-smart normalizing clients, wants. In addition a global flag would be approachable for simpler clients that don't transform a user-defined query. Although, for those middle-tier smart-clients that don't transform, maybe they would prefer that the flag be supplied as a header or http query variable. That way the client could select the execution mode without needing the user's participation (adding the query-level annotation)...

I'm was a bit hesitant to propose a change where a top-level annotation forks execution behavior for the full query. Having two separate execution modes sounds undesirable from the perspective of the spec and also the mental overhead of the whole ecosystem. That said, I think the value that could be unlocked by a true nullability schema is considerable and would likely be worth the added complexity.

I think the big question here is:

For smart clients that can handle errors client-side, a single top-level annotation like you propose would obviate the need for the rest of CCN. Should we consider skipping CCN, with its complexity, limitations, and tradeoffs, all together and try to make the jump straight to True Schema Nullability?

Some outstanding questions are:

1. How do simple clients stay resilient in the face of a true nullability schema? (Does it matter?)
2. How practical is it to migrate to a true nullability schema? Legacy clients (apps that have been deployed) will be retroactively opted into a less resilient execution mode.

from nullability-wg.

Question: in an ideal world, would Relay have GraphQL inline the error rather than returning it in a separate errors list? I'm thinking:

{ // Response B (without null bubbling)
  "data": {
    "me": {
      "id": "10",
      "age": {
        $$isError: true, // <-- note that this key is not possible through aliases, but could happen in custom scalars... Risky.
        "message": "Age errored",
        // no need for "path"
      } // <-- Errored, but did not bubble!
    }
  }
}

Answer: we can't do this, because of custom scalars. If your JSON field errored, there's no way for the client to differentiate this between an actual error and data that happens to contain $$isError: true.

from nullability-wg.