[normalize] Possibly include errors & extensions in normalized result

[smkhalsa]

Should we be caching GraphQL errors & extensions data? Before we can, we'd have to figure out...

Where to include them in the normalized result?

Errors and extensions are relevant to a specific Operation execution. However, we currently store selections from all operations of the same type in a single Map.

For example, we might receive the following server response:

{
  'data': {
    '__typename': 'Query',
    'posts': [
      {
        'id': '123',
        '__typename': 'Post',
        'author': {
          'id': '1',
          '__typename': 'Author',
          'name': 'Paul',
        },
        'title': 'My awesome blog post',
      },
    ],
  },
  'extensions': {
    'my': {
      'arbitrary': {
        'data': true,
      },
    },
  },
}

Which would be normalized under the shared Query key.

{
  'Query': {
    '__typename': 'Query',
    'posts': [
      {'\$ref': 'Post:123'}
    ]
  },
  'Post:123': {
    'id': '123',
    '__typename': 'Post',
    'author': {'\$ref': 'Author:1'},
    'title': 'My awesome blog post',
  },
  'Author:1': {
    'id': '1',
    '__typename': 'Author',
    'name': 'Paul',
  },
}

In order to save errors and extensions data, we'd need to separate data out for each operation. We could achieve this by flattening the Operation data, using the OperationName and variables to create a key, then store the data, errors, and extensions seperately:

{
  'Query:MyQueryName({someVar:true})': {
    'data': {
      '__typename': 'Query',
      'posts': [
        {'\$ref': 'Post:123'}
      ],
    },
    'errors': [
      {
        'message': 'Title for post with ID 123 could not be fetched.',
        'locations': [
          {'line': 6, 'column': 7}
        ],
        'path': ['posts', 123, 'title']
      }
    ],
    'extensions': {
      'my': {
        'arbitrary': {
          'data': true,
        },
      },
    },
  },
  'Post:123': {
    'id': '123',
    '__typename': 'Post',
    'author': {'\$ref': 'Author:1'},
    'title': 'My awesome blog post',
  },
  'Author:1': {
    'id': '1',
    '__typename': 'Author',
    'name': 'Paul',
  },
}

How would this impact client read / write functionality?

Should the client's readQuery / writeQuery functions return the entire response (including errors and extensions data), not just the data?

[smkhalsa]

@micimize any thoughts on this?

[micimize]

Hmm – I kind of don't think normalize should concern itself with things beyond data, as these aren't matters of normalization, but that they should definitely be a concern for caching

related: zino-hofmann/graphql-flutter#753

[smkhalsa]

I agree that caching errors isn't strictly a normalization concern. However, in practice, the normalization process determines the structure of the cached data, and if we want to store errors next to data in the cache (which I'd argue we would), normalization would have to take errors into consideration.

What's the downside to having normalize handle this?

[micimize]

@smkhalsa well, errors and extensions don't necessarily correspond to the data itself, but might be request level information. I believe we'd also have to make sure anonymous query A's errors and extensions don't get mingled with anonymous query B due to normalization.

Things worth considering:

• In Consider caching errors zino-hofmann/graphql-flutter#753 I was mistaken and Apollo doesn't actually cache errors
• In the spec, the extensions key is described as being "reserved for implementors to extend the protocol however they see fit." Which is pretty broad. dgraph uses it for the tracing of specific request resolutions

It might make sense to add a latestResponses concept to the cache though, which would save the latest extensions and errors to disk for all operations and saturate them with normalized data on cold starts

[smkhalsa]

I'm closing this since I don't plan to implement it.