Hanami::API
summary
Hanami::API packages a new high‑performance Ruby router into a tiny Rack framework, measuring against Roda and Sinatra with concrete numbers: initial runtime 1.11s (Roda 0.34s) and memory ~50–53MB versus Sinatra 125MB, then optimized to 0.081s and reduced boot memory from 116MB to 73MB. Speedups come from changing array→trie storage, method+path partitioning (separate fixed vs variable buckets), targeted microbenchmarks and removing shared deps, and the built app achieves the claimed lower latency and smaller footprint.
AI-written summary · about
chapters (16)
- 0:00Intro
- 1:01hanami- router in a DSL
- 2:58Low risk Hanami adoption
- 7:23JSON rendering, scopes, mounted apps, Rack
- 10:44Competition is healthy for Ruby ecosystem
- 14:24O(log n) logarithmic
- 15:03Trie based router
- 16:08The previous version used to store routes in a collection. O(n)
- 16:23Each partition has its own trie.
- 17:43Fixed vs variable paths
- 18:06Partitioned tries are only used for variable paths (e.g. /books/:id)
- 19:52Fixed paths are stored separately in a partitioned Hash.
- 22:19Micro speed enhancements
- 22:55Instance variables are faster than getters.
- 23:05Avoid each_with_object
- 26:13The present of Ruby is bright, the future is exciting.
related talks
42mHanami - New Ruby Web Framework
25mHanami - New Ruby Web Framework
51m"A year with Hanami in production: the Good, the Bad and some Recipes"
28mBetter Routing Through Trees
39mRoda: The Routing Tree Web Framework
01h 09mRails 3 ...and the real secret to high productivity
01h 07mA year with Hanami in production: the Good, the Bad and some Recipes
36mReturn To Simplicity: Architect Hypermedia REST applications using Hanami + HTMX