diff --git a/content/_header.md b/content/_header.md index 61d515c..b50d664 100644 --- a/content/_header.md +++ b/content/_header.md @@ -1,24 +1,23 @@ - - Markdown@Edge - -

Markdown@Edge

 --- diff --git a/content/favicon.ico b/content/favicon.ico new file mode 100644 index 0000000..5c2c3c9 Binary files /dev/null and b/content/favicon.ico differ diff --git a/content/index.md b/content/index.md index 24bb1e9..0cfa9da 100644 --- a/content/index.md +++ b/content/index.md @@ -1,36 +1,36 @@ -### What? - -This page is written in Markdown (actually in three Markdown files). - -These Markdown files are requested by Fastly's Compute@Edge engine and rendered into -HTML at the edge, on every request. - -You can check out the source code [here](https://git.nora.codes/nora/edgeblog). - +This page is written directly in Markdown - one file for the body, +plus one for the header and one for the footer. + +For each HTTP request your browser makes to Markdown@Edge, a Fastly server makes +checks its cache for the relevant Markdown files, and either uses the cached +files as-is or makes a request to my web server at nora.codes to retrieve them. +The WebAssembly code running on that server, compiled from a single Rust file, +then combines them, parses the resulting string as Markdown, and uses a +streaming event-based renderer to convert that Markdown to HTML. The only dependency of the service, other than the Fastly SDK, is Raph Levien's [`pulldown-cmark`][pulldown_cmark]. -It's not an optimal choice, as it only supports one-shot rendering and requires buffering -the Markdown (though not the resulting HTML) in memory, but it's the best option available -at the moment. [pulldown_cmark]: https://github.com/raphlinus/pulldown-cmark +In a normal website written with Markdown, this rendering process is done just +once, when converting source Markdown files into the HTML files that are +actually served to your browser. In this case, the rendering has been moved "to +the edge" and is running on a server that is probably physically much closer to +you than my webserver is. + [![A diagram showing the difference in pipeline between normal websites with a CDN and this monstrosity](images/diagram.jpg)](images/diagram.html) The renderer takes advantage of the fact that Markdown allows embedding raw HTML by embedding anything with a "text" MIME type in the Markdown source, while passing through anything without a "text" MIME type - images, binary data, and so forth - unchanged. - -That allows the above JPG image to embed properly, while also allowing the linked SVG image page -to be rendered as a component of a Markdown document. - +That allows the above JPG image to embed properly, while also allowing the +linked SVG image page to be rendered as a component of a Markdown document. ### Why? I work on the Compute@Edge platform and wanted to get some hands on experience with it. This is not a good use of the platform for various reasons; among other things, it buffers all page content in memory for every request, which is ridiculous. - A static site generator like [Hugo][hugo] or [Zola][zola] is an objectively better choice for bulk rendering, while the C@E layer is better for filtering, editing, and dynamic content. @@ -41,11 +41,10 @@ That said, this does demonstrate some interesting properties of the C@E platform For instance, the source files are hosted in [a subdirectory][source] of my webserver; in theory, you could directory-traverse your way into my blog source, but in fact, you can't. - -[source]: https://nora.codes/edgeblog/ - I also have a [Clacks Overhead][clacks] set for my webserver, and the C@E platform is set up to make passing through existing headers trivial even with entirely synthetic responses like these, so that header is preserved. + +[source]: https://nora.codes/edgeblog/ [clacks]: https://xclacksoverhead.org/home/about