Fermyon is proud to introduce our new lightweight WebAssembly (Wasm) content management system (CMS): Bartholomew. As we mentioned in our first blog post, the entire Fermyon.com website is served from WebAssembly modules. In this post, we talk about Bartholomew, our CMS system.
Bartholomew is built as a Wagi application, and will run inside of Hippo or inside of Krustlet if you have the Wagi extension. At Fermyon, we run ours using Hippo deploying to a Nomad cluster.
Bartholomew offers a feature set that should be familiar to users of popular static site generators like Hugo. However, Bartholomew is not a static site generator. Built into a lightweight WebAssembly module, it processes page requests individually on demand.
Bartholomew has the following features:
- Write your content in Markdown with a simple TOML header.
- Create custom templates using the popular Handlebars template language.
- Build custom template functions in the Rhai scripting language.
- Get started quickly with built-in support for Bootstrap 5.
- Generate your first Bartholomew site from our easy Bartholomew site template.
- Deliver static files with the Wagi fileserver.
- Get instant SEO optimization with dynamically generated (and easily customizable) Atom syndication, sitemap.xml, and robots.txt files.
Why Build a WebAssembly CMS?
Wasm has received a lot of attention as a potential cloud-side compute runtime. We wanted to showcase why we love WebAssembly by building a CMS system that shows off some of the cooler bits of Wasm. So we created Bartholomew.
The day we launched Fermyon, we decided that our first project would be to host our own website on our new WebAssembly stack. That gave us a feature set to target for Bartholomew’s first release.
- We wanted a system that could publish scheduled blog posts. Bartholomew can load up content with a publish date, and publish it at the precise second you want.
- We wanted a system with an easily extended template language. Bartholomew uses Rhai and Handlebars to accomplish this.
- We wanted a better system of front matter that allowed us to cleanly separate custom fields from built-in ones. Using TOML headers, Bartholomew provides an elegant way of doing this.
- We wanted to control our SEO features right from the outset. We wrote some useful Rhai scripts to help with this.
- Finally, we wanted to cut down the configurational complexity typical of site generators that support too many unnecessary features. Bartholomew let us take an minimalist (but opinionated) view.
The result: An adaptable WebAssembly CMS uses a Functions-as-a-Service model for page rendering instead of requiring the entire site to be pre-generated to static HTML.
The Functions-as-a-Service Model… for a CMS
Bartholomew is built using a Functions-as-a-Service (FaaS) model like you might find in AWS Lambda or Azure Functions. The CMS is only running when it needs to handle incoming requests. This reduces the load on our servers, which in turn reduces our long-term operating cost. Because we are using Nomad as our scheduler, we can deploy as many Wagi instances as we need, and have each running multiple applications.
But we don’t need to host these on costly VMs because we are only consuming compute resources when handling traffic. And WebAssembly has miniscule compute requirements compared to more costly containers. We are running our infrastructure on inexpensive ARM small VMs. And right now, we can run our entire website infrastructure, including the Nomad cluster, for a fraction of the cost of running a basic three-node Kubernetes cluster. This is simply because the baseline compute needs (and also storage needs) are svelte.
WebAssembly is the key technology that enables us to take this approach. Wasm modules are a fraction of a size of container images. They start and execute within milliseconds. In our own testing, we saw response times at 30-45ms. We mount a WebAssembly binary to a file system. Bartholomew loads Markdown content from the file system. And unlike traditional FaaS solutions, this entire system can easily be run on any cloud platform as well as a local developer system.
We are just getting started with Bartholomew. Because our own website runs on it, we have a vested interest in improving the project over time. And we are excited about demonstrating the potential of a WebAssembly CMS. But Bartholomew isn’t, in our minds, a “product.” Rather, it is a robust demonstration that WebAssembly on the cloud is indeed ready to build production-grade applications.