We have a React app using react-router with client-side routing. However for it to work with the BrowserRouter, we need the webserver to support responding to 404 errors with the index.html so it can load the app.
We’re using Fly Statics with Tigris to serve up the static assets. The actual container running in the fly app doesn’t really know anything about the front-end. We have a separate process that builds the assets and uploads them to the Tigris bucket, then the [[statics]] configuration for the app points all /app* requests to the static bucket with a configured index_document. However, if we have subroutes (like /app/posts/{postId}), when you refresh the page it breaks because the [[statics]] configuration doesn’t respond with the index.html on 404 requests.
My question is, is there a configuration to support this in the fly.toml or in Tigris somehow?
In AWS, one way to configure this setup would be to put a Cloudfront configuration in front of the S3 bucket, which has a configuration for serving up a specified file as the 404 page.
Is this maybe something that I should ask in Tigris support? I wasn’t sure which part of the stack would/should be responsible for responding with a default file.
If I’m not mistaken, there isn’t currently a native way in fly.toml or Tigris configuration to rewrite all 404s to index.html for SPA support with client-side routing. As far as I’m aware, the [[statics]] config handles index_document for root requests but doesn’t support 404 fallback rewrites for nested routes.
To get around this for React Router’s BrowserRouter, the common pattern is usually to deploy a simple web server inside a Fly machine that serves your static assets and rewrites all unknown routes to index.html. Have you tried this yet?
You could also try using React’s HashRouter or putting a CDN like Cloudflare in front of your Tigris bucket, which can rewrite 404s to index.html. Might be an option, similar to your AWS CloudFront setup. If you want to keep using Fly Statics + Tigris directly, you might have to use one of these workarounds since SPA fallback routing on 404s isn’t currently supported natively.
We haven’t tried that, but that’s mostly because the back-end app isn’t a simple web server. We were hoping to leverage this awesome fly/statics statics config to be able to make this workflow work. We’ll look at other solutions. Thanks!