Quote:
Originally Posted by RustyBrooks
It's typical in a dev setup to have the app regenerated whenever the source changes, because that matches how people work. When you deploy you generally pre-package all your stuff into a set of .js files that are loaded by your site's index url. I really doubt apps that are served by express are generating the app on the fly.
With react if you want to use actual urls for routing instead of hashes - when you deeplink you have to redirect those urls (IE - /registration) to the home page. So the server has to be in sync with that as well.
We found that out the hard way - trying to host our react app on S3/cloudfront. Normal navigation works fine, but deep-linking fails. The crappy workaround is to redirect 403s to the home page. Why cloudfront/S3 throws a 403 and not a 404 when say /registration can't find a file called 'registration' I have no idea.
But then you run into issues on stuff like our WAF for internal sites - the 403 gets redirected to home, which the WAF happily returns(!) to the outside world. Annoying - it doesn't load any of the supporting JS, CSS or img files. But you can still see the code for the home page for our dev site - which in theory might have some sensitive stuff that a dev doesn't realize they're exposing to the internet.
Fortunately our business doesn't care if we use hash routing - which I think is butt-ugly but it works around this problem. They may change their minds at some point though. "Um, can we get the URLs to look like this?" (shows normal URL with no hash) At which point I will give my boss the "I told you so" look. The fallback is either the hacky 403 redirect, or host the site on a real webserver on EC2.