back
13 comments
Static sites are a neat solution for most web publishing these days (I built Punch - one of the earliest static site generators).

However, one of the main complaints I received was the inconvenience of using such a setup to deliver a client project (or managing a site with a team of non-tech people). At this stage most still end up with Wordpress or other CMS from last decade.

I'm working on a new project called Pragma[0] which combines the benefits of static sites with the conveniences of CMS and Web-site builders. I wrote about it in detail: www.laktek.com/2016/11/29/introducing-pragma/

[0] https://pragma.build

You might be into Lektor ( https://www.getlektor.com/ ), which is a great middle ground between static site and dynamic CMS -- it's a static site generator, but has a GUI client that is somewhat usable for non-technical people. It's a very clever system and un-opinionated about how you structure your content.
> But of course there are downsides: caching can be annoying sometimes, because file changes take much longer to be rolled out

If you just want the SSL, you don't have to enable caching on cloudfront — that way you get in the instant updates at the cost of a bit of performance.

Valid point. I will clarify this aspect in my blog post later today. (UPDATE: done. thanks for your input!)
A few years ago, I used CloudFront as a CDN for video files hosted on S3, and I ran into performance issues -- I think because the traffic was relatively low, and hence it took more time for the CDN to "reload its cache" (for lack of a better term) than it would have been to just serve the files directly from S3.

Just a word of caution for people thinking (as I did) that a CDN is an automatic performance boost for all situations... it might actually be a detriment if you don't get reasonably high traffic.

Interesting – can you quantify these performance issues somehow or do you have any other insight what was happening there?

It surprises me to hear it, because when CloudFront refreshes an item, it should immediately start to forward the retrieved data from the first byte onwards. So, the maximal additional latency could be the initial roundtrip between CloudFront and the origin (which I suppose should be neglectable in case of S3).

It was a while ago (2011), and it was specifically with streaming videos using the RTMP protocol... so it might have been specific to that. But here is a StackOverflow answer someone wrote that explained the general idea of how CDN's might slow down the process for infrequently-accessed files:

http://stackoverflow.com/a/7800805/477513

EDIT: In re-reading that S.O. answer, I see now that this is specific to LARGE files (these videos were 50+ MB each)... so your use-case of HTML files and images for a static site would probably not result in this performance problem.

Is there any inherent advantage in setting the TravisCI account permissions in the bucket properties rather than the IAM role, or is it just a personal preference thing?
In this case it was indeed a matter of personal preference, because I wanted to see all the bucket permission in one place.

AWS offers some guidance on this question in their docs: https://aws.amazon.com/blogs/security/iam-policies-and-bucke...

It's a great design! I use a similar setup for my blog and wrote about it here: http://blog.michaelschmatz.com/2016/03/31/how-i-wrote-this-b...
What about GitHub Pages + CloudFlare? Hard to beat free. There's also free CI with Travis.
In my case I decided for S3 because I use Hugo instead of Jekyll and I wanted to avoid checking in the build assets into the Repo. My S3 costs range around a few cents per month.

However, if you use Jekyll or don’t mind commiting the build output, GH Pages is a superb option for sure.

I've been meaning to try this out instead of github pages just to learn about it. I was hoping this tutorial was for users 1 step less technical :(.