Item — HN Reader

Netlify is awesome--far and away the best option for static content that I've found, and very developer-focused.

There's a big list of pleasant surprises as you work with their platform:

* You can deploy a folder of static content quickly by just dragging it onto the browser window

* Better, you can set up continuous deployment with github and netlify will run your build command and deploy the result whenever you push to Github

* Even better, Netlify will install any needed dependencies from any Gemfile, package.json, bower.json or requirements.txt in the root of your repository, before running your build. Now you are open to a wide world of static site generators and build tools.

* There's a command line tool and a rich, well-documented API

* Clever: You can add a simple _headers file to define custom headers

* Great for migrations: a _redirects file can power some pretty complex rulesets

* Blew my mind: you can configure proxying so that external API endpoints appear to the browser to be coming from the same domain. This can greatly simplify the headaches around cross-origin resources.

* Bonus: HTTPS is supported

3 comments

I was saying "okay-ish" till I reached the last three points. Sounds amazing for Single Page applications.

Thanks for sharing these points, from a quick look at the site I couldn't figure out differences with GitHub pages.

Do you know how is the CDN working across the planet?

HTTPS & proxying look great! I'm hosting HasGluten.com [1] on GitHub and HTTPS is a big missing. Also, I'm using Google spreadsheet API (instead of a database) and proxying via my domain could be cool.

I was asking about the CDN, as one of the good things of GitHub+Google spreadsheet is (free) geo-distribution.

[1] http://github.com/hasgluten/hasgluten

Our CDN is global yes. Actually, when you deploy to netlify, we'll fingerprint all your assets (CSS, JS, images) and rewrite the URLs in your HTML so we can serve those straight out of Akamai's CDN with a 1 year max-age.

We run our own CDN for the actual HTML files, currently we have edge nodes in 7 datacenters around the work. This CDN is super optimized to this use case, which means you'll get a 90%+ cache hit rate on your HTML from our cache servers, while still getting instant cache invalidation whenever you push a new deploy.

This is also what allow us to do more complex things like proxying, OAuth1 request signing and pre-render support directly at the CDN level.

We currently beat all the services we run regular benchmarks again in our internal benchmarks for real user performance.

Very cool stuff - question - on the website you mention: "Those that need a CMS (major exception we know, but check in with us regularly - we are working on something huge), and those that need constant updating."

Can you give us any hint of what you're thinking about?

A bit too early to drop a lot of details in public, but feel free to write me (mathias@netlify.com) and I'll be happy to share more details.

We want to solve the issue of having non technical content editors when working with static site generators, without having to rely on an external content-store (ie. content should still just be flat text files in your repository).

Right now the workflow for developers is amazing with modern static site generators. We want to make sure it's great for content-editors as well.

Really interesting, thanks. Hopefully I'll have some time to try it soon!

Tiny nitpick on the page: why does clicking on "pricing" in the menu take me to a page where I have to scroll over multiple screens until I actually get to see the prices?

>ou can configure proxying so that external API endpoints appear to the browser to be coming from the same domain

Where is the proxy server running?

We do the proxying straight from our CDN nodes, so it basically works like putting a CDN in front of the app/site you're proxying.

This also means you have an HTTP cache in front of the proxied site, so if you use HTTP caching headers like max-age or Etag we'll respect that and do conditional get requests to the backend or serve cached responses straight out of our CDN.

The proxies run on their CDN servers as I understand. I was just playing around with the proxy setup a bit to experiment, but I do plan to use this approach in a project if it proves successful.