The critical distinction of redis-objects is that it does not abstract away the atomic redis commands, which are the source of redis' power. It contrasts with ORMs where the goal is primarily convenience; with redis-objects the goal is power.
Redis is absolutely beautiful for async networking; the protocol is extremely straightforward. It has completely solved my problem of persisting data from EventMachine programs in Ruby, too.
A couple hundred lines of ObjC got a generic Redis client and a special-purpose blpop client working for my Cocoa apps (I keep libevent in a thread there).
Redis' usual mode of operation is to keep the dataset in memory, making the FusionIO SSD hardware kind of redundant. With the new diskstore back-end, though, and really fast solid state drives, I bet that Redis could be really fast with a data set much bigger than memory.
11 comments
[ 0.20 ms ] story [ 165 ms ] threadhttps://github.com/nateware/redis-objects
redis-objects is built on top of redis-rb and creates objects that are backed by redis, with operations like push, pop, etc. cleanly mapped.
In other words, it's a more ruby-like API.
I recommend reading the github README for redis-objects, it goes into a lot of depth.
Thanks for the heads up.
Edit: updated.
I started using Redis for a project with Node, and I loved the node_redis library because it's non-blocking :-)
A couple hundred lines of ObjC got a generic Redis client and a special-purpose blpop client working for my Cocoa apps (I keep libevent in a thread there).