outline + intro for serve command post

This commit is contained in:
facundoolano 2024-03-03 16:47:47 -03:00
parent 11e4e32db8
commit af09593474

View file

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