Data fetching on SSR using useFetch/useAsyncData does not work on page refresh/reload

I've searched extensively but haven't found the correct solution. Here are some points I've considered: * The site certificate is NOT self-signed, so adding NODE_TLS_REJECT_UNAUTHORIZED=0 is unnecessary. * Setting server=false or any implementation that moves the request to the client-side is not preferred, as my goal is to use SSR for data fetching. My SSR application is hosted in AWS, following a structure similar to the one described here (see attached image) but with CloudFront in front of ALB. I suspect that I might be missing a specific CloudFront or other header in the request, which is automatically added on the client-side. When running my site locally using yarn dev or yarn build, SSR data fetching works without issues. There are also no logs found for all the SSR requests in our API log. Has anyone encountered this same issue and is willing to share their solution?
Amazon Web Services, Inc.
Web アプリケーションにおける Amazon ECS / AWS Fargate ...
Amazon ECS / AWS Fargate を中⼼とした代表的なアーキテクチャパターンを、最新の AWS サービスアップデートを踏まえつつ紹介します。
No description
3 Replies
kapa.ai
kapa.ai2w ago
Hi @bvttercvp. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Based on the knowledge sources provided, I can identify several potential issues with your SSR data fetching not working on page refresh/reload in a production environment while working fine locally. Possible Causes and Solutions 1. Caching Issues with useFetch One common issue is that useFetch caches responses, and on page refresh, it might be using cached data instead of making a new request:
// Try adding a unique key to prevent caching
const { data } = await useFetch('/your-api-endpoint', {
key: 'unique-key-' + Date.now(), // Forces a new request on each refresh
})
// Try adding a unique key to prevent caching
const { data } = await useFetch('/your-api-endpoint', {
key: 'unique-key-' + Date.now(), // Forces a new request on each refresh
})
This solution was mentioned as helpful for similar issues where old data was being shown on page refresh Link to StackOverflow answer. 2. Cookie/Header Forwarding Issues When making server-side requests, cookies and headers aren't automatically forwarded like they are in client-side requests:
// Use useRequestFetch to forward headers and cookies during SSR
const requestFetch = useRequestFetch()
const { data } = await useAsyncData(() => requestFetch('/your-api-endpoint'))
// Use useRequestFetch to forward headers and cookies during SSR
const requestFetch = useRequestFetch()
const { data } = await useAsyncData(() => requestFetch('/your-api-endpoint'))
The useFetch composable actually uses useRequestFetch under the hood to automatically forward request context and headers Link to Nuxt docs. 3. Reactive References Not Updating If you're using reactive references with useFetch, there might be issues with the values not updating properly:
// Instead of this:
const myRef = ref('value')
const { data } = await useFetch(`/api/endpoint?param=${myRef.value}`)

// Try this:
const myRef = ref('value')
const { data } = await useFetch('/api/endpoint', {
query: { param: myRef },
watch: [myRef] // Ensures refetching when myRef changes
})
// Instead of this:
const myRef = ref('value')
const { data } = await useFetch(`/api/endpoint?param=${myRef.value}`)

// Try this:
const myRef = ref('value')
const { data } = await useFetch('/api/endpoint', {
query: { param: myRef },
watch: [myRef] // Ensures refetching when myRef changes
})
This addresses issues where useFetch doesn't use new values from reactive objects Link to GitHub issue. 4. Hydration Issues There might be hydration mismatches between server and client. This can happen when the key generated for the payload is different between server and client:
// Explicitly define a key to ensure consistency between server and client
const { data } = await useFetch('/your-api-endpoint', {
key: 'define-custom-key',
})
// Explicitly define a key to ensure consistency between server and client
const { data } = await useFetch('/your-api-endpoint', {
key: 'define-custom-key',
})
This solution was mentioned for cases where pages were experiencing infinite loops or hydration failures Link to GitHub issue comment. 5. Environment-Specific URLs Since your application works locally but not in production, you might need to handle different base URLs:
// Create a custom fetch function that handles different environments
export async function customFetch(endpoint) {
const runtimeConfig = useRuntimeConfig()
const baseUrl = process.server ?
"<https://your-production-api"> :
runtimeConfig.public.apiBaseUrl

return await useFetch(baseUrl + endpoint)
}
// Create a custom fetch function that handles different environments
export async function customFetch(endpoint) {
const runtimeConfig = useRuntimeConfig()
const baseUrl = process.server ?
"<https://your-production-api"> :
runtimeConfig.public.apiBaseUrl

return await useFetch(baseUrl + endpoint)
}
This approach was helpful for users experiencing issues with Docker containers and different environments Link to StackOverflow answer. Conclusion Given that your application is hosted on CloudFront, I suspect the issue might be related to either header forwarding or environment-specific configurations. Try implementing the solutions above, particularly focusing on explicitly setting keys for useFetch calls and ensuring proper header forwarding. If these solutions don't resolve your issue, you might need to investigate CloudFront-specific configurations, such as cache behaviors or origin request policies, which might be affecting how your SSR requests are handled. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
kapa.ai
kapa.ai2w ago
<@1080330519776084090> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
bvttercvp
bvttercvpOP2w ago
I am already using requestFetch and some of the other suggestions are not applicable to mine as it's simply not calling the API in SSR since no logs can be found.

Did you find this page helpful?