From af09593474e2681e3ec1bf37f3d30ad424787f46 Mon Sep 17 00:00:00 2001
From: facundoolano <facundo.olano@gmail.com>
Date: Sun, 3 Mar 2024 16:47:47 -0300
Subject: [PATCH] outline + intro for serve command post

---
 .../blog/a-site-server-with-live-reload.org   | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 docs/src/blog/a-site-server-with-live-reload.org

diff --git a/docs/src/blog/a-site-server-with-live-reload.org b/docs/src/blog/a-site-server-with-live-reload.org
new file mode 100644
index 0000000..d56d174
--- /dev/null
+++ b/docs/src/blog/a-site-server-with-live-reload.org
@@ -0,0 +1,46 @@
+---
+title: A site server with live reload
+date: 2024-03-05
+layout: post
+lang: en
+tags: [golang, project]
+draft: true
+---
+#+OPTIONS: toc:nil num:1
+#+LANGUAGE: en
+
+** 1. Introduction
+
+The core of the static site generator is the ~build~ command: take some input files, process them ---render templates, convert other markup formats into HTML--- and write the output for serving to the web. <This is where I started with ~jorge~, not only because it was the fundamental feature but because I needed to see the org-mode parsing output as early as possible to know whether I could reasonably expect this project to ultimately replace my Jekyll + org-export setup.
+
+Although you could say that I had a working static site generator as soon I had the ~build~ command, for it to be minimally useful I needed some facility to preview a site while working on it: a ~serve~ command. It could be as simple as running local file server of the ~build~ output files, but ideally I would make it watch for changes and live reload the browser tabs looking at them.
+
+I was aiming for more than the basics here because ~serve~ was the only non-trivial command I had planned for: the one with the most potential to learn other Go features ---and the most fun. For similar reasons I wanted to tackle it as early as possible: since it wasn't immediately obvious how I would implement it, it was here where unknown-unknowns and blockers were most likely to come up.
+I knew it was a feasible feature because other generators have it, but I didn't want to just copy whatever Hugo or gojekyll were doing, I wanted to figure it out for myself.
+
+The beauty of the ~serve~ command was that I could start with the most naive implementation and iterate towards the ideal one, keeping a usable command at every step. With ~build~ and ~serve~ out of the way, I'd be almost done with the project, the rest being nice to have features and UX improvements.
+
+** 2. Context
+
+** 3. Implementation
+
+*** A basic file server
+
+- basic fs server implementaion
+- improve for directory and html handling
+
+*** Watching for changes
+- fsnotify to trigger builds
+- optimization: ln static files
+- optimization: worker pool
+
+*** Live reload
+
+- naive implementation
+- event broker
+  - is this name right?
+
+*** Refinements
+- don't stop on errors
+- ignore chmod and temp file events
+- delay to prevent bursts