Talk · Experimental
Git as a Data Store
How to stop writing servers, and why you might (not) want to. A lightning talk I gave as a senior engineer, with a demo that is deliberately a hack.
How it works
The demo is a blog with no server and no database. Three facts add up:
- isomorphic-git is git written in JavaScript, so it runs in a browser: clone, commit and push, with a virtual file system standing in for a disk.
- A website can be built from a git repo. The blog’s posts are a JSON file in that repo.
- Netlify watches the repo, and every push rebuilds and redeploys the site.
So the blog’s admin page clones its own repo into the browser, adds the new post to the JSON file, commits it and pushes. About a minute later, the rebuilt site shows the post. Writing a post is “front-end development” only.
Is this ever useful?
- Contract work: a blog or small site with only a few admins, who may even be happy editing HTML.
- Quick prototypes that need to save something, without a backend.
- A personal blog, if you don’t mind what a future employer makes of the commit history.
Why you might not want to
- Credentials in the browser. Pushing needs a GitHub token, typed into the page. Browsers can’t talk to GitHub’s git server directly, so requests go through a CORS proxy, which sees that token. Only use a fine-grained token limited to the one repo, or run your own proxy.
- Everyone writes to one file. Two admins posting at once means one push is rejected (or, with a force push, one post is lost).
- Slow writes. Each change waits for a full rebuild and deploy.
- Everything is public. Every draft and edit stays in the repo’s history.
The demo keeps its admin page so you can try it, with large warnings about these risks right above the form.
Links
- The demo blog
- Source code: fork it and try it yourself.
- The Hacker News post by Sammi that inspired it.