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

Caching Problem (related to JS-SDK) #402

Open
Patrick3131 opened this issue Nov 13, 2024 · 2 comments
Open

Caching Problem (related to JS-SDK) #402

Patrick3131 opened this issue Nov 13, 2024 · 2 comments

Comments

@Patrick3131
Copy link

I am experiencing caching problems in various places, basically anywhere the JS-SDk is used.

But to reproduce here is a specific example.

  1. Use the frontend and perform requests related to product categories.
  2. Add a new category in the backend.
  3. Refresh the frontend
  4. The new category does not appear in the front end.

The SDK is performing a request:

Performing request to:
URL: http://localhost:9000/store/product-categories?limit=6&offset=0
Headers: {
"accept": "application/json",
"content-type": "application/json",
"next": "[object Object]",
"x-publishable-api-key": "pk_a2a7ef77ac474db492f87f3c9103ebc6a8ddf917ba0bb004d6219930dd71bd9f",
"authorization": ""
}
However, it is only returning the previously cached request without the newly added category.

Adding no caching to the Medusa SDK init fixes the issue:

export const sdk = new Medusa({
  baseUrl: MEDUSA_BACKEND_URL,
  debug: process.env.NODE_ENV === "development",
  publishableKey: process.env.NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY,
  globalHeaders: {
    "Cache-Control": "no-store",  // Prevents caching
    Pragma: "no-cache",            // For HTTP/1.0 compatibility
  },
})

But also then removes the caching completely 😛

@Patrick3131 Patrick3131 changed the title Caching Problem (maybe related to JS-SDK) Caching Problem (related to JS-SDK) Nov 13, 2024
@sradevski
Copy link
Member

Thanks for opening a ticket with reproduction steps.

This is more of a NextJS caching behavior, not an issue with the SDK itself. That being said, we need to make the entire caching story better, probably by first upgrading to NextJs 15, as they've done some changes to how caching works out of the box.

We'll keep this ticket updated once we get this looked into. Also feel free to open a PR if you want to help with a fix

@Patrick3131
Copy link
Author

Well we are using the SDK within Nextjs so we have to find a solution that makes it feasible to use it within Nextjs.

Medusa has this article on their website, talking about benefits and also pointing out challenges (reading the article makes you think these challenges are solved):

If a product sells out, it should be immediately clear to all customers. And with multi-currency and personalized prices, the customer should see the price they will be charged in real time. Ecommerce websites, therefore, have to interact with a server that can deliver this information.

At first, re-fetching the same data multiple times in a component tree seemed counterintuitive as you’d normally fetch data in one place, and pass it down via either Context or props. You must also remember to revalidate the relevant parts of the cache every time you mutate data on the server. These patterns take some getting used to.

But basically this starter doesn't live up to its promises because currently we have to disable the caching (simultaneously also removing benefits of Nextjs SSR) to use it.
This #54 probably also stems from a caching problem.

What would be a caching strategy moving forward?

I understand the caching is caused by Nextjs extension of the fetch API and that is not the case when the Medusa SDK is used in another context. However, I think this should still be something that the SDK handles automatically, because this logic will be necessary in any implementation with Nextjs. Do you think we should move this issue to a different repository? If Nextjs is a common storefront technology, maybe a more specific SDK targeting Nextjs specific challenges could make more sense?

One idea would be to subscribe/listen to changes from the medusa backend and purge the cache when necessary. Maybe a temporary solution could be to purge the complete cache with any change that is coming from the backend and in the future a more targeted approach?

If I understand it correctly, I also found other inefficient ways how the cache is used:

export async function updateCart(data: HttpTypes.StoreUpdateCart) {
  const cartId = getCartId()
  if (!cartId) {
    throw new Error("No existing cart found, please create one before updating")
  }

  return sdk.store.cart
    .update(cartId, data, {}, getAuthHeaders())
    .then(({ cart }) => {
      revalidateTag("cart")
      return cart
    })
    .catch(medusaError)
}

or

export const updateCustomer = cache(async function (
  body: HttpTypes.StoreUpdateCustomer
) {
  const updateRes = await sdk.store.customer
    .update(body, {}, getAuthHeaders())
    .then(({ customer }) => customer)
    .catch(medusaError)

  revalidateTag("customer")
  return updateRes
})

This purges the cache for any user, would it not make more sense to have a more user specific cache and only purge the cache necessary?

Temporarily, what would make sense to target? Disabling the caching completely till there is a more sophisticated cache handling solution?

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