In my previous post, I explained how straightforward it is to host a static website on S3 with HTTPS support and a custom domain. Naturally, this s...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for the great post! I'd like to confirm if what I understood is correct or not. I'd really appreciate if you reply it.
I can deploy websites using S3 with static website hosting, but when it comes to SPA, all routes(actually, it depends on the app) are supposed to be handled with index.html(the app). If a user first enter the index, the other routes work because the user doesn't actually navigate. But if a user first enter the other routes, it will display an error page because files that correspond on the routes don't exist in the storage. There is a way to change the content when S3 get requested for a file that doesn't exist, but it still responses 404 status code, basically, it is correct to send the code since the file doesn't exist in the storage. Some browsers display their own error pages when they get the 404 status code.
There are two ways to solve this problem.
CloudFront - It can override the response status code and the content. If I change it the status code 200, web browsers will accept it as a normal request and if it sends
index.html, all the routes will be handled by the appindex.html.CloudFront Functions - It catches a request and change the
uritoindex.htmlto display the app.Hi @lico, yes you got it! :-)
My post was mainly related to React SPAs with React Router, but the principle applies to other frameworks as well. The first HTTP request from the user is the crucial step here: if the URL contains a path like
/about, S3 will try to find an object namedabout. If it doesn't find it, it will continue looking for a folder namedaboutand try to find the objectindex.htmlin that folder. If it doesn't find that either, it returns a 404.With CloudFront, we can handle this case on the server side without the user being aware of it. In the case of custom error responses, CloudFront receives the 404 from S3 and simply requests the
index.hmtlfile from S3. This is then returned to the user like a normal 200 response. CloudFront functions go a step further and let us intercept the request to S3 and modify it directly. So in this case we don't process a 404 from S3, but directly request the correct "index.html".I got it! Thank you for the answer and the post!! 👍👍👍
Thanks Chris, I'd like to take this a step further with another use case for a cloudfront function that I wrote about. Also read thru all three parts of this comprehensive series about challenges overcome during cloudfront migration. Let me know what u and others think, thanks
Entitled - Enabling AWS S3 to behave more like a Web Server
dev.to/rickdelpo1/enabling-aws-s3-...
Thank you Rick! I'll take a look at your post, the title sounds promising! :-)
I stumbled around a bit along the way but had some critical takeaways that now have me sold on AWS.
What were these?
Most Importantly I learned about what I can do with Cloudfront functions using the request object: conditionals, redirects, subfolders, security headers at response level. Then I learned about some obstacles encountered along the way during my migration and how to overcome them. My 3 part series is a deep dive into all these details.
Great
Thank you for the great post,
But I belive there are better alternatives to host SPAs like Netlfiy that takes all the extra steps to make S3 work.
Hi @hussam22 thank you!
But how would you better define?
I won't argue that Netlify and Vercel are a valid choice. My personal blog zirkelc.dev itself runs directly on Vercel because it's just super convenient. However, I still want to emphasize the value of understanding how these things work. Or as in this post, why they don't work the way we expect them to.
Hey, Why not simply use Aws-amllify that will automatically do all these under the hood with advance capabilities.
Hi @imdkbj
of course, you could simply use Amplify for hosting and it will take care of all these things.
However, I think it's always good to understand what's going on behind the scenes. Services like S3, CloudFront, Route53, etc. are the low-level building blocks, while Amplify is more of a toolchain that puts these building blocks together in the right combination.
If Amplify meets all your needs, that's perfect, then stick with it. But there are many users, myself included, who either already have a specific infrastructure in place, need a specific feature that is not currently supported, or simply want full control over their resources.