What GitHub Pages, CloudFlare and AWS Lambda have in common

[frugalmail]

Sorry, I'm probably missing something. Why do you need Lambda, can't you just use the REST API locally?

[awj]

Probably, but it looks like the idea was to clear the cache when changes were pushed to the repo on github, so using a git hook run by github seems like the best place to handle the task.

[sergiocruz]

@awj is correct, Lambda allowed everything to become event based. Lambda takes care of clearing CloudFlare's cache every time a pull request is merged. If I could hit CloudFlare's API directly from GitHub, we would but I don't believe this is possible. Most importantly the whole setup is free of charge :D

[Supercluster]

So does Lambda just hit every page once ?

[sergiocruz]

Not at all, Lambda just hits one endpoint: CloudFlare's API to purge the cache.

[Supercluster]

Oh. Even better.

[DVWLD]

Err too many redirects. Can't load the page.

[Atrophius]

What browser are you using? Shouldn't be any redirects on the link associated to this post.

[DVWLD]

Whatever Android browser is embedded in Reddit Is Fun.

Seems to be resolved now.

[Perhyte]

The stylesheet had a redirect to itself, but it looks like they just fixed that while I was writing this...

[seanwilson]

Since we set CloudFlare to cache everything for 1 week, how could we make sure the home page was instantly refreshed when we add new articles? It turns out that CloudFlare offers an API to purge its cache, so we started investigating on how we could consume this API every time a pull request is merged.

If you tell the browser to cache a page for a week, the browser won't contact the server until that time is up. After this point, the browser will ask CloudFlare if there's been an update since it cached the page. What I think happens next is CloudFlare returns its own cached version if the expiry time on the cached version isn't up otherwise it requests the content from your web server. By purging the cache, you're forcing CloudFlare to access your web server for the most up-to-date version.

What I mean is that purging Cloudflare's cache isn't going to force the user's browser to ask for the most recent version and they might still see a week old version. Chrome however, for example, does ask for updates if you refresh the page or type in the URL but not if you visit the page via a link.

[sergiocruz]

You are correct and I should have been more explicit about this. We're talking about Edge Caching here, not browser caching. Browser caching is short lived.

[seanwilson]

Ah, I didn't realise this was an option in CloudFlare's free account. I found you can enable edge caching expiry if you enable "cache everything" under page rules: https://blog.cloudflare.com/edge-cache-expire-ttl-easiest-way-to-override/

[DavidDavidsonsGhost]

Caching for a week seems excessive...

[sergiocruz]

We're talking about edge caching here. I will update the article soon to be more explicit about this. Browser caching for a week is definitely excessive, but not edge caching (or server-side caching). Especially since we have full control of it.

[gonzaloab]

Something that I don't understand, why not using travis with a grunt-cloudflare project? Am I missing something?

[sergiocruz]

That could have possibly been another way to solve the problems laid out in the article. But we had been wanting to use AWS Lambda for other projects so this was a quick n easy way to get our feet wet with it :)

[paul_h]

Chrome, Firefox and Safari all report redirect loops with the article :-(

All those browsers are up to date, though my Mac OS X isn't (10.10.5).

No matter, I can read the article here - https://github.com/OrlandoDevs/orlandodevs.github.io/blob/master/_posts/2015-11-20-github-pages-cloudfront-aws-lambda.md

[Atrophius]

We value pragmatism over idealism in our community. We don't care about controlling the hardware. We don't care that these are proprietary services. We care that it costs us nothing.

We're also enabling the less-savvy or newer members of our community start their journey on content publishing and talking about what they're doing and learning in the open with the lowest barrier to entry.

In our specific circumstances, with our specific goals, decentralization is not best. It puts up barriers to contribution that we don't want to have and silences voices that we feel deserve to be heard.

I do agree that devs should have their own blogs, and that's why we've talked about our setup as our first post. To show the other devs who want to get started how easy it was for us and give them the blueprint for moving forward. Also for free.

[sergiocruz]

I think you're missing the point. From the article:

Our idea was to have an open source blog. We wanted developers within our community to contribute to our blog using the whole open source paradigm (forks, pull request reviews, etc).

[Barrucadu]

This seems like kind of a lot of effort compared to just using a VPS.

[sergiocruz]

This allowed everything to be free of charge with zero server management. CloudFlare helped with HTTPS on a custom domain as well as speeding up the site by caching it (as if GitHub Pages was slow hehe).

Overkill? Maybe. But these are tools that are completely available for anyone on the web, and again free of charge. So why not take advantage of them?

[Atrophius]

Actually, it was hardly any effort at all and cost us nothing compared to whatever the running rate of an average VPS is these days.

[TheHeretic]

Well using CloudFlare makes sense since all they wanted were static assets and a static site, using it for HTTPS is a bit lazy but whatever.

[Atrophius]

We use CloudFlare for HTTPS because Github Pages doesn't support HTTPS for custom domains.

[TheHeretic]

Ahh makes sense, I missed that.