Most Redis tutorials teach you commands. Few show you what those commands
actually do to the data structures underneath. I kept finding myself
running redis-cli, guessing at internal state and cross-referencing
documentation to confirm what I thought just happened.
So I built Redis State Explorer (RSE). It is a web-based lab where you run real Redis commands and watch the actual state change in front of you. Lists, hashes, sets; all rendered as their real structure, not just text output.
It's completely free, open source and live at https://redislab.vercel.app/
The problems that I kept running into
Redis's data model is simple to explain and surprisingly easy to misjudge in actual practice.
SADD-ing the same value three times silently succeeds every time, but
the set only grows by one member. No error, no warning. You have to
just already know that Sets work this way.A
WRONGTYPEerror tells you that something went wrong. It is never obvious why, especially if you're newer to Redis's strict per key typing model.
All of this is documented. It is the kind of thing that's much
faster to realise by watching it happen rather than reading about it.
What does RSE do?
Three pieces:
A live terminal & state panel. Type a command, watch the keyspace update in real time, with type-aware cards for Strings, Lists, Hashes, Sets, with TTL.
A structure visualizer. The same data rendered as an actual diagram. list nodes connected with HEAD/TAIL markers, hash field/value tables, set
pill collections.
In short, you can see roughly where time is going.
Ten guided experiments. Each one is a question, not an instruction with a hypothesis you test by running real commands.
The idea is much closer to a lab notebook than a tutorial.
Some technical decisions worth mentioning
2-second backend polling & 1-second client-side TTL interpolation. The
backend doesn't push updates. The frontend polls /state every 2 seconds.
But a TTL counting down in 2-second jumps looks broken, so the frontend
interpolates the displayed countdown every second locally, using the
timestamp of the last real fetch. Smooth countdown, no extra network traffic.
Completely Plain CSS, no Tailwind. The whole UI follows a specific dark, systemic design language with tight tonal layering.
I found handwritten CSS with consistent naming more predictable for this than composing utility classes for something this opinionated. This isn't a general recommendation, its just what worked here.
Not built yet (genuinely, not just modesty)
Pub/Sub and Streams visualization.
Bring_your_own_redis (currently it's only wired to one fixed instance. It can't point it at your own Redis Cloud/Enterprise instance yet, which is something a couple of people have already asked for).
A real mobile-responsive layout (the landing page works fine on mobile,
the actual lab is a desktop tool right now).Docker setup for easier local dev.
All tracked in the repo's ROADMAP.md and genuinely open for contribution.
Try it
Live: https://redislab.vercel.app/
Source: https://github.com/ps-aditya/Redis-State-Explorer
License: MIT, and it'll stay that way.
If you build something with Redis professionally and something in RSE looks wrong, or you've got an experiment idea that should exist and doesn't, please open an issue. That feedback loop is the actual point of putting this out there.
