Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why aggressive normalization? #31

Open
stalniy opened this issue Jun 23, 2019 · 3 comments
Open

Why aggressive normalization? #31

stalniy opened this issue Jun 23, 2019 · 3 comments

Comments

@stalniy
Copy link

stalniy commented Jun 23, 2019

After playing with the library I see that you normalize all objects. What is the purpose of normalizing everything and not only objects which has __typename and id ?

@stalniy stalniy changed the title Why hungry normalization? Why aggressive normalization? Jun 23, 2019
@jonaskello
Copy link
Member

This is a good question and partly related to #27. We could normalize only object's that have ID. However then the structure will not be 100% flat since some normalized objects may have fields with deep structure (becuase some of their child objects have no ID). Not having a 100% flat structure brings some problems:

  • When merging, we probably need to do a deep merge instead of just shallow.
  • When denormalizing, we need to determine if we should treat a field as normalized or not (today everyhing is normalized so there is no need to determine it).

So the reason for normalizing everything is that the logic becomes easier, however it brings problems like in #27. I read an issue in the apollo repo about this and it seems they also normalize every object, probably for the same reasons (I can't seem to find that issue right now though).

@stalniy
Copy link
Author

stalniy commented Jun 26, 2019

yes, apollo also normalize the whole graph (but they also save some additional meta information). Now I understand the reasoning behind this decision, thanks!

@stalniy stalniy closed this as completed Jun 26, 2019
@jonaskello
Copy link
Member

It seems like in Apollo Client 3 they are moving towards not normalizing objects without ID:

a) The InMemoryCache no longer generates local IDs
Previous versions of the InMemoryCache would generate identifiers for entities that lack one in order to enable normalization. In Apollo Client 3, theInMemoryCache uses a new, reference-ID-based approach that only normalizes entities that have an ID. Entities without an ID are instead stored within their parent object in the cache. Initial tests with production data sets show a dramatic reduction in cache size, and an increase in overall cache performance.

Might be interesting to look into this more.

@jonaskello jonaskello reopened this Jan 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants