nora
/
edgeblog
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Polish writing, css, and favicon

This commit is contained in:
Leonora Tindall 2022-10-01 22:17:53 -05:00
parent a80b0dff8f
commit c231dbd66d
Signed by: nora
GPG Key ID: 7A8B52EC67E09AAF
3 changed files with 23 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
content/_header.md
View File

@ -1,24 +1,23 @@
<style>
/* 100 Bytes of CSS to look good nearly anywhere */
html {
body {
max-width: 70ch;
padding: 3em 1em;
margin: auto;
line-height: 1.75;
font-size: 1.25em;
font-family: sans-serif;
}
/* 100 More optional bytes */
h1, h2, h3, h4, h5, h6 {
text-align: center;
margin: 3em 0 1em;
margin: 1em 0 1em;
}
p, ul, ol {
margin-bottom: 2em;
color: #1d1d1d;
font-family: sans-serif;
}
/* Don't underline the link to the index page */
@ -30,10 +29,8 @@ h1 a {
/* Clear around images, and preallocate their space */
img {
margin-left: auto;
margin-right: auto;
margin-top: 2px;
margin-bottom: 8px;
display: block;
margin: 2 auto;
aspect-ratio: attr(width) / attr(height);
}
@ -42,16 +39,11 @@ img[alt="A diagram showing the difference in pipeline between normal websites wi
width: 582px;
height: 521px;
}
</style>
<!-- These should, by rights, go in <head>, but we have no such luxury. -->
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>Markdown@Edge</title>
<!-- And here we begin the true page content. -->
<a href="/"><h1>Markdown@Edge</h1></a>
---

BIN
content/favicon.ico Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 318 B

37
content/index.md
View File

@ -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