5 ms·
Great questions Andy! We do support wrapping payload types of any kind because we invalidate _all_ objects returned from a mutation. For example, if you run a
by mxstbr 5y ago
Great questions Andy!
We do support wrapping payload types of any kind because we invalidate _all_ objects returned from a mutation. For example, if you run a mutation like editUser { user { id posts { id } } } we will invalidate any cached query result that contains that user and any cached query result that contains any of those posts!
You are right that smart invalidation can never be 100% reliable, which is why we have the Purging API to manually purge records you know changed from your backend. I think most customers are going to use the manual Purging API, however we also have a bunch of customers with use cases for whom the smart invalidation suffices.
- jorams 5y agoI guess that means a mutation like `editUser { user { name } }` would not trigger smart invalidation, since there is no ID to work with?
- mxstbr 5y agoThat's correct, however we also allow defining custom "Key fields", which is how you can tell us which fields are unique and should be invalidated by (e.g. "User.email").
- nivertech 5y agoWould UUIDs or Relay-style global IDs help to avoid manual purging here?
- mxstbr 5y agoAny kind of unique ID works, whether UUIDs, global IDs, incremented IDs, etc.