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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate parsing and normalization #2841

Merged
merged 13 commits into from Jan 7, 2021

Conversation

martinbonnin
Copy link
Contributor

Remove normalization from the parsing step. Normalization is now done from the models, like it is done when using the cache write APIs.

Advantages:

  • Normalizing network response now uses the same path as when writing to the cache using the imperative cache write API. This ensures the results will be identical (see ApolloStore#writeAndPublish overwrites cache entries when using fragments聽#2818)
  • Normalization can be better decoupled from the parsing and not applied at all if no cache is configured. This also means we can make normalization "async" and send a model to the UI without having to wait

This also enables the streaming parser in ApolloParseInterceptor, which is the main use case, which is something like ~25% faster on the whole parsing + normalization path, potentially event faster without normalization 馃帀 (see the README.md in the benchmarks for actual numbers)

val data = operation.adapter().fromResponse(responseReader, null)
val records = operation.normalize(data, customScalarAdapters, networkResponseNormalizer() as ResponseNormalizer<Map<String, Any>?>)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we always use neworkResponseNormalizer here, we can remove the parameter and do other cleanups. I didn't do them yet in order to not clash with #2839

builder<D>(operation)
.data(data)
.fromCache(true)
.dependentKeys(responseNormalizer.dependentKeys())
.dependentKeys(records.dependentKeys()) // Do we need the dependentKeys here?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a specific reason why we would need the dependent keys when reading from the cache?

@martinbonnin martinbonnin merged commit 725ec72 into dev-3.x Jan 7, 2021
@martinbonnin martinbonnin deleted the separate-parsing-and-normalization branch January 7, 2021 11:51
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

Successfully merging this pull request may close these issues.

None yet

1 participant