Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Static site hosting hurdles

notes.volution.ro

Post reply on HN
Print view View original

121–130 of 183 posts

Re: Static site hosting hurdles

#121

Post by ciprian_craciun »

Theodores wrote: post #118
Aldipower wrote: post #115

One forgotten hurdle of static site hosting is in-memory caching. At most http-server default setup each request goes down to the filesystem. Mostly your are lucky and your filesystem itself has some kind of caching mechanism, so you won't notice. But if your static site ends up in a "very high requests" situation, you should think about in-memory caching of your static files.

With nginx you should set static files to be on a separate cookieless domain and proxied to a different port with the nginx cache keys set how you want them. You should be using brotli dialled up to 11 for scripts and stylesheets. This takes ages to do if done on the fly but works great if using an nginx cache. Images need to be on another cookieless domain with the cache configured to work with accept headers, in th…

> Building an origin server for a CDN is a different task to building a regular server. The focus for cached resources is getting the byte size down, not serving a billion requests at once. The CDN can do that.

I think this put perfectly in words what I've believed for some time, but failed to compile into words...

However, having once you've gotten your cached resources down to the smallest size, you can now also optimize for serving a lot of them at once. :)

Re: Static site hosting hurdles

#122

Post by chrismorgan »

ciprian_craciun wrote: post #110
chrismorgan wrote: post #90

> check that with/without .html extension serving works properly; (i.e. /some-file.html should perhaps return the same content as /some-file, or even better, choose one as canonical and redirect for the other one;) Strong disagree. You do not want both URLs to return the same content; you can have alternatives redirect to the canonical URL; but think through why you’re doing it: who is benefited by the redirect? If y…

> Strong disagree. You do not want both URLs to return the same content; you can have alternatives redirect to the canonical URL; but think through why you’re doing it: who is benefited by the redirect? At least with regard the with/without slash redirects there is value in these: sometimes the user copy-pastes the URL but forgets the final slash, sometimes the application he is using for bookmarking, sharing, etc. d…

You seem to have missed a good chunk of what I said.

But to address some particular points:

> sometimes the application he is using for bookmarking, sharing, etc. drops the slash

Do you happen to have any evidence of this? I’ve heard it mentioned very occasionally, but never seen it, including any probability of it in logs (though I have seen more bizarre things), and the only ways I can imagine it being likely to happen would break many other things too, so that it doesn’t seem likely.

> perhaps you've been inconsistent along the years, thus having redirects saves the dead links...

And so I strongly advocate for retaining such redirects. Just not gratuitous support for other things.

> It is when you don't want dead links.

I said for the sake of it. If by “dead links” you mean “existing URLs that worked in the past”, that’s not “for the sake of it”, but good cause. But if you’re speaking about proactively allowing things that never worked in the past, that’s exactly what I’m arguing against. I want robust justification for every extra URL that is supported, of the machine or human that is likely to encounter it and why. (As an example of this, I’d honestly quite enjoy returning 400 for requests with unknown query strings parameters, which in the context of static websites mostly means any query string, in order to truly have only one URL for the content; but I acknowledge that this is not pragmatic because it’s not uncommon to inject additional query string parameters, typically for the purpose of spying on users in unwanted utm_* parameters and the likes.)

Re: Static site hosting hurdles

#123

Post by giantrobot »

chubot wrote: post #39
giantrobot wrote: post #34

Earlier quoted context omitted.

I've also been a Dreamhost customer for a long time. Note that Dreamhost's $10/mo is for I-don't-know-exactly number of domains. If you own a domain name you can add it in their dashboard, point it to their name servers, and you're up and running. Their services includes e-mail which means avoiding the perils of fully self-hosting. While you could save a few dollars renting a VPS, it's only cheaper if your time is wo…

Yeah I think it's infinite domains ... You pay a yearly fee for each domain, which is something like $16. But the hosting is a flat fee at less than $10/month. (edit: just checked, actually I pay yearly for a discount.) So I find that to be pretty nice, because I have had 5 domains at one point. And now I have 3 or so. But I always keep the same hosting account. It works well in practice.

You can register your domains anywhere and point them at Dreamhost. I don't recall any fees for setting up a new domain with them so long as you already own it.

Re: Static site hosting hurdles

#124

Post by ciprian_craciun »

the_gipsy wrote: post #120
akerl_ wrote: post #3

It felt odd to see a doc this comprehensive on static site hosting with no mention of AWS S3/Cloudfront, given how easy it is to push content to an S3 bucket (either manually or via the CI pipeline of your choosing) and then serve it up either direct-from-S3 or via Cloudfront. But then it turns out that this is actually pushing folks towards some new paradigm of static cached HTTP responses instead of files. It pitch…

"HTML on disk" does not cover headers. But it's true that cloud providers have that solved, and "DIY" bring-your-own-server don't, and the article somehow concludes that bringing your own server with the right configuration is not an option.

> [...] the article somehow concludes that bringing your own server with the right configuration is not an option.

[the author here] On the contrary, it is an option to fine-tune your web-server configuration to put all the right headers in the right places. (I usually do this from HAProxy and just ignore the web-server.)

However, the point I was trying to make in the article is that where these headers are configured is divorced from the content itself lives. I can't look at a HTML file and easily say "when the browser will hit this resource these are the HTTP headers that will be sent in the reply"; I need to execute in my mind the web server configuration logic to get that.

Thus my proposal is to move back (some of) the headers where they belong: as meta-data right besides the actual resource.

Re: Static site hosting hurdles

#125

Post by pSYoniK »

I just use a VPS, Caddy with a 10 line Caddyfile and scp my html on to the machine.

I don't find any real hurdles here and the only thing running on the server is Caddy to serve the content on https/http. Anything that's not a valid path returns a 404 custom page I made and that's it.

To get my HTML I use Hugo locally, but I'm not a huge fan of Hugo itself due to it's documentation which cannot be followed linearly and I plan on writing something to do just this - convert some markdown files and a folder structure to an HTML. I'm sure such a tool already exists but I'm curious about building something like this myself.

I think the hurdles appear depending on what you expect or want to do with your static page, but the base setup is I think pretty straightforward.

Re: Static site hosting hurdles

#126

Post by quickthrower2 »

I read this as:

The problem is there are 99 ways to do to it from sysadmin-y to cloud-y.

My solution is to add 100th way.

——-

If static hosting is hard use Netlify or similar. Just point it at your Github and you are done!

They mentioned Netlify.

Re: Static site hosting hurdles

#127

Post by oneeyedpigeon »

hedora wrote: post #103
Dalewyn wrote: post #8

Earlier quoted context omitted.

>We’ve already standardized the hosting side of static sites by using the file system. Worth noting that the incoming younger generations can't and don't into file systems.[1] Yes, anyone who wants to be a webmaster should do their homework, but that is besides the point. We are probably the last generation who can be ubiquitously assumed to have an understanding of files and folders/directories in a computer. [1]: h…

In fairness to younger generations, I can never figure out how to use file choosers in modern operating systems or in crap like google drive. It takes me a minimum of 60 seconds to naviate to ~ using the GUI on my work laptop. (Partially because the dialog box sucks, and partially because I only do that once every 6 months or so.) It's like some UI designer didn't understand folders, then somehow forced their brain d…

> It takes me a minimum of 60 seconds to naviate to ~ using the GUI on my work laptop.

Which OS? For all its flaws (and there are many related to this issue, like overzealous hiding), macOS lets me add ~ as a 'Favourite' which then shows up in file choosers as well as the main file browser app.

Re: Static site hosting hurdles

#128

Post by nsteel »

chubot wrote: post #76
bachmeier wrote: post #71

Earlier quoted context omitted.

> I prefer not to use free services because they're not sustainable Just a guess from outside, but Microsoft is likely to be sustainable even if you use GitHub Pages to serve your static site on a free account.

When I say "sustainable", I don't just mean that the company might not have enough money to keep its lights on It's more that some product manager or VP will notice this free service and want to attach their strings to it. Having worked in big tech, it happens very often. Google Groups is a famous example at Google (among many). It was way better 15 years ago, but it just wasn't "worth it" to keep the lights on in it…

I don't disagree with you but you can't use Google to support your argument. They have to be the worst player out there when it comes to supporting free services over the long-term. You're so much safer with Github's free tier, there's no comparison.

Re: Static site hosting hurdles

#129

Post by jacooper »

justsomehnguy wrote: post #92
coder543 wrote: post #62

Earlier quoted context omitted.

I used to do something similar, but DigitalOcean App Platform's $0/month "starter" plan[0] hosts a static site for even less effort. When I was self-hosting on a DigitalOcean droplet, I was using Caddy instead of nginx, which handled letsencrypt for me, so that was nice. [0]: https://www.digitalocean.com/pricing/app-platform

I'm using Caddy with Docker labels auto-configuration. It's somewhat PITA to configure if you don't need a public cert, eg something for testing or not having a public A/AAAA record, but otherwise the automagik just works. The only negative moment is what Caddy container restarts when the dependent containers starts|restarts, so you briefly lose all connectivity to all sites behind Caddy. [0] https://github.com/lucas…

There are also security implications that the webserver has access to the socket directly.

Re: Static site hosting hurdles

#130

Post by twhitmore »

akerl_ wrote: post #3

It felt odd to see a doc this comprehensive on static site hosting with no mention of AWS S3/Cloudfront, given how easy it is to push content to an S3 bucket (either manually or via the CI pipeline of your choosing) and then serve it up either direct-from-S3 or via Cloudfront. But then it turns out that this is actually pushing folks towards some new paradigm of static cached HTTP responses instead of files. It pitch…

I agree -- the OP said space for all the separate HTTP response variations might be an issue, and "With a smart enough storage format all of these could be solved".

I think he misses that storing HTML and having a webserver turn this into HTTP responses, might be exactly the storage format that solves this problem.

Post reply on HN