A tour of the Redis stars


On the Redis site is a page that lists Redis clients for various languages. It's very extensive, covering clients that work with languages as diverse as emacs lisp, GNU Prolog, Haskell and C#. Throughout the list, some clients have a star next to them and these are the current recommended clients. In this tour of the starred clients, the ones that are recommended, we're going to list them in order of language popularity using the Redmonk programming language index for June 2016.

Before we dive into the tour though, you may be wondering why having so many different clients for Redis is important. Redis can be thought of, in many cases, as the database glue that can hold many applications together. While disk-based databases are good as sources of reference, Redis shines in being a source of state and transient data for many systems. In a lot of cases, it's used as a cache, but that's just sharing state out to many other clients.

What makes Redis work is that it has so many drivers there's no application that can be considered out of the running when working with Redis. The recommended clients are the cream of the crop, the ones that have proven themselves to be stable, mature and well maintained.

Before we start though, it's worth noting there are two major styles of driver: minimalist drivers and what we call the idiomatic drivers. The minimalist drivers provide the framework to send Redis command strings and arguments and decode the Redis response. The developer using a minimalist driver will have the Redis commands documentation. The idiomatic drivers instead map the Redis command set to a richer API which exposes the Redis commands in a way that's native to the language.

So let's begin the tour with...

JavaScript/Node.js (1) - Node-Redis and ioredis

JavaScript tops the Redmonk rankings, though you'll only find JavaScript in its Node.js form in the client list. Node.js is popular with Redis client developers though; there are ten listed on the client list and two of them are recommended.

Node-redis is an idiomatic driver and claims complete coverage of the Redis command set with an entirely asynchronous set of calls. That means callbacks all round for processing results though it can be promisfied with bluebird for less indented, more predictable code flow. It also has support for server events for managing the connection and subscriber events for managing pub/sub subscriptions. Handy tricks: a built-in redis.print command you can use instead of a callback to just print results.

ioredis is another idiomatic and extensive Redis client with a similar set of features to node-redis, and more. For example, it works with Redis sentinels and clusters out of the box and supports ES6 Map and Hash types. Its support for Lua scripting includes a defineCommand call to simplify the process of uploading and storing Lua in the Redis server.

You may wonder why two clients are recommended, and it appears so do the developers who are currently, but not rapidly, working on consolidating the features of node-redis and ioredis into a single library. Which leaves the question, which to choose currently. We'd lean towards ioredis purely because it's a more recently developed codebase.

Java (2) - Jedis, lettuce and Reddison

Java, halfway house to the motto "there's more than one way to do things", has three recommended drivers, Jedis, lettuce and Redisson...

Jedis is your "small, lightweight and fast" idiomatic Redis driver. The single Jedis instance isn't thread-safe but is usable. For thread safety, you need to create a statically stored JedisPool and fill it with Jedis instances. There's no asynchronous support but there is support for sharding over multiple Redis servers.

Lettuce does claim to be thread-safe and able to service multiple threads with one connection as long as an app doesn't block the connection. It includes support for asynchronous and reactive APIs to deal with those blocking commands. It's a very idiomatic driver with a vast hierarchy of classes representing commands and results.

Redisson is probably one of the most interesting of the Java clients. It sets out to create distributed data structures and services that are backed by Redis. This means you can create a Map or Set locally that is synchronized with a Redis server without marshalling the data in and out of appropriate Java objects. With a rich set of integrations, support for many services and codecs and an Apache license, it's one to look at if you want a higher level interface. Find more at the git repository.

PHP (3) - phpredis and predis

Phpredis is a C-based extension for PHP, while Predis is a pure PHP client. Both are recommended and actively maintained. Phpredis offers better performance but usually can't be installed on hosts where the user has no shell access. Predis, as a pure PHP client doesn't have that issue, but doesn't offer the very high performance that phpredis could offer. That said, many applications don't need that high a level of performance.

Python (4) - redis-py

Pythonic access to Redis is but a "pip install redis" away with redis-py. It's notable for its extensive Readme.rst file which makes you aware of all the deviations from the Redis commands and is explicit over thread-safety issues and other pitfalls you could run into with the library.

C# (5) - ServiceStack.Redis and StackExchange.Redis

ServiceStack.Redis is a recommended driver, but that could well change as the most recent version, v4, is now a commercial product with a free tier and after hitting 6000 Redis requests in an hour (or other limitations), it will start generating exceptions requiring an upgrade. If you are in the market for a commercially supported Redis driver for C#, check it out, otherwise, your next stop is ...

StackExchange.Redis was developed by StackExchange as a "logical successor" to an earlier driver called BookSleeve, StackExchange.Redis is an MIT-licensed driver which includes support for clusters, shared connections and coverage of the full redis feature set. With regular updates and a range of programming models, it's the more recommendable recommended driver for C#.

Ruby (5) - Redis-rb

Redis-rb is exactly what you expect from the Ruby community - a one-to-one idiomatic mapping of Redis functionality which maintains Ruby's idioms and pragmatism. Redis-rb is all Ruby using Ruby's socket library for connections, but can also be setup to use the hiredis C driver (see the next entry) for better performance with large objects.

C (9) - Hiredis

If you positively have to code in C and want the best performance from your driver, then hiredis is the foundation you are going to want to build on. Surprisingly, it's still yet to release a 1.0.0 version and the last release was a year ago. That said, as minimalist driver, it abstracts Redis communications as a redisCommand() call passing the actual command in a string so Redis command additions don't require changes to hiredis.

Perl (13) - Redis

There are a lot of Perl Redis clients with different objectives, as befits the language built around there being "more than one way to do it", but there's only one recommended Perl client and that's Redis. If you dig into the docs, you'll find a client that idiomatically exposes the Redis API, up to but not including Redis 3.2 features. There are also modules to tie Redis Hashes and Lists into Perl Hashes and Arrays and offer sentinel support.

Go (15) - Radix and Redigo (and go-redis)

Go is a rapidly moving ecosystem and there's an interesting mix of drivers out there. Radix is an example of the minimalist style of driver, with a non-thread-safe Redis connection which can be made safer with its own pool, sentinel and cluster implementations. Redigo is the other recommended driver, and that also offers a minimalist driver with similar features - external projects that offer the sentinel and cluster clients support.

Oddly, there's no recommended idiomatic driver, so allow us to informally recommend go-redis. It's an actively developed driver with cluster and sentinel support and has interesting additional features like rate limiting and distributed locking.

Haskell (16) - hedis

For Haskell developers, there's only one recommended and actively maintained Redis client and that's hedis. The documentation has it as a full idiomatic driver for the Redis 2.6 command set though there are at least some commands from later Redis versions implemented. It also exposes its low level API giving the user the flexibility of a minimalist driver.

Clojure (20) - carmine

Clojure developers have one choice in Redis client support and that's carmine. It's another rich idiomatic driver with support for 2.6 and later features and adds its own capabilities such as distributed locks, raw binary handling and easy message queues. Redis commands are exposed as Clojure functions, and - here's the neat part - generated by using the official Redis command reference so it's always up to date and documented.

We run out of Redmonk ratings - they reasonably stop at 21 places (after ties), but there are still more recommended clients. Switching to alphabetical order we have:

Crystal (-) and crystal-redis

For Crystal developers, the crystal-redis package is the only option we know of. It has an idiomatic style API which appears to be up to but not including Redis 3.0.

Dart (-) and DartRedisClient

The DartRedisClient seems to have stalled in development. As a Redis client for Dart, Google's JavaScript alternative, the library reached a version 0.1 last year and there have been no commits since. That said, the 0.1 version offers an idiomatic API which returns Futures for async/non-blocking functionality.

Erlang (-) and Eredis

Erlang developers are recommended Eredis which is a minimalist non-blocking library, with support for pipelining and auto-reconnection, but no support for sentinels or clustering.

Lua (-) and Redis-lua

The Redis-lua library has support for commands up to, and including, Redis 2.6 in an idiomatic API but hasn't been updated since 2014.

Rust (-) and Redis-rs

The Rust libraray for Redis, Redis-rs, is being actively developed and strikes a half-way house between idiomatic and minimalist - there is some high-level functionality but it's only for commonly used features, but developers are free to fall back to using the low-level API to construct any Redis commands they wish. There are also features limited by what's currently implemented in the languge - these are detailed in the documentation.

Scala (-) and Scala-redis

The scala-redis library is actively being developed and its more recent work has brought support for Redis 3.2's GEO commands among other things. It works with native Scala types and is not a wrapper around a Java client. It's a blocking client but has a pool and asynchronous futures built on top of that. And it's idiomatic. Scala developers are not short of Redis client alternatives, but scala-redis seems to cover most core requirements.

And there the tour ends

Hopefully, you'll come away with a good feeling about the range of languages covered by the Redis community's driver work. From strictly minimalist drivers that cover the protocol with a thin veneer of essential code, to rich idiomatic libraries designed to make Redis a natural fit to the language in use, there's a lot of ground that is covered. Remember, we've only touched all too briefly on the recommended drivers and there's a whole lot more that are not recommended but worth investigating. We'll be taking a deep dive on some of these Redis libraries in the future.

We invite anyone who is knowledgable about a Redis driver to check out our Write Stuff page where you can earn cash and database credits.

If you have any feedback about this or any other Compose article, drop the Compose Articles team a line at articles@compose.com. We're happy to hear from you.

Image by ESO.org
Dj Walker-Morgan
Dj Walker-Morgan is Compose's resident Content Curator, and has been both a developer and writer since Apples came in II flavors and Commodores had Pets. Love this article? Head over to Dj Walker-Morgan’s author page to keep reading.

Conquer the Data Layer

Spend your time developing apps, not managing databases.