Porting my website to Workers Sites and Zola | Hacker News Reader

Porting my website to Workers Sites and Zola

words.steveklabnik.com

109 pointssteveklabnik44 comments

It's interesting to see how Cloudflare seems to be desperately avoiding becoming a static site hosting service.

They now have a KV storage and a CDN, but you still have to write and upload a <20 line script to connect the two, instead of being able to just select a KV namespace on the CDN from which to serve a static site.

EDIT: The KV store does have a REST endpoint for reading values, though.. I wonder if you could use the CDN to point a domain to /storage/kv/namespaces/[site-namespace]/values/ and use Page Rules to pass the authentication headers. I'd try it, but I'd rather burn the fiver on a glass of Port.

I mean, before this you could do it but had to do it all yourself, I’d characterize this as the opposite of avoidance. It’s moving closer. I am, of course, biased.

You have to start somewhere. We would like to make this even easier in the future. Can’t promise specifics or times for that, though.

Fair enough, I didn't mean it as a dig against Cloudflare. It's just that you're already providing all the components, and now even giving the instructions on how to connect them, just not adding a configuration screen to do so.

It's like a pc shop that sells you a nice pre-built desktop and monitor, but instead of a VGA/HDMI cable there's a paper with instructions on where to buy one :)

It’s not so much that we’re avoiding it, as much as we think there are more interesting things for us to accomplish. We could double down on hosting static sites, but that’s only one use case of the realm of possibilities of what we can achieve with compute on the edge with Workers. We’re excited for people to get their hands dirty, and see where else they take it.

Yes, that absolutely makes sense to me, and to continue GP's analogy - it's a 'pro PC shop', not a 'fix your computer and tell you you need a new mouse mat and thumb drive' shop.

If someone springs up and starts making money providing a static site hosting solution built on top of CloudFlare, that sounds to me like a success for CF, not a missed opportunity.

This makes it incredibly easy for me to deploy Elm web apps (which are all static). For a while now, my side-project's backend (Rust) was deployed in a Cloudflare worker and the frontend (Elm) was a Github Page (using Cloudflare for DNS).

Today I moved my frontend over to a Worker, and deleted my GitHub page repo. This is much simpler. Now I don't have to worry about cache rules, and I can use the same deployment tooling for the backend and frontend.

(I am a Cloudflare employee on a totally different team, and the project is a plaintext screenplay renderer https://screenplay.page)

You don't have to worry about cache rules, but what about your bill with Cloudflare?

5$/month plan is kinda open ended, you pay for each request above included in the plan (0.5$ for 1 million requests)

With a high-perfomance language like Golang for example, I could write a script that's making 500req/second to your site. That would cost you 20$/day.

With Github Pages it wouldn't cost you anything (or they might disable your page if it costs too much bandwidth, not sure)

> You don't have to worry about cache rules, but what about your bill with Cloudflare?

> 5$/month plan is kinda open ended, you pay for each request above included in the plan (0.5$ for 1 million requests)

> With a high-perfomance language like Golang for example, I could write a script that's making 500req/second to your site. That would cost you 20$/day.

> With Github Pages it wouldn't cost you anything (or they might disable your page if it costs too much bandwidth, not sure)

500req/s would result in you being ratelimited by the global worker ratelimit though unless you distributed these requests across multiple IPs.

I'm getting an error trying to load that site: 'The resource from “https://screenplay.page/main-ddefa53b6789be8ec720.css” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).'

I have been using Zola for about a year and a half now and I love it. However I just use Caddy in a docker container to host it, as Caddy's git plugin can listen for github webhooks. All I have to do is push to git and it rebuilds. I have a post explaining how I set that up. [0]

[0]: https://andrewzah.com/posts/automatically-deploy-your-blog-v...

Neat! This does require you to run your own server, which has pros and cons. I’ve heard great things about Caddy but never used it myself.

> Neat! This does require you to run your own server, which has pros and cons. I’ve heard great things about Caddy but never used it myself.

Things like AWS fargate allow you to run containers without running the underlying server though.

Yep, that's fair. In my mind, the differentiation here is that Fargate (which with my Rust team hat on, I'm a fan of; it uses Rust!) picks and chooses where it thinks the best place for your code to run is, and you don't really have control over that, in my understanding. Workers runs on every single POP without you needing to do or choose anything.

But regardless, different tools are good in different circumstances. Nobody is always the best thing all the time.

> One fun thing about having a personal domain is that you can keep the contents the same forever, but take a few days every so often to port it to some new stack you want to try out.

Oh yes! I'm playing with Hugo today and maybe Zola tomorrow. Now I'm on Dokuwiki, before that other CMSes.

I always thought of that as a weakness, not being able to be content with something, but the way you phrase it lifts my spirits.

If anyone wants to add blog comments to a static Zola site, I created an integration for Zola a while ago, in a commenting system I'm developing: https://www.talkyard.io/blog-comments (I was curious about Rust, hence Zola)

To be clear, this post is on (one of my) blogs, which is on Svbtle. The main site is what I ported. I like Svbtle, and maybe will move all of my stuff back onto the main domain, but haven't felt the need just yet.

What service do you use to manage the domain? I'm looking for an affordable option that would make it easy to redirect to a new service frequently, as you describe.

I currently have the domain registered via NameCheap. I have all of my domains there currently, except for the .rs ones, since it doesn't offer them.

Most "redirect" stuff is "point a DNS record somewhere"; so I have the 'www' subdomain pointing at Cloudflare, the 'words' subdomain pointing at Svbtle, I think 'blog' is pointing at... heroku? Before I moved www to Cloudflare, it was pointed at Netlify, and then gh-pages before that.

I've been meaning to check out the new Cloudflare registrar, but there's only so many hours in the day :)

Workers sites seems nice but is still limited to 2MB pages (same as the max. key size for KV) https://developers.cloudflare.com/workers/sites/reference/

Depending on the frameworks used and how big your application's own code base is, webpack and other build systems can easily produce artifacts above 2mb, not even to mention that images can also reach above 2mb in size.

FD: I worked on a Workers-based file hosting project before this first-party solution came out; my system does file splitting and stitching, making it more expensive for files >2mb but possible. https://github.com/judge2020/cloudflare-file-hosting

I'm the PM on KV, and you're absolutely right. I am interested in possibly raising this limit. Large media like videos will probably never make sense for KV, but discounting situations like that, what would the limit be that you'd never have to worry about running into it 99.9% of the time?

Perhaps 5-10mb, but there's a wide range of websites that go from really heavy to really light. I don't think workers should accommodate for installing all 10 of the top 10 most-used frameworks with tree shaking disabled, but 2mb is limiting and raising it would make it viable for many more existing sites.

Thanks for the input :)

Building a non-prod Angular project produces a 7 MB js file, so the 2 MB limit definitely needs to be raised. I think it would make sense to have a higher limit for certain file types, like js and html.

I am very interested in this feature, but the limit is a bit concerning right now.

Thanks! To give some context here, KV is also implemented as a worker, and we encrypt your contents, so we’re also subject to CPU limits. There’s a trade off here and experience reports are super valuable, so thanks :)

As a workaround maybe you could, behind the scenes, split large files into 2 (or more) key-value pairs, and then bill appropriately for the use of 2 key-value pairs instead of just 1.

Possibly, yeah! You won't necessarily get a ton of speed that way...

This is how my file stitching logic works, and it's actually pretty fast (some reported 2mbps-30mbps depending if the DC had those keys locally cached), it's just incrementally more expensive for each 2mb increase in file size. https://github.com/judge2020/cloudflare-file-hosting/tree/dd... But it might be a little much for this to be a first-party solution.

Thanks for the tip. By the way, line 84 introduces some unneeded serialization; you could get some more speed there by fetching the bits in parallel.

Neat, I was thinking about doing just this!

One clarification:

> Additionally, you need to have a $5/month subscription to Workers, to get access to Workers KV. I want us to offer a free tier of KV in the future, but we’re not there yet. That $5/month gets you a lot more than one site, to be clear, but this isn’t a completely free solution today.

Just to be clear, since I misunderstood at first: there is a free tier of Workers (which is absolutely worth trying). It's the KV store that adds cost. I think you are saying that, but it also could be read that Workers by itself costs $5/mo.

But conceivably, you could host your blog on the free tier, right, by compiling the static content into the hosted app?

Yes, there's basically two tiers of Workers for self-service: Free, and $5/month. You only get access to KV on the $5/month plan currently. You do get better speed and more CPU time for those workers, but it's strictly speaking KV that requires the $5 here.

> But conceivably, you could host your blog on the free tier, right, by compiling the static content into the hosted app?

Yes, you could! There's a size limit to a worker though, so for a large site you may not be able to.

Totally! I do that for small sites quite often, e.g.:

- https://lazy.invoice.workers.dev

- https://web.scraper.workers.dev

Both are powered in part by a worker which generates CSS on the fly for whatever components you need, e.g:

https://ui.adam.workers.dev/?components=button,input

Looks good, bookmarked!

Interesting read.

This part caught my eye:

"The +++s are like --- in Jekyll, and the metadata is in TOML instead of YAML"

Why does it seem like every other day a new mark-up comes around, with its own syntax, often (in this case) the exact opposite symbols. I mean, I guess "markup is hard" or something along those lines, but it doesn't appear to be to me.

For what it's worth, TOML [0] has been around for a few years. It's intended for configuration data and borrows some ideas from INI files. The +++ thing is just Zola's way to have you tell it whether you put YAML or TOML inside the "front-matter" of the post. +++ and --- to denote front matter isn't a standardized thing, as far as I know; it's just a convention that a lot of static site generators seem to follow. +++ in particular for TOML might have come from Hugo (that's at least the first place I encountered it).

[0]: https://github.com/toml-lang/toml

The "cute" thing about using --- is that it's a part of the YAML spec as a document divider [1] and some of the cheaper front-matter readers were just YAML spec-compliant libraries told to read only the first document in the file. It's almost weirdly disappointing that +++ doesn't have any real specificity to TOML itself.

[1] --- is the explicit document start marker. Most frontmatter should probably be more accurately using ... which is the actual explicit document end marker and doesn't imply another YAML document follows, but the symmetry of using --- on both sides is cleaner.

Huh, thanks for that, I never thought of the --- as being part of the YAML (as a document divider); I always thought of it as being part of the Markdown (as a horizontal rule).

I agree with you that it's cute to be able to parse YAML frontmatter by streaming the file to a YAML parser that's been instructed to stop after the first document... but it makes me all the more uneasy about frontmatter as a concept. Call me old fashioned, but I want my files to contain just one kind of syntax.

Needing multiple parts for a document is one of the older needs on the net (MIME's first RFC was 1992, for instance; though MIME would presumably be a terrible format for static site generators). Frontmatter seems related to HTTP headers, its just interesting to have needs for similar metadata for a file "at rest" as opposed to in transit.

Though HTTP does have an "at rest" relative, the META tag in HTML. Similarly, reStructuredText has always had "Field Lists" and even a history of using the first field list in a file as "frontmatter" and the docutils API even returns it as a separate metadata stream if asked. (Sphinx, for instance, checks for some fields there.) It's maybe just Markdown here that's deficient in having a first-class metadata syntax of its own. (reStructuredText and docutils also have a first-class concept of a document title made available by API to tools but maybe not intended for direct output in rendered contents, which is the number 1 reason for YAML front-matter in most Markdown documents I've seen.)

It did come from Hugo.

I'm not arguing in favor of churn, but in fairness TOML is at its core a cleaned-up/standardized INI file. Not exactly the new kid on the block.

The TOML in the post is identical to the first config syntax I used, back in the early 90s. It's based on ini syntax.

Static + Netlify is my current hosting scheme. Although I’m somewhat unique in that I use artisanal hand crafted HTML rather than using a generator.

I’m super happy with this setup and think it should be way more popular.

Does Workers KV rely on Quicksilver? Is that stuff going to be open source at some point? Just curious.

Workers KV is distinct from Quicksilver; I have no idea if it's going to be open source or not, sorry!

Thanks! It was quite the coincidence that I saw you were working on Workers KV at the moment I noticed that Cloudflare had abandoned Kyoto Tycoon for something else.

Reply on news.ycombinator.com