[v4] GraphQL cache issue because of API schema format

[M1CK431]

Bug report

Describe the bug

Because of id and attributes split in API schema the GraphQL cache can't be updated and raise a warning in the browser console (among obvious cache handling issue).

The warning message from the console is:

invariant.ts?6cf4:42 Cache data may be lost when replacing the attributes field of a ExampleEntity object.

To address this problem (which is not a bug in Apollo Client), either ensure all objects of type Example have an ID or a custom merge function, or define a custom merge function for the ExampleEntity.attributes field, so InMemoryCache can safely merge these objects:

  existing: {"__typename":"Example","createdAt":"2021-12-25T23:43:56.648Z","firstName":"John","lastName":"Do","message":"I'm asleep","status":"NEW","dueDate":null,"referer":"https://example.com","contactDetails":[],"user":{"__typename":"UsersPermissionsUserEntityResponse","data":null}}
  incoming: {"__typename":"Example","dueDate":null,"firstName":"John","lastName":"Do","message":"I'm asleep","referer":"https://example.com","ipAddress":"12.34.56.78","createdAt":"2021-12-25T23:43:56.648Z","updatedAt":"2021-12-25T23:43:56.648Z","contactDetails":[],"communications":[]}

For more information about these options, please refer to the documentation:

  * Ensuring entity objects have IDs: https://go.apollo.dev/c/generating-unique-identifiers
  * Defining custom merge functions: https://go.apollo.dev/c/merging-non-normalized-objects

This is because the GraphQL schema is the following:

• example query:

example(id: ID): ExampleEntityResponse
type ExampleEntityResponse {
  data: ExampleEntity
}
id: ID

and

data: ExampleEntity
type ExampleEntity {
  id: ID
  attributes: Example
}

Steps to reproduce the behavior

1. Using GraphQL API, request the same asset in a query and in the result of a mutation (for example)
2. See warning message in the browser console

Expected behavior

The id and attributes split in the GraphQL API schema is incomprehensible for me. I can't understand why there are not in the same object (like Apollo Client is obviously expecting to find it). In addition, I also can't understand why we need to wrap everything in a data object while fetching a single asset. I guess there is strong reasons for such things, but I can't actually believe them 🤯

IMHO, the expected schema should be like this:

example(id: ID!): Example
type Example {
  id: ID!
  createdAt: DateTime!
  updatedAt: DateTime!
  // other fields...
}

Screenshots

N/A

Code snippets

Regardless the GraphQL cache issue, I'm currently forced to write such code in every query/mutation (and I really hate it 😠):

function Example({ id, attributes }) {
  Object.assign(this, { id, ...attributes });
}

this.$apollo
  .query({ query: examplesQuery, variables: { ids: this.ids } })
  .then(({ data: { examples: { data } } }) => {
    const examples = data.map(e => new Example(e));
    // finally some useful code
  }

Strapi v3 use by far more "dev friendly" in this respect (no useless data wrapper for single asset, no incomprehensible id and attributes split).

System

• Node.js version: v16.13.1
• NPM version: v8.1.2
• Strapi version: v4.0.5
• Database: MariaDB
• Operating system: Archlinux

[M1CK431]

Up! 🙃

[derrickmehaffy]

Can you please share this information here: https://forum.strapi.io/t/discussion-regarding-the-complex-response-structure-for-rest-graphql-developer-experience/13400

I'm going to close this as it's not "technically" a bug, I know the new structure is a bit frustrating and some caching issues (especially client-side) do exist with the new structure especially with apollo-client but we are trying to centralize feedback.

Thank you

[M1CK431]

Hi @derrickmehaffy ,

Thanks for your reply and pointed me out the related forum discussion. I will copy my bug report as requested.

However, this issue is mainly about caching issue and as you stand yourself there is a knowned caching issue, regardless technical choices which leads to that issue. In addition, a lot of dev/users don't use strapi forum but check for existing (open) issues and report issue on github. That's why I think that issue should stay open until a fix is provided.

[strapi-bot]

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/discussion-regarding-the-complex-response-structure-for-rest-graphql-developer-experience/13400/19

[derrickmehaffy]

Hi @derrickmehaffy ,

Thanks for your reply and pointed me out the related forum discussion. I will copy my bug report as requested.

However, this issue is mainly about caching issue and as you stand yourself there is a knowned caching issue, regardless technical choices which leads to that issue. In addition, a lot of dev/users don't use strapi forum but check for existing (open) issues and report issue on github. That's why I think that issue should stay open until a fix is provided.

While normally I would agree with you, this isn't something that is "easily fixed" and it's a problem that mainly happens upstream on the client side. Given I will say the issue is caused by our structure it just relates to that discussion so for now I'll leave it as closed with the hope that our engineering team can raise the discussion to an actual bug report.

[M1CK431]

Hi @derrickmehaffy ,
Thanks for your reply and pointed me out the related forum discussion. I will copy my bug report as requested.
However, this issue is mainly about caching issue and as you stand yourself there is a knowned caching issue, regardless technical choices which leads to that issue. In addition, a lot of dev/users don't use strapi forum but check for existing (open) issues and report issue on github. That's why I think that issue should stay open until a fix is provided.

While normally I would agree with you, this isn't something that is "easily fixed" and it's a problem that mainly happens upstream on the client side. Given I will say the issue is caused by our structure it just relates to that discussion so for now I'll leave it as closed with the hope that our engineering team can raise the discussion to an actual bug report.

Sorry, I don't understand the arg "this isn't something that is "easily fixed"". Ok it's not easy to fix... and then? It's still an issue!
And about "it's a problem that mainly happens upstream on the client side", well, not a surprise honestly, since strapi is an API, the biggest issues happens when a client can't use it as expected, right? 🤭

But after all, your repo, your rules 🤷‍♂️
I hope you will not have too many new other issues about that to close in the futur 🤞

Again, thanks to provide the discussion in the forum. Now I know that this issue will not be fixed soon and I can take decisions accordingly 😘

[JWesorick]

Does anyone have an example of how they fixed the Apollo Cache issue?

[petersino]

Contributor

Hi, did you find any solution?

[jbcrestot]

in case anyone land on this page, you can merge attributes by indicating it in apollo cache like this :

  typePolicies: {
    ExampleEntity: {
      fields: {
        attributes: {
          merge: true,
        }
      }
    }
  }
});

[M1CK431]

in case anyone land on this page, you can merge attributes by indicating it in apollo cache like this :

  typePolicies: {
    ExampleEntity: {
      fields: {
        attributes: {
          merge: true,
        }
      }
    }
  }
});

I'm even doing this massively for years:

new ApolloClient({
  link: "<insert your link here>",
  cache: new InMemoryCache({
    typePolicies: [
      "UsersPermissionsUser",
      "Asset1",
      "Asset2",
      "AssetX",
    ].reduce((acc, type) => ({ ...acc, [type]: { merge: true } }), {})
  })
});

This is just a workaround. The real issue come from Strapi with it's abnormal schema.

IIRC it was even one of the reasons why Strapi team keep alive v3 until now.
However v3 is reaching EOL very soon and the problematic GQL schema is still there... 😢

[jbcrestot]

Oh, I agree entirely with you ; attributes object without id is annoying

[ansmlc]

in case anyone land on this page, you can merge attributes by indicating it in apollo cache like this :

  typePolicies: {
    ExampleEntity: {
      fields: {
        attributes: {
          merge: true,
        }
      }
    }
  }
});

I'm even doing this massively for years:

new ApolloClient({
  link: "<insert your link here>",
  cache: new InMemoryCache({
    typePolicies: [
      "UsersPermissionsUser",
      "Asset1",
      "Asset2",
      "AssetX",
    ].reduce((acc, type) => ({ ...acc, [type]: { merge: true } }), {})
  })
});

This is just a workaround. The real issue come from Strapi with it's abnormal schema.

IIRC it was even one of the reasons why Strapi team keep alive v3 until now. However v3 is reaching EOL very soon and the problematic GQL schema is still there... 😢

@M1CK431 Does this fix the caching issue? Is there any downside?

In my case I have types such as ArticleEntity, CategoryEntity, LocationEntity, etc. Should I include all of these?

new ApolloClient({
  link: "<insert your link here>",
  cache: new InMemoryCache({
    typePolicies: [
      "ArticleEntity",
      "CategoryEntity",
      "LocationEntity",
    ].reduce((acc, type) => ({ ...acc, [type]: { merge: true } }), {})
  })
});

[M1CK431]

in case anyone land on this page, you can merge attributes by indicating it in apollo cache like this :

  typePolicies: {
    ExampleEntity: {
      fields: {
        attributes: {
          merge: true,
        }
      }
    }
  }
});

I'm even doing this massively for years:

new ApolloClient({
  link: "<insert your link here>",
  cache: new InMemoryCache({
    typePolicies: [
      "UsersPermissionsUser",
      "Asset1",
      "Asset2",
      "AssetX",
    ].reduce((acc, type) => ({ ...acc, [type]: { merge: true } }), {})
  })
});

This is just a workaround. The real issue come from Strapi with it's abnormal schema.
IIRC it was even one of the reasons why Strapi team keep alive v3 until now. However v3 is reaching EOL very soon and the problematic GQL schema is still there... 😢

@M1CK431 Does this fix the caching issue? Is there any downside?

In my case I have types such as ArticleEntity, CategoryEntity, LocationEntity, etc. Should I include all of these?

new ApolloClient({
  link: "<insert your link here>",
  cache: new InMemoryCache({
    typePolicies: [
      "ArticleEntity",
      "CategoryEntity",
      "LocationEntity",
    ].reduce((acc, type) => ({ ...acc, [type]: { merge: true } }), {})
  })
});

Yes, it workaround the cache issue, no downside.
The only project where I'm still using Strapi (for historical reasons) is working with that for years until now.

TBH, I have even written a special Vue.js "plugin" called strapollo (closed source) which wrap the regular Apollo client and merge id and attributes in the response globally. However, I still have to use the horrible GQL schema in queries and mutations because AFAIK there is no simple way to workaround that.

However, my advise is to not use Strapi if you plan to use the GraphQL API. Creating your own API with NodeJs/Koa is a far better alternative, especially if your main need is a regular CRUD around some assets, and you can even add subscriptions support.

As an example, I urge you to take a look on my recent open source project where I'm doing exactly that. Especially, this file could be very helpful for you because it's a kind of "generator": you call it with an object describing your model and almost everything is generated for you (GQL type, DB model, filters/sort, etc...). See usage example here.

In addition, you may be also interested by Nexus/Prisma.

Hope it helps 🤞🏼

EDIT: Directus looks like a great alternative too (not tested myself... for now 😉)