Next.js: assetPrefix not working on getStaticProps JSON

[pueyo5]

Bug report

Describe the bug

When using getStaticProps with assetPrefix, the JSON file with the page data is not using assetPrefix.

Current: https://domain-name.com/_next/data/${build_id}/es/cars/audi.json
Expected: https://cdn-name.com/_next/data/${build_id}/es/cars/audi.json

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Set assetPrefix on next.config.js
2. Create a page that uses getStaticProps
3. Navigate to that page using Link or Router
4. Open the devTools console
5. See that the requested JSON uses the hostname instead of the assetPrefix

Expected behavior

Use assetPrefix on getStaticProps JSON

System information

• OS: Ubuntu 18.04.4 LTS
• Browser: Chrome 84
• Version of Next.js: 9.5.2
• Vercel production build

Additional info

Similar closed/fixed issues: #11992 & #15287

The answer given for the issue #11992 is not working in our case because we want to use a subdomain and this is not supported on basePath:

Please use the new basePath support instead of assetPrefix in Next.js 9.5.1+ for this use case!

_Originally posted by @Timer in https://github.com/vercel/next.js/issues/11992#issuecomment-666148936_

[GxDesign]

Our team is experiencing this exact issue as well with Vercel production builds, all browsers, NextJS 9.5.3-canary.10

[callumbooth]

I think it's related to #12046, seems like the same issue I see here

[tatyanaKozlovskaya]

Same issue

[callumbooth]

any idea if this issue will get resolved in the next update?

[theBork]

Hope that this will be fixed soon

[shkmc]

Same issue

[callumbooth]

According to the docs https://nextjs.org/docs/api-reference/next.config.js/cdn-support-with-asset-prefix.

Asset prefix support does not influence the following paths:

• Files in the public folder; if you want to serve those assets over a CDN, you'll have to introduce the prefix yourself
• /_next/data/ requests for getServerSideProps pages. These requests will always be made against the main domain since they're not static.
• /_next/data/ requests for getStaticProps pages. These requests will always be made against the main domain to support Incremental Static Generation, even if you're not using it (for consistency).

So it looks like this behaviour is intended. We ended up having to put extra ingress routes for our reverse proxy to handle the /_next/data requests coming in which worked.

[jayeheffernan]

Hi everyone!

I understand that this is intended behaviour but it's a big issue with deploying a site I'm working on. I'd love to see it addressed, probably in the form of a new config variable (to not make any breaking changes). I'm looking for a solution for the situation where a user has already loaded a page, and we make a deploy while they're in the middle of using it. Our deploy system is "atomic", so any files that changed names for the deploy will now be missing on the main domain (from the perspective of the stale page in the user's browser). I thought I had a good solution to this, but it's blocked by this issue.

I'll describe my situation on Netlify, but it seems this is also an issue on the Vercel platform.

The problem

Users load our page through the main domain, but each Netlify deploy also gets its own unique deploy URL. This means that the deployed assets, bundles etc. from any previous deploy remain accessible. So my idea is that I should be able to use the unique URL to allow a user to continue browsing the site with whatever version of the page they have loaded: all further requests from the Next.js app client-side for assets, new bundles, etc. should be served from the deploy URL that they loaded. If they reload the page, the latest deploy URL will be included in the new response, and they will browse that version from then on.

What I've tried

To get this working I have tried setting Next.js's assetPrefix and webpack's output.publicPath to the unique deploy URL. This _almost_ works great. Whatever deploy is the one to serve the initial page load to the user, the images and bundles are loaded from that unique deploy URL. This way the user can continue to browse around the site and their pages and assets will continue to load. Great!

Why it doesn't work

What ruins this whole plan is (from the docs):

Asset prefix support does not influence the following paths: [...] /_next/data/ requests for getStaticProps pages. These requests will always be made against the main domain to support Incremental Static Generation, even if you're not using it (for consistency).

From my understanding this means that the props returned from getStaticProps() will always be served from the main domain, even if my page bundles have been loaded from an older deploy. Those props can be very important (e.g. we set a lot of data from the CMS through those props), and it will often be the case that an updated page component is not compatible with the getStaticProps() result of a previous deploy. So our page components will be out of sync with the data passed to render them, if we are not able to to apply assetPrefix (or some equivalent) to these paths.

What else I've considered

I've noticed on other issues (e.g. #11992) that basePath is a newer config parameter that is suitable for some use-cases people were trying to use assetPrefix, but it does not appear to be a good fit for this. It can't be set to an absolute URL, and if it could then <Link />s would presumably start linking off to some other domain.

The other solution I've seen is to use a service worker to force the user to refresh, or to prompt them that there is a new version of the site. Apart from the added complexity to figure out how to properly configure the service worker, this is also not good UX. A site cannot always force a reload of the user's page, because they might be in the middle of reading, interacting, filling in a form, or making a purchase. To prompt the user to refresh because there is a new version of the page available might be ok for more of an "app"-style site, but for something like an ecommerce site it would be a very strange and off-putting experience for the user to have to interact with that. If the site is being actively developed there may be multiple deploys per day, which means annoying and confusing the user multiple times per day with this method.

My issue could also be mostly fixed on a platform level, by keeping files from old deploys available through the CDN on the main domain. This wouldn't be possible if the files don't change name, but maybe with content-hashes it could work. I don't think Next.js should rely on platform support for this though, and it's currently not implemented for either Netlify or Vercel.

Please help

Please reconsider allowing assetPrefix (or some other variation) to configure what domain /_next/data/ requests are served on 🙏 It will be a great help for many developers who want to actually run Next.js in production and serve their site to a lot of users.