The Rarefied Redis Project
View the GitHub Repos
| JavaScript | rarefied-redis-js | redis-mock-js |
| Java | rarefied-redis-java | redis-mock-java |
| Python | ||
| Ruby | ||
| Go |
The purpose of this project is to provide high-quality, battle-hardened, efficient Abstractions on top of redis. redis is awesome! It's also an interesting base to build upon. Mature, scalable, easy to grok, easy to develop against, deep, and just enough features to tantalize the imagination.
This project is not intended to replace, subvert, or otherwise suggest that redis is the best tool for any given Abstraction. It is as much about finding the limits of redis as it is about providing working code.
As Programmers, our lives are about abstraction. Machine code abstracts away the electronics, languages abstract away the machine code, other languages abstract away these languages, and Theoretical Computer Science abstracts away the Computer! It's turtles all the way down.
Since this project started with ideas such as a Guaranteed Message Queue and Time Series, it seemed appropriate to think of this project as providing yet-more abstractions. In this case, Abstractions upon redis. In some cases, these Abstractions are what we might traditionally call Data Structures, but in other instances, such as a Reliable Lock, the term is not general enough.
An Abstraction is composed of two parts: its Semantics, and its Operation. Semantics are what the Abstraction means. For instance, a Reliable Lock means that one and only one requester can lock it at a time, and the lock is always unlocked. Its Operation, in contrast, is what the Abstraction does. For instance, a simple non-distributed redlock uses the redis string data type coupled with certain commands to implement Reliable Lock Semantics.
TODO: List of abstractions will go here!
A key part of the Rarefied Redis project is unit testing. However, when interacting with redis, we presume a certain service available to us with a certain version, which really stretches into the bounds of integration testing.
When beginning this project, mocking redis was used to unit test. The breadth of Rarefied Redis meant that almost all of redis had to be mocked! Not fun.
To bring some (in)sanity to this process, we began writing in-memory "mocks" that operated like a real redis instance. These mocks provide functionality to swap the regular client, e.g., node_redis, with an in-memory compatible implementation.
As we continued writing, these "mocks" morphed into something else. We could call them implementations of the redis specification. But we shouldn't, because they really aren't at this point. Perhaps one day they will be!
Each language's mock is at various stages of implementation and development. Currently, the JavaScript mock is the most complete, with the Java mock following in its heels. They are intended to be written in a pure style in each language, such that there are no external dependencies or weird version conflicts. For instance, the JavaScript mock can run on any JavaScript engine, barring perhaps some old ones.
| node_redis | Obvi! redis client for node.js |
| Redisson | Distributed and Scalable Java Data Structures |
| Jedis | Blazingly small and sane Java redis client |
@wilkenstein