Multiplayer client-side git and further extensions

Git is more fun with friends

Multiplayer mode

While a static site sending a git commit into a repo is neat, it'd be even better if others could collaborate through this mechanism. To achieve that you'd have to use the GitHub API to check for forks and fork the repo if none exist, then send the commit there, and open a pull request.

Note that you could also achieve 'multiplayer' mode on this by adding other people as collaborators on a regular repo, or using an org repo.

You can also do multi-file commits using the commits and trees endpoints in the /repos API then sending a PATCH request to fast forward a branch. I imagine there is lots more there I haven't considered.

Applications beyond GitHub

The 'keyhole' pattern of using CloudFlare Workers as a secret-holding CORS proxy is generically useful: aside from GitHub App secrets you could keep API keys for third party services to be used in your web apps only, HuggingFace inference endpoints.

I thought about making the one Worker multifunctional, but note there's a tradeoff between not having to set up the same one multiple times and then being able to distinguish which are being used and even to shut them down discretely than if you have them serving multiple apps.

There is no tracking done in the static site demo here, but of course you could also use this to track users on web apps, or to take input from the public (as opposed to patterns like Google Forms).

If sticking with the single player 'admin' setup, you could use this for blog editing on a static site directly in the browser, which perhaps is more user-friendly to you or gives you some feature that is awkward to preview locally.

For ML model visualisations (something I personally use static sites a lot for), you could use this to persist your inputs on the fly - in other words you could store canonical examples through image uploads or text inputs from the browser, for example if you were in a company that was developing demos and wanted to have colleagues provide their suggestions for how they'd use it. I think this pattern could be really user-friendly and save much faffing around with backends for what are really trivial data transfer operations.

In a similar vein (somewhat like how people use thumbs up/down buttons), you could collect feedback on which inputs to some feature on your static site people want to see, and use that to reweight the order they're shown in, or even which is the most popular (and then default to that). It essentially makes dynamic site features feasible on static hosts.

WASM angles

You could also do more interesting things if WASM was brought into the mix, such as converting files to structured formats like Parquet and then committing those rather than plain text formats inputted by users. Rust lets you compiled to WebAssembly, you could even potentially be running client-side ML models to classify/auto-tag inputs that you then persist to the repo.

GitHub Actions as serverless compute platform

I touched on how this pattern makes GitHub Actions CI into a serverless compute platform of sorts, but only incidentally, to simply re-present the content without modification. However (subject to restrictions of the workflow compute model) it would also be possible to have the client-side commit persist something in a 'pending' state, which would prevent the GitHub Pages site from redeploying, and instead trigger some other compute operation resulting in a commit, only after which would the GitHub Pages job run again. Provided that this was permitted by the workflow model (and there are some awkward rules here that prevent runaway CI), it would potentially mean that you could use the browser input to kick off a compute pipeline but not be limited to what could be computed client-side. This could open up ways to kick off computations that are too slow for browser callbacks or allow them to be 'backgrounded' asynchronously.

Offline-first

Another angle here is the possibility to recover from loss of signal, or even to design a workflow with it in mind. In some situations, like trains going into tunnels, we might want to batch up some commits and then push them on mobile once we regain it. All this is a bit speculative, and overengineering without some real problem in mind, but with browsers' IndexedDB this wouldn't be hard to do.

Multi-branch workspaces

While so far we've assumed commits would go to the trunk branch (master/main), they could equally be set up to treat branches as separate workspaces and so provide distinct static sites to a single user or per-user (in their repos).

For blog editing, this would be a natural way to stage drafts.

Rate limits

To state another aspect which may not be common knowledge, GitHub gives you ~5,000 API calls for various parts of its API (each), which for manual operations is a lot. The more complicated you make a workflow the more likely however you might burn it up (for instance doing lots of querying as well as commits and branch juggling).

As for CloudFlare, their free tier is generous with 100k requests per day, 10ms compute time (plenty for proxying auth requests) and 3MB of memory in the 'worker' process.