Preemptive Deduplication of Response Data

[shmax]

Hi there, wonderful library, I'm really enjoying it. Straight to the question: I intend to use Apollo Client, and I've read that if you start with a request like this...

author(name: 'wilson rawls') {
    firstBook {
      __typename,
       id,
       title,
       year
    },
  },
  book(id:1) {
   __typename,
    id,
    title,
    year,
  }

...that produces a result like this...

{
  "data": {
    "author": {
      "firstBook": {
        "__typename": "Book",
       "id": 1,
       "title": "Where the Red Fern Grows", // notice that the first instance of this book has all the data
       "year": 1961
      }
    }
  },
  "book": {
     "__typename": 'Book', // even though I requested everything, this book object just has an id and a __typeName; the data for it is up in the first instance above corresponding to this book id
    id: 1
  }
}

...then Apollo Client is smart enough to interpret __typename and id and glue everything back together and ultimately puts this in the store:

{
  "data": {
    "author": {
      "firstBook": {
        "__typename": "Book",
       "id": 1,
       "title": "Where the Red Fern Grows",
      "year": 1961
      }
    }
  },
  "book": {
     "__typename": "Book",
    "id": 1,
   "title": "Where the Red Fern Grows",
   "year": 1961
  }
}

I'm going to be working with very complex nested data sets, and would really like to have this kind of optimization if possible. Is there some kind of feature or pattern out of the box that supports this? I've found a few projects on github that try to "deduplicate" a GraphQL data set after the fact, but I figure it's better to not duplicate the data in the first place.

I've gotten pretty far with Deferred and a custom ObjectType subclass, but the best I can seem to do is to return null for fields that have already been handled, when what I want to do is not write a field to the result set at all if it's already been written earlier in the data set.

Any advice? Thanks much!

[vladar]

I see what you mean, but GraphQL was designed without normalization in the first place. They do plan to introduce normalization in the reference implementation (see this thread), but nothing was done so far.

This subject is much more complex than what you are trying to do. Consider the following query:

author(name: 'wilson rawls') {
    firstBook {
      __typename,
       id
       title
    },
  },
  book(id:1) {
   __typename,
    id
    year
  }

(and there are many variations of it, including fragments, interfaces and unions, etc)

You can't just reference a first entry, you must also ensure it has all the same fields as the second one, taking in account aliases. The truth is that if you need normalized data in the first place, GraphQL may be not the right tool.

Consider falcor although I am not sure if there are PHP implementations of it.

[shmax]

Consider the following query:

As a matter of fact, that's exactly what I typed in the first draft of my issue; I decided to simplify for the initial conversation. I guess I needn't have bothered. 😄

The truth is that if you need normalized data in the first place, GraphQL may be not the right tool.

The irony here is that I have it already in my own custom-built solution. Like everybody else, I just sort of got swept up in all the GraphQL madness. It seems so strange that such a powerful technology would completely gloss over something like this!

I've managed to get a crude version of this functionality working (with a few small tweaks) in a fork of this library. I think what I'll do is forge ahead and circle back to revisit this once I've seen what Apollo Client can do with it.

Thanks very much for the reply. Closing for now.

[vladar]

Actually, normalization is not the only approach on the client-side. If your source of truth is on the server, you can have a client which avoids normalization step. I am pretty sure that GraphQL was initially designed for such workflow.

But then client developers decided to go a bit further than that and introduced the normalization stage. That's why I am not entirely happy with Apollo or Relay - they add significant overhead on the client side by using normalization and don't use strong parts of GraphQL, instead focusing on its weak parts (lack of normalization).

It is beyond my understanding why there is still no good client which would utilize the power of GraphQL to avoid complexity on the client instead of adding it.

[shmax]

Well sure, no one says you have to use normalization on the front end, but from where I sit it's a good practice for the back end regardless of which client you use. You not only wind up with a smaller data payload, but it encourages habits that can save processing time on the back end (because you don't process the same field for a particular record more than once) and you wind up with a smaller JSON value to parse in the front end. This all assumes that the overall savings is not lost due to the extra work required to piece things back together again in the front end. We shall see! Thanks much for the comment.