Announcing New Redis Caching + Node.js Interactive Course

Redis is a popular in-memory database used for a variety of projects, like caching and rate limiting.

In this blog post, we will see how you can use Redis as an in-memory database, why you’d want to use Redis, and finally we’ll discuss a few important features of the database. Let’s start.

What is an in-memory database?

Databases like MySQL and MongoDB keep part of the database (usually the “hot” or often-accessed indices) in memory for faster access, and the rest of the database on disk.

For redis, speed is important! Therefore it focuses a lot on latency and the fast retrieval and storage of data. So it operates completely on memory (RAM) instead of storage devices (SSD/HDD).

Redis is a key-value database. But don’t let it fool you into thinking it’s a simple database. You have a lot of ways to store and retrieve those keys and values.

Why do you need Redis?

You can use Redis in a lot of ways. But there are two main reasons I can think of:

You are creating an application where you want to make your code layer stateless. Why? – Because if your code is stateless, it is horizontally scalable. Therefore, you can use Redis as a central storage system and let your code handle just the logic.
You are creating an application where multiple apps might need to share data. For example, what if somebody is trying to bruteforce your site at payments.codedamn.com, and once you detect it, you’d also like to block them at login.codedamn.com? Redis lets your multiple disconnected/loosely connected services share a common memory space.

Redis Basics

The new Redis CLI interactive course consists of the following topics:

What is Redis?
Strings and integers in redis
Key-value pairs
Sets and lists
Common operations with redis
Expiring keys
Redis single threaded
Transactions
Projects built with Redis + Node.js

You can try the course for free here.

The Redis CLI

This Redis REPL is very useful when you’re working with the database in an application and quickly need to get a peek into a few keys or the state of Redis.

Project 1 – Build an API Caching System with Redis

This project involves setting up an API caching system with Redis, where you cache results from a 3rd party server and use it for some time.

This is useful so that you are not rate limited by that third party. Also, caching improves your site’s speed, so if you implement it correctly it’s a win-win for everyone.

You can build this project interactively on codedamn inside the browser using Node.js. If you’re interested, you can try the API caching lab for free.

If you’re only interested in the solution (and not building it yourself) here’s how the core logic will work in Node.js:

app.post(‘/data’, async (req, res) => {
const repo = req.body.repo

const value = await redis.get(repo)

if (value) {
// means we got a cache hit
res.json({
status: ‘ok’,
stars: value
})

return
}

const response = await fetch(`https://api.github.com/repos/${repo}`).then((t) => t.json())

if (response.stargazers_count != undefined) {
await redis.setex(repo, 60, response.stargazers_count)
}

res.json({
status: ‘ok’,
stars: response.stargazers_count
})
})

Let’s see what’s happening here:

We try to get the repo (which is the passed repo format – facebook/react) from our Redis cache. If present, great! We return the star count from our redis cache, saving us a roundtrip to GitHub’s servers.
If we don’t find it in cache, we do a request to GitHub’s servers, and get the star count. We check if the star count is not undefined (in case a repo doesn’t exist/is private). If it has a value, we setex the value with a timeout of 60 seconds.
We set a timeout because we don’t want to serve stale values over time. This helps us refresh our star count at least once a minute.

Project 2 – Rate limiting API with Redis

This project involves rate limiting a certain endpoint to protect it from bad actors, and then blocking them from accessing that particular API.

This is very useful for login and sensitive API endpoints, where you don’t want a single person to hit your endpoint with thousands of requests.

We perform rate limiting by IP address in this lab. If you want to attempt this codelab, you can try this project for free on codedamn.

More on Redis

Redis is much more than what we have learned so far. But the good thing is that we have learned enough to start working with it already!

In this section, let’s cover a few more Redis fundamentals.

Conclusion

I hope you liked this introduction to Redis. This blog post is a part of codedamn’s new interactive course: Redis + Node.js caching, where you not only learn about these concepts, but practice them within your browser on the go.

Feel free to give the course a try and let me know what you think. You can find me on twitter to send any feedback 🙂