Redis is No Longer Open Source 🚫

Redis, now owned by a commercial company, has undergone a transformation in its licensing terms. As it turns out, within its source code lay contributions from the open-source community.

Overnight, this source code found itself under the control of a company that now solely exploits it for its own ends.

The issue here isn’t about a company trying to make money — after all, as a developer myself, I understand the need to monetize work that has required significant design and implementation efforts. But when people volunteer their time for years to advance a project, appropriating their work freely amounts to theft.

The open-source community wasted no time in rallying together.

The Birth of the Redict Project 🚀

Redict, short for REmote DICTionary, has been created under the LGPL 3.0 license by the open-source community.

I’m intimately familiar with the Redis project. Many of my projects rely on it, and even my blog leans on Redis. I’ll be transitioning to Redict as soon as possible, and the goal of this article is to explore if there’s a way to replace this service with minimal effort.

In this article, we’ll install Redict via Docker, then conduct a simple read and write test. Finally, I’ll conduct a local test of the blog engine to see if Redict is fully compatible with more complex operations (such as key patterns, etc.).

Installing Redict via Docker 🐳

I’ll create a directory called redict-test, and in a file named docker-compose.yml:

#version: "3.1"
services:
  db:
    image: registry.redict.io/redict
    restart: always
    ports:
      - 6379:6379

Once the file is created, we can launch the service:

sudo docker compose up -d

We can check its status in real-time:

sudo watch docker compose ps

Testing Redict with Node.js 🧪

We’ll create a simple project in Node.js Typescript (I no longer do JavaScript, but don’t worry, it’s just as straightforward. Follow along!).

Creating a package.json and adding dependencies:

yarn init

yarn add redis
yarn add typescript @types/node ts-node -D

Now, we can create a file, index.ts:

import { createClient } from 'redis';

(async () => {
  const client = await createClient({
    url: "redis://127.0.0.1:6379",
  })
    .on("error", (err) => console.log("Redis Client Error", err))
    .connect();
  await client.set("key", `value ${Date.now()}`);
  const value = await client.get("key");
  console.log(value);
  await client.disconnect();
})();

To run, we simply need to enter:

npx ts-node index.ts

We should get the following result:

value 1712480118619

Victory! 🎉🎉

I should mention that at any time, we can use redis-cli as we normally would with Redis.

Since everything seems to work for such a simple need, let’s try to address a more complex requirement.

Putting the Blog’s Cache Lifecycle on Redict 🔁

I set up my blog locally with a dump of online articles.

We don’t need to make any changes to the libraries or even the environment variables.

I launch a monitor on a redis-cli that connects to the Redict server, and here’s what happens as I navigate through the site:

Everything seems to function identically. I believe we’ve succeeded! 🥳

All that’s left is to launch the project into production. 🚀