Over the past two years I threw myself back into full-time engineering with a simple goal: write code that gives back to the community. After a lot of late-night FOMO (“AI will do it all for us, right?”) and some painful production incidents, I finally turned my weekend project into an open-source library.
[ What is Solidis? ]
- Super-light (< 30 KB) RESP2/RESP3 client with zero runtime deps and first-class ESM/CJS support.
- Fully tree-shakable – import only the commands you need.
- Written with SOLID principles & full TypeScript typings for every command.
- Designed for cold-start sensitive serverless platforms (small bundle + tiny memory footprint).
[ Why I built it ]
1. node-redis & ioredis pain
- ESM is still an after-thought.
- Hidden deadlocks on RST, vague error surfaces.
- Everything gets bundled, even commands you’ll never call.
2. I refuse to add a dependency I don’t fully understand – I literally read candidates 10× before `npm i`.
3. Serverless bills love to remind me that every KB and millisecond matters.
[ Key features ]
- Protocols: RESP2 and RESP3 (auto-negotiation)
- Bundle size: `<30 KB` (core) / `<105 KB` (full)
- Dependencies: 0
- Extensibility: Drop-in command plugins, custom transactions
- Reliability: Auto-reconnect, per-command timeouts, type-checked replies
[ Roadmap / Help wanted ]
- Benchmarks against `node-redis` & `ioredis` (PRs welcome!)
- More first-class Valkey love
- Fuzz-testing the parser
- Docs site – the README came first; I’d love help polishing full docs
This might be my last big OSS push for a while, so stars, issues, and PRs mean the world.
If Solidis saves you some cold-start time or just scratches a TypeScript itch, let me know!
Repo: https://github.com/vcms-io/solidis
License: MIT
Thanks for reading, and happy hacking!
(Feel free to AMA in the comments – I’m around.)
badmonster•6mo ago
jayl-e-e•6mo ago
As a result, in most real-world scenarios, Solidis tends to be about 2–3x faster than ioredis (even with auto-pipelining enabled). Compared to node-redis, the performance is generally on par or slightly behind.
One caveat: if the payloads being parsed are very large, Solidis can experience increased latency due to its parser being more CPU-intensive, which may introduce delays compared to other stacks.