I just published the first (v0.1.0) release of tiddly-wiki-server, which implements the TiddlyWiki WebServer API in Rust using Axum, SerDe, and TiddlyWiki.

Motivation

One might ask why a new TiddlyWiki server is necessary, since

• TiddlyWiki5 includes a first-party NodeJS web server, and
• one of TiddlyWiki's beautiful features is that it works as as static HTML file.

These are valid points. I confess, this project fulfills quite a narrow use case: I like to self-host my tools on a small, cheap VPS, and the first-party NodeJS server consumes about 100MB of RAM. This isn't huge, but it's a decent chunk of my available resources. This server consumes much less (about 10MB, and that's before I've done anything to optimize it).

This was also a project that let me combine two technologies that I like an awful lot, so if it seems self-indulgent, well... maybe it is.

Components

The server makes use of some very nice Crates; I'll mention some of the big ones:

axum, a web framework

I've tried a number of Rust web frameworks (Tide, Rocket, simple-http-server); this one's the first one I feel like I really understood and was productive with (though that might also just be that I'm slowly getting better at Rust). Of particular note is that Axum is compatible with tower-http , so many services and middlewares that you might want already exist.

rusqlite, a SQLite binding

I use SQLite for most of my tiny side projects; this one's no exception. The TiddlyWiki back end mostly treats tiddlers as opaque bags of objects, so the database is little more than a key-value store.

serde_json, a loosely-typed JSON interface

If you're reading about Rust you're probably familiar with serde, but since I wanted to retain TiddlyWiki's fairly open schema I needed an ergonomic way to work with un-typed JSON objects.

Future Work

There are lots of ways this project could be added or improved:

• More testing; I want this server to be feature-compatible with the first party server.
• User authentication and access control
• Streaming large responses to keep memory small

If any of that sounds interesting to you, pull requests and bug reports are very much welcome!