# Apollo caching whole query instead of it's payload response

**URL:** <https://community.apollographql.com/t/apollo-caching-whole-query-instead-of-its-payload-response/7265>\
**Category:** Client SDKs\
**Tags:** client, web\
**Created:** [March 5, 2024, 2:03pm UTC](https://community.apollographql.com/t/apollo-caching-whole-query-instead-of-its-payload-response/7265 "2024-03-05T14:03:28Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![don](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/don/32/4947_2.png) [@don](https://community.apollographql.com/u/don)\
**Post date:** [March 5, 2024, 2:03pm UTC](https://community.apollographql.com/t/apollo-caching-whole-query-instead-of-its-payload-response/7265/1 "2024-03-05T14:03:29Z")

</div>

Hello, I have Apollo Client setup with the REST link for some endpoints and I use the `typePatcher` to manually add `__typename` to nodes and each one as an `id` indentifier. The query result after patch is like:

```auto
{
  data: {
    order: {
      attributes: {
        meals_order: [
          {
             __typename: "MealOrder",
             id: 123,
             ...
          }
        ]
      }
    }
  }
}

```

But the cached result in Apollo Client shows only in `ROOT_QUERY` as `current_order({ input: {}})`. I’d like to show its payload cached like `MealOrder:123`, etc.

I wonder if the problem is related to any of these facts:

1. This REST endpoint is a `POST` instead of a `GET`. Yes, it’s the wrong method and that’s the reason why apollo caches it with empty input arguments in the query `current_order({ input: {}})` instead of just `current_order`.

2. Deeply nested response without `__typename` or `id` in some nodes.

Does anyone have any idea how to resolve it?

---

<div class="post-metadata">

**Author:** ![lenz](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/lenz/32/4007_2.png) [@lenz](https://community.apollographql.com/u/lenz)\
**Post date:** [March 5, 2024, 2:28pm UTC](https://community.apollographql.com/t/apollo-caching-whole-query-instead-of-its-payload-response/7265/2 "2024-03-05T14:28:31Z")

</div>

If your endpoint is GET or POST should not have any influence on how things are stored in the cache. If you provide variables to your query, your cache entry path also seems fine.

Generally, that part of your payload _should_ be cached as a reference to `MealOrder:123`. Is this a basic Apollo Client, or do you have some InMemoryCache configuration that might have changed it’s behaviour?

---

<div class="post-metadata">

**Author:** ![don](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/don/32/4947_2.png) [@don](https://community.apollographql.com/u/don)\
**Post date:** [March 7, 2024, 6:27pm UTC](https://community.apollographql.com/t/apollo-caching-whole-query-instead-of-its-payload-response/7265/3 "2024-03-07T18:27:04Z")

</div>

No changes in `InMemoryCache `.

I wonder if it may due to the deep nesting.  
Apollo docs states ([ref](https://www.apollographql.com/docs/react/api/link/apollo-link-rest/#response-transforming)):

> By default, Apollo expects an object at the root for record requests, and an array of objects at the root for collection requests

And my payload response does not seem to follow the pattern

---

<div class="post-metadata">

**Author:** ![lenz](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/lenz/32/4007_2.png) [@lenz](https://community.apollographql.com/u/lenz)\
**Post date:** [March 8, 2024, 12:48pm UTC](https://community.apollographql.com/t/apollo-caching-whole-query-instead-of-its-payload-response/7265/4 "2024-03-08T12:48:03Z")

</div>

I’m pretty sure that your payload does this pattern - to be honest, I’m not sure if it’s possible to return JSON that doesn’t match this (apart from a plain string or number).

Could you create some reproduction that shows this behaviour you see here? It’s hard to give any advice otherwise.

Generally, everything that has a typename and id should be normalized - no matter how many non-normalizable layers are between.