|
|
|
@ -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. |
|
|
|
|
|
|
|
[](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 |
|
|
|
|
