Deploying built assets to CDN/S3
I run a pretty big site and we're slowly implementing TanStack Start on it.
We have around 8 web boxes in a load balancer, and the way we typically handle deploys is we build the the app on every one of those boxes, and have a copy of client-side assets/modules on S3.
This allows us to properly leverage Cloudflare caching and whatnot for the user, while still allowing all server-side JS to run on the box properly.
I've kinda got it working by specifying the
base option in vite.config.js, and then kind of "undoing" that in nitro.config.ts by setting runtimeConfig.app.baseURL to / so that it still uses / for server stuff, but the S3 URL for vite public asset paths.
That more or less works, but it feels pretty "hacky"? I guess. In addition, the <link preload= scripts added to the html have misformated URLs: http:/<cdn>/<asset> (notice one slash after http: and not two), this is due to the use of path.join(APP_BASE.. vs. joinURL in the start-plugin-core and that causes 404s for the user.
Can go more in detail if anyone from the TS team is willing to lend some input, but basically just trying to understand if there's a more stable kind of first party way of doing this.13 Replies
noble-goldOPā¢6mo ago
Giving this a quick bump as a last try -- completely understand it's a new framework so not many scenarios like the above, but just in case!
unwilling-turquoiseā¢6mo ago
so what would be needed here? a separate config for asset paths?
noble-goldOPā¢6mo ago
Yep! Just to clarify so we're on the same page: I'm also talking about client JS build files.
What I am doing is running
npm run build, taking all the public files (js/assets/etc...) and hosting those on s3, and then running npm run build on all my web boxes again, and keeping the server files stored on each individual box.
This is our ideal scenario because we then are not forced to drop our whole site's cache after a change/deploy, and users on cached pages are still able to look at "older" build files (since the cached server files will request older files) because we don't delete those from s3.
tldr, ideally there would be two separate configs, one for client, and one for server. Let me know if that makes sense, and whether you need me to open up a gh issue with some more explanation/examples and whatnotunwilling-turquoiseā¢6mo ago
we could also look into whether an API like vite's
renderBuiltUrl https://vite.dev/guide/build.html#advanced-base-options makes senseunwilling-turquoiseā¢6mo ago
so yes, definitely add a gh issue for this with a complete example and then we can discuss in detail
extended-salmonā¢6mo ago
This sounds like something we would definitely want to make easier
noble-goldOPā¢6mo ago
Yep! Planning to take a deeper look myself in the coming days/week and if I'm able to find a nice solution then will submit a PR for it. Will revert back!
deep-jadeā¢4mo ago
This is very important. No serious use case will want nitro serving assets.
Other solutions typically have an asset prefix as the simplest option. Next.js does and so does Vike: https://vike.dev/base-url#baseassets
Base URL | Vike
The Modular Framework ā Next.js & Nuxt alternative for unprecedented flexibility and stability.
deep-jadeā¢4mo ago
@happy your solution with the nitro config seems to work well for me. Thanks.
Considering Tanstack Start is thinking about being more agnostic about how it's served, it should probably handle this itself though.
unwilling-turquoiseā¢4mo ago
we absolutely should
xenial-blackā¢3mo ago
Sorry to bring back this dead thread but I can't find the PR referenced here or any references in the doc - I'm having the exact same issue
unwilling-turquoiseā¢3mo ago
this has not been approached yet. but definitely something we will do asap
xenial-blackā¢3mo ago
Sorry I was referring to the solution @Cruel mentioned related to nitro config.
Oh wait, it's in the original post
š¤¦āāļø