Lua application server backed by world's worst key-value store. Applications are collections of routes that look like the following:
route("balance", "json", function(args)
local account = get("acc:" .. args.id)
if not account then
return 404, { error = "account not found" }
end
return 200, { id = account.id, balance = account.balance }
end)(get/set with a string key is the only persistence mechanism). concave takes the app and runs it, making sure that each handler invocation runs in it's own transaction. Once HTTP request returns, you can be sure that your changes have made it to disk cache (i.e. they have been fsynced).
Handler execution is fully serializable thanks to optimistic concurrency control (OCC).
This is one weekend project, so don't take it too seriously. The most important thing I got out of it is that f.Sync() on MacOS will end up doing F_FULLSYNC, and you can only do about 250 of those per second (while also completely hammering your drive in the process).
- OCC conflict checks
- WAL read/write
- Transaction execution (read lock for reads, write lock at commit time)
- Bank account demo
- Reading WAL on startup
- Lua execution in transactions
- Migrate bank account demo to use Lua routes
- HTTP server exposing Lua routes
- HTML template rendering and first Lua HTML apps
- Compaction
- Augmented treaps with max on subtree
- Range queries and conflict detection
- Lifecycle callbacks (first run, subsequent runs)
- Switching away from JSONL
Since we can run world's worst TODO app as follows
go run . -wal build/todo.json -app demos/todo.lua -resources demos -addr :8080
it is only appropriate to show how the above looks in it with WAL alongside it (see http://localhost:8080/fn/view for the UI and build/todo.json for the WAL).
Not great demos/bank_stress.py gets ~3k http requests per second on Mac, though it's unclear if it's db or someone elses fault. Would be a fun project to figure out what actual performance bottlenecks in this setup are (in order of their significance).