Create a CloudFront Distribution

From @jayair on Mon Apr 10 2017 01:09:21 GMT+0000 (UTC)

Link to chapter -

Copied from original issue:

From @tommedema on Thu Oct 19 2017 13:47:57 GMT+0000 (UTC)

> So we are going to create a custom error response and return a 200 status code instead. The downside of this approach is that we are going to be returning 200 even for cases where we don’t have a route in our React Router. Unfortunately, there isn’t a way around this. This is because CloudFront or S3 are not aware of the routes in our React Router.

This seems like a deal-breaker for production / corporate purposes. Instead of saying there is no way around this, perhaps we should explore serverless alternatives to using cloudfront + S3?

For example, what about serving the application directly from Lambda with a simple node HTTP server?

From @jayair on Thu Oct 19 2017 18:00:16 GMT+0000 (UTC)

@tommedema It depends what your client side app is for. If your app is a dashboard and the “routes” are purely for client side use then this isn’t as much of an issue. However, if you are using it to serve content publicly then using a Create React App is probably not the best solution anyway.

Lambda + HTTP does work for cases but you need to decide if a cold start is okay for your use case.

For other ways to deploy your Create React App you can refer to -

From @bharloe on Thu Oct 19 2017 18:41:47 GMT+0000 (UTC)

@jayair Could you explain why Create React App is not a good solution for serving content publicly? I can’t really think of any deal breakers. Maybe it would be good to have a “use cases” page for this serverless stack?

Edit: Or possibly a limitations type of page. I was going to try to extend this stack into a site that would include content pages like blog posts.

From @jayair on Thu Oct 19 2017 23:56:09 GMT+0000 (UTC)

@bharloe That’s a good point. We cover a specific use case for building a client side app in React but we are noticing more folks extending the use cases.

For public content pages, SEO would be my biggest concern (even though Google does index client side JS). I would feel more comfortable using some sort of a static site generator (like Gatsby perhaps).

I’m not sure if these would classify as deal breakers for me. But as it was pointed out above, maybe the response headers for pages that are not found being displayed as 200s is one for you.

From @tommedema on Fri Oct 20 2017 04:40:39 GMT+0000 (UTC)

@jayair Gatsby is a good recommendation. I’ll give it a go.

From @bharloe on Fri Oct 20 2017 22:34:25 GMT+0000 (UTC)

@jayair I see, yeah those are important considerations. As someone who was coming at this with more serverless experience and basically zero react experience these problems are news to me, and I would really appreciate a page that explains potential pitfalls like this somehow. But overall I love this tutorial (seriously, one of the best I’ve ever taken), and I know you have to draw the line somewhere as far as what this tutorial covers. Thanks for the Gatsby recommendation, I’ll check it out. Is it fair to say that the issue, insofar as SEO concerns go, is that the app is built as bundled javascript which many web scrapers have trouble with parsing? So it’s not necessarily an issue inherent to React, but rather to how the React app is built/deployed?

From @jayair on Sat Oct 21 2017 23:45:42 GMT+0000 (UTC)

@bharloe Thanks!

Yeah the app we are creating in the tutorial is rendered completely on the client side. But React does support server side rendering as well. So when you request a URL it responds with the complete content as the HTML (as opposed to returning the bare minimum HTML and making API requests after). And I know Google does execute client side JS (I think Bing doesn’t) and I wouldn’t feel comfortable hosting a blog or a content driven public site with just client side rendering. That’s not to say that people don’t but I would prefer not to.

From @maxdarque on Wed Dec 20 2017 14:08:36 GMT+0000 (UTC)

When I tried accessing a page via react-router i.e. on S3, I got a 403 response. Is it worth setting up an Error page for a 403 response with a redirect to /index.html?

Same as this person

1 Like

Same here! From what I read, S3 is now sending 403 errors instead of 404 errors.

You want to repeat the step " Pick 404 for the HTTP Error Code and select Customize Error Response . Enter /index.html for the Response Page Path and 200 for the HTTP Response Code ." and just replace 404 with 403.

1 Like

Thanks for letting us know. We’ll update the tutorial.