51 lines
2.7 KiB
Markdown
51 lines
2.7 KiB
Markdown
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].
|
|
|
|
[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.
|
|
|
|
### 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.
|
|
|
|
[hugo]: https://gohugo.io/
|
|
[zola]: https://www.getzola.org/
|
|
|
|
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.
|
|
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
|