Normalized Responses

[gyzerok]

Please read the following comment.

[gyzerok]

Here I come with the following API idea. We add one new function normalize which would be an opponent for resolve.

const userType = new GraphQLObjectType({
  name: 'User',
  description: 'User type',
  fields: () => ({
    name: {
      type: new GraphQLNonNull(GraphQLString),
      description: 'User name',
    },
    friends: {
      type: userType,
      description: 'User friends',
      resolve: (user) => {
        return find({ id: user.friends });
      },
      normalize: (friend) => {
        return friend.id;
      }
    }
  })
});

For now all GraphQL seems for me similar to serialization and I assume it would be cool to have a possibility of deserialization with existing schema.

What for? Purpose is the same you described in Relay. We always need to store some data in the cache on the client. But the problem is that we need to store deserialized data to be able to easily manage it and update with some server responses. On the other hand developers always want to minimize the amount of data which is passed between client and server. Lets assume that we've batched a few different queries in one request and run them agains GraphQL schema. After it we would have some deep data structures which probably we cannot merge. If we normalize them before sending we can merge all the responses and send them as one plain data structure. Than we merge this result with data on the client and are able to run Same GraphQL queries to get data in appropriate form.

Sorry for my bad English and pure explanation I hope you can get the idea behind this.

[leebyron]

Normalized responses require a lot more than just adding a method to normalization. It requires different validation rules and changes the shape of the result which requires specific handling by clients.

This is something we eventually want to do, but the implicates are large so we need a more comprehensive proposal.

[gyzerok]

@leebyron

1. Do you think validation rules are nessesary? Mb it is up to client to give it back correct data.
2. Yes, it requires specific handling by clients if we normalize data on the server. But we dont have to. The core idea here is to provide possibility, but its up to developer where to use it, on a server or on a client with isomorphic schema. So if one want to use it on the server its hes responsibility to deal with normalized data on the client.

I would write my full usecase of using this in a few days. I hope it would be helpful.

[gyzerok]

Hi, @leebyron!

You can check my solution: prepare GraphQL schema and normalize.
It works for me as expected, but do not support Interface and Union abstractions for now and expects id attribute. I'm gonna work more on this later.

[leebyron]

Closing this aging issue.

FYI, this is still something on the long term plan. Validation rules are necessary to account for a scenario where the same object may appear in two places in a normalized response with illegal overlapping fields. That is, an extension to http://facebook.github.io/graphql/#sec-Field-Selection-Merging

As you also discovered, you need some unique identifier to perform the normalization from. That must also end up in a final proposal.

I'm excited to share more details on this soon, as I've been thinking about it quite a bit.

[ghost]

@leebyron Did your thoughts on this amount to much in the end? Any further conclusions?

[andrewmclagan]

Normalisation would be an insanely useful feature.

[monojack]

You can give graphql-normalizr a try

[jonaskello]

If you want to do normalization and denormalization of GrapqhQL responses we developed graphql-norm for that purpose. It could be used to build client-side caching or returning normalized responses from the server-side.

[nin-jin]

For your inspiration: https://page.hyoo.ru/#!=uhgyst_zfa8t3