It's a practical tutorial that will provide you with everything you need to understand how require() works and how to use it efficiently. It includes detailed instructions and code examples that you can run either locally on your computer or in a prepared online Node environment to quickly get the hang of it. And there will be practical exercises waiting for you at the end of this tutorial.

It's part of my tutorialhell.dev project, aimed at helping beginners learn easily without getting stuck.

In Node.js, a module is a self-contained block of code that doesn't affect other code. JavaScript files are treated as modules in Node.js, where you can export functions, objects, or values from one file and use them in another.

Node.js supports two module systems: CommonJS modules and ECMAScript modules.

• The CommonJS modules were the original method for packaging JavaScript code in Node.js.

• The ECMAScript modules standard is utilized by browsers and other JavaScript runtimes and is generally viewed as the preferred approach for being future-proof. However, to get started, we will focus on CommonJS modules since they are still widely used. As we progress, I will introduce you to ECMAScript modules in the upcoming tutorials.

Let's break down the basics, starting with how to create a module in Node.js, how to export from it, and how to use the exported entities in other files.

If you don't have Node.js set up, you can get started using a ready-made Node.js environment in this sandbox.

Creating a Simple Module

Create a File: Every module is a JavaScript file. Create a file named 'myModule.js'.

Write Some Code: Inside 'myModule.js', define a function that you want to make available outside this file.

function sayHello(name) {
  return `Hello, ${name}!`;
}

Exporting from a Module

To make functions, objects, or values available outside the module where they are defined, you need to export them using module.exports.

module.exports is an object included in every JavaScript file in Node.js by default. It is used to export functions, objects, or values from a module. Here is the full code:

function sayHello(name) {
  return `Hello, ${name}!`;
}
module.exports = sayHello;

Importing a Module

To use the exported entities from a module in another file, you need to require that module.

Create Another File: 'index.js'. (It's already there if you are using the sandbox. Simply replace the contents with the code provided below.)

Require the Module: Use the require() function to import the module, passing the path to the module file as an argument:

const sayHello = require('./myModule');
console.log(sayHello('World')); // Outputs: Hello, World!

Explanation:

require('./myModule'): This line imports the module myModule.js. The ./ indicates that the file is located in the same directory as index.js. Node.js reads myModule.js, executes it, and then module.exports from myModule.js is returned by require() and assigned to the variable sayHello in index.js.

sayHello('World'): This line calls the imported function with the argument 'World', and the function returns the string 'Hello, World!'.

Multiple exports

To perform multiple exports from a Node.js module, you can use either the module.exports object or the exports shorthand. Each approach allows you to export multiple items, such as functions, objects, or values, from a single module. Here's how you can do it:

1. Using module.exports

You can directly assign an object to module.exports containing all the items you want to export. This approach is useful when you want to structure your exports clearly in one place. Create a 'multipleExport1.js' and paste the following code there:

function func1() {
  console.log('Function 1');
}

function func2() {
  console.log('Function 2');
}

module.exports = {
  func1,
  func2,
};

1. Using exports

The exports shorthand allows you to attach exports directly to the exports object. This is syntactically more concise for exporting multiple items. Create a 'multipleExport2.js' and paste the following code there:

exports.func3 = function () {
  console.log('Function 3');
};

exports.func4 = function () {
  console.log('Function 4');
};

Multiple imports

Similarly, you would import these in another file like this:

const myModule = require('./multipleExport1');
const myModule2 = require('./multipleExport2');

Or, using destructuring:

const { func1, func2 } = require('./multipleExport1');
const { func3, func4 } = require('./multipleExport2');

Replace the contents of the 'index.js' file with this code:

const sayHello = require('./myModule');
console.log(sayHello('World')); // Outputs: Hello, World!

// Approach 1
console.log('------- Approach 1 -------');
const myModule = require('./multipleExport1');
const myModule2 = require('./multipleExport2');

myModule.func1(); // Calls 'Function 1'
myModule.func2(); // Calls 'Function 2'

myModule2.func3(); // Calls 'Function 3'
myModule2.func4(); // Calls 'Function 4'

// Approach 2
console.log('------- Approach 2 -------');
const { func1, func2 } = require('./multipleExport1');
const { func3, func4 } = require('./multipleExport2');

func1(); // Calls 'Function 1'
func2(); // Calls 'Function 2'
func3(); // Calls 'Function 3'
func4(); // Calls 'Function 4'

And you should see the following logged in your terminal:

You might have noticed that when functions are imported through destructuring, they are assigned unique identifiers like func1, func2, etc. This uniqueness is necessary because two functions with the same name cannot coexist in the same file (module). It requires us to use unique names in different modules, which is not convenient.

However, there is a technique to rename these functions while importing them. This allows functions to have identical names across multiple modules and be renamed when imported into the same file to avoid name collisions. Here is how you do it:

Create a new file named 'multipleExport3.js' and paste the following code there:

exports.func3 = function () {
  console.log('Function 3 with an identical name from a different module');
};

exports.func4 = function () {
  console.log('Function 4 with an identical name from a different module');
};

Then add this code to the bottom of your 'index.js' file:

const {
  func3: renamedFunc3,
  func4: renamedFunc4,
} = require('./multipleExport3');
console.log('------- Destructuring with Renaming -------');
renamedFunc3();
renamedFunc4();

And your updated terminal output will look like this:

👉 Working code you can find here.

Choosing Between module.exports and exports

Use module.exports when you want to export a single item, like a function or an object, or when you prefer to define all exports at once in an object.

Use exports to attach multiple exports individually. This can be more straightforward when exporting several items but remember that you cannot assign directly to exports as it will break the reference to module.exports. For example, doing exports = { func1, func2 } will not work as expected.

Both methods are commonly used and choosing between them often comes down to preference and the specific needs of your module.

Here’s a breakdown of the key feature that every beginner should grasp:

require() is Synchronous and Caches Modules

Synchronous Loading: When you use require() to import a module, Node.js reads and executes the entire module file synchronously. This means that Node.js will halt the execution of your code until the entire module is loaded. This behaviour is particularly important to understand because it affects how and where you use require() in your application. Here's a simple code example to demonstrate that require() is synchronous in Node.js, meaning Node.js waits for the module to be fully loaded and executed before moving on to the next line of code.

Or try it out yourself by pasting the following code in the sandbox.

Create a file named 'greet.js' and paste the following code there:

console.log('Loading greet.js...');

function greet() {
  console.log(
    'Hello and welcome to learning web development with www.tutorialhell.dev!'
  );
}

console.log('greet.js loaded successfully.');

module.exports = greet;

Create or update (it's already there in the sandbox) the 'index.js' file and paste the following code there:

console.log('Starting index.js...');

const greet = require('./greet'); // Synchronously loads and executes "greet.js"

console.log('greet.js has been required.');

greet();

console.log('Ending index.js...');

How it works: When you run 'index.js' using the command node index.js, you will see the logs in the following order, demonstrating the synchronous nature of require():

Notice how the execution of 'index.js' pauses until 'greet.js' is fully loaded and executed (evidenced by the logs from 'greet.js' appearing before the continuation of 'index.js').

In simple terms, synchronous means doing things one by one in order, where you have to finish one thing before you can start the next thing.

Caching Mechanism: Node.js caches the first instance of each module you require. If you require() the same module multiple times in different parts of your application, Node.js will not reload or re-execute the module file after the first time it's loaded. Instead, it reuses the cached version. This caching mechanism improves performance by avoiding the overhead of loading and compiling the module's code multiple times. However, it also means that any state maintained in the module is shared across all parts of your application that import it.

In simple terms, caching means storing something in a place where it can be quickly accessed later. It's like saving a shortcut to find information faster without having to go through the whole search process again.

Why It Matters

Performance Implications: Knowing that require() is synchronous helps in structuring your code for optimal performance, especially during the startup phase of an application. It encourages the practice of requiring modules at the beginning of files or in sections of the code where blocking the event loop has minimal impact on the application's responsiveness.

Understanding JavaScript's synchronous, single-threaded nature is key in Node.js to avoid blocking code. Node.js uses techniques like callbacks, promises, and async/await to enable asynchronous operations, preventing the event loop from being blocked. These methods allow Node.js applications to remain efficient and responsive, handling tasks in the background without slowing down the main execution flow.

Single-threaded means that a program or environment, like JavaScript in Node.js, can only execute one operation at a time on a single path of execution. Imagine it as a single-lane road where cars (operations) must go one after another, not side by side. This setup ensures that operations are carried out in sequence, but it also means that one operation must complete before the next one starts, preventing simultaneous execution of multiple operations.

Module State Sharing: Awareness of the caching mechanism is important when designing modules. Since the same instance of a module is shared wherever it's required, any state stored in the module is also shared. This can be leveraged to maintain application-wide state but requires careful management to avoid unintended side effects.

In programming, "state" refers to the current condition or data held by an application or a module at any given time. It's like remembering the score while playing a game; just as the score tells you how well you're doing at that moment, the state in programming keeps track of information like what's been clicked, entered into forms, or saved temporarily as the program runs. This state can change based on what actions are taken within the application, just like the game score changes when you score points or lose points.

It's important to distinguish this concept of "state" from a database (DB). While a database can store data that might represent part of an application's state, such as user profiles or application settings, the "state" in the context of programming generally refers to the in-memory condition of an application at a specific moment. This includes data that the application is currently working with but hasn't necessarily saved to a database.

Debugging: Understanding how require() works can aid in debugging issues related to module loading, such as why changes to a module don't seem to take effect (due to caching) or why an application may be blocking at startup (due to synchronous loading of modules).

Practical Exercises

To reinforce your understanding of the require() functionality and the caching mechanism, I recommend practising. Here is the Node.js sandbox, in case you need it..

Objective:

Your task is to create a simple Node.js application that demonstrates how the state is shared and managed across modules due to Node.js's caching mechanism. You will create a shared state module and two additional modules that modify and display the shared state, respectively.

Instructions:

1. Create the Shared State Module:

• File Name: 'counterState.js'

• Task: This module will maintain a counter. Write two functions within this module: one named incrementCounter to increment the counter and another named getCounter to retrieve the counter value. Export both functions.

The counter code will look something like this:

let count = 0;

function incrementCounter() {
  count++;
}

function getCounter() {
  return count;
}

module.exports = { incrementCounter, getCounter };

2. Create the First Additional Module:

• File Name: 'incrementModule.js'

• Task: This module will require 'counterState.js' and use its incrementCounter function to increment the counter, and the getCounter function to display the counter's current value. It should then log a message showing the new counter value. Export a function named increment that performs these tasks. You need to write this code yourself.

3. Create the Second Additional Module:

• File Name: 'displayModule.js'

• Task: This module will also require 'counterState.js' but will only use the getCounter function to display the current value of the counter. Export a function named display that logs the counter's current value. You need to write this code yourself.

4. Create the Entry Point File:

• File Name: 'index.js'

• Task: In this file, you will require both 'incrementModule.js' and 'displayModule.js'. Use their exported functions to increment the counter and display its value, demonstrating the shared state across modules. You need to write this code yourself.

• Instructions: Increment the counter, display its value, and then increment it again to show the shared and persistent state. Then display the value again to see how it updates in the other file (module) that requires the 'counterState.js' module.

The working code should log the following:

By completing this homework, you will understand how Node.js caches imported modules, allowing shared state between different parts of your application. This knowledge is fundamental for efficient Node.js development, especially for applications relying on shared data across modules.

Here are the solutions to the above practical exercises.

Transferable Knowledge and Patterns

• Understanding of Synchronous Operations: Recognising that require() operates synchronously, halting execution until a module is fully loaded, teaches the general principle of synchronous execution in programming. This concept is critical for understanding how different parts of a program can affect execution flow and performance, applicable in various programming languages and environments.

• Importance of Caching for Performance: The caching mechanism of require() illustrates a fundamental performance optimisation technique used widely in computing. Caching, or temporarily storing data for quick access upon repeated requests, is a concept that can be applied in numerous scenarios beyond module loading, such as web content delivery, database queries, and more.

• Module State Sharing and Global State Management: The idea that a module's state is shared across all parts of an application that import it underscores the broader concept of global state management. This is a key consideration in software design, relevant for understanding how state is managed across an application.

• Performance Optimisation Practices: The advice to require modules at the beginning of files or in strategic code sections to minimise performance impact teaches a broader lesson on resource management and optimisation in software development. Prioritising resource-intensive operations and understanding their impact on the application's responsiveness and efficiency are valuable skills.

• Debugging and Troubleshooting: The emphasis on how understanding require()'s behaviour aids in debugging extends to a general principle in programming: knowing how your tools and frameworks work under the hood can significantly improve your ability to troubleshoot and solve problems. This is a critical skill for any developer, as it applies to debugging in all programming languages and environments.

That said, understanding how to import modules in Node.js opens up a wealth of critical knowledge that you will learn once and use everywhere. It shows you how to avoid getting stuck.

You are more than welcome to explore these topics independently because it’s the best way to develop problem-solving skills. But keep in mind that we will gradually cover all these topics through my tutorials because that’s why tutorialhell.dev was created.

Learning path from here:

The concepts mentioned in the examples, such as function definitions, template literals, and destructuring, are frequently used, and thus I strongly encourage you to engage in some self-learning as well. Yes, to develop problem-solving skills. I cannot emphasize this enough.

• Introduction to Objects: Learn about JavaScript objects, including creation, access, methods, property shorthand and computed properties.

• Function Definitions: Explore different ways to define functions, including function declarations, function expressions, and arrow functions.

• Template Literals: Learn about string interpolation and multi-line strings in ES6, using backticks to define template literals and ${} for embedding expressions.

• Destructuring: Understand the destructuring assignment syntax for arrays and objects.

• File Paths: Learn about relative and absolute file paths to grasp how to navigate and reference files within your projects effectively.

If you like this content, consider following me and subscribing to receive these cool tutorials as soon as they are ready.

The sunfish on the post cover was sourced from the O'Rly Generator.

In practice, the choice of a database often depends on the application’s data-access patterns as well as the current and possible future requirements.

Redis was a perfect database for a Q&A board. I described how I took advantage of sorted sets and hashes data types to build features efficiently with less code.

Now I need to extend the Q&A board with registration/login functionality.

I will use Redis again. There are two reasons for that.

Firstly, I want to avoid the extra complexity that comes with adding yet another database.

Secondly, based on the requirements that I have, Redis is suitable for the task.

Important to note, that user registration and login is not always about only email and password handling. Users may have a lot of relations with other data which can grow complex over time.

Despite Redis being suitable for my task, it may not be a good choice for other projects.

Always define what data structure you need now and may need in the future to pick the right database.

Implementation

I use serverless functions, the ioredis library and Upstash Serverless Redis.

I can’t help but talk about serverless all the time because it greatly simplifies development. I love when complexity is removed whenever possible and Upstash is doing just that for me.

I have zero work with setting up Redis. Moreover, I am using Upstash both in development and production.

Registration flow

During registration, we collect the user name, email and password. Before registering a user, we need to make sure that the email has not been registered already (is unique in the system).

Redis does not support constraints. However, we can keep track of all registered emails using a sorted set named emails.

On every new registration, we can use the ZSCORE command to check whether the provided email is already registered.

If the email is taken, we need to notify the user about it.

⚠️ Note, that this isn’t the best option because by telling that a given email is registered we provide a simple way for anyone to check whether someone is registered with a particular service, albeit it’s not a big security issue.

Before we can save a new user, we need to:

• Generate a unique user ID.

We can use the INCR command to always get a unique value by incrementing a number stored at a key by one. If the key does not exist, Redis will set it to 0 before performing the operation. This means that the initial value will be 1.

const id = await redis.incr('user_ids') // -> 1

Whenever you need to create a counter, INCR is a great choice. Or you can build a rate-limiter to protect your API from being overwhelmed by using INCR together with EXPIRE.

• Hash the password with the bcrypt library.

const hash = await bcrypt.hash(password, 10)

Now that we have the unique user ID (e.g. user ID is 7) and the hashed password, we can: 1. Store user details in a hash under the user:{ID} key.

redis.hmset('user:7', { 7, name, email, hash })

Knowing the ID, we can easily get all user details using the HGETALL command:

redis.hgetall('user:7');

2. Add the user’s email to the emails sorted set.

redis.zadd('emails', -Math.abs(7), email)

This allows us to lookup emails to check if they are registered or get the user's ID by email which is exactly what we need for the login process.

redis.zscore('emails', email) will return the score which is the ID or nil if the email is not found.

Notice how we use this sorted set for two important features, namely ensuring unique emails and looking up users by email.

But we are taking it one step further and set scores (which represent user IDs) as negative numbers to mark emails as unverified: -Math.abs(7). Then, when the email is verified, we simply convert it to a positive number.

redis.zadd('emails', Math.abs(7), email)

If a specified email is already a member of the emails sorted set, Redis will update the score only.

During the login process, we can always check for negative numbers and request users to verify their email instead of logging them in.

Retrieving all unverified emails is a trivial operation done with the ZRANGEBYSCORE command.

redis.zrangebyscore('emails', '-inf', -1, 'WITHSCORES');

Registration function source code

Login flow

Before logging in the user, we check if the provided email exists in our database. As mentioned before, the score is the user ID.

const userId = await redis.zscore('emails', email);

If so, we first check if the email is verified by making sure the ID is a positive number. If not, we ask users to verify their email.

If the email is verified, we get the password hash that we stored for the user:

const hash = await redis.hget('user:7', 'hash');

and check whether the password is correct:

const match = await bcrypt.compare(password, hash);

If the password is correct, we generate a token and return it to the client.

And we are done.

Login function source code

Conclusion

As you can see, we needed four Redis commands for registration and only two for login.

Probably you noticed that while describing the registration and login process with Redis we also revealed two more use cases for Redis, namely counter and rate-limiting.

Redis has a lot more use cases beyond cache and learning about them will only make you even more efficient.

Follow me to read about how I am implementing a secure production-ready registration flow with email verification and password recovery backed by Redis.

Check out my article on how I implemented the LinkedIn-like reactions with Serverless Redis.

Most people do not even consider Redis as a primary database. There are a lot of use cases where Redis is a perfect choice for non-cache related tasks.

In this article, I will demonstrate how I built a fully functional Q&A board for asking and upvoting the most interesting questions. Redis will be used as a primary database.

I will use Gatsby (React), Netlify serverless functions and Upstash Serverless Redis.

Upstash has been a good choice so far and I decided to try it out in a more serious project. I love everything serverless and how it makes things simpler for me.

Serverless will be a great choice for most tasks however you need to know the pros and cons of the tech you are using. I encourage you to learn more about serverless to get the most out of it.

Q&A board features

As you may know, I run a tech newsletter for recruiters where I explain complex tech in simple terms. I have an idea to collect questions from recruiters using a Q&A board and let them vote for questions.

All questions will eventually be answered in my newsletter, however, the most upvoted questions will be addressed first.

Anyone can upvote a question and registration is not required.

Questions will be listed in three tabs:

• Active - questions sorted by votes and available for voting.
• Most recent - questions sorted by date (newest first).
• Answered - only questions that have answers.

Upvoting will be one of the most frequently used features and Redis has a data type and optimized commands for it.

A Sorted set is ideal for this task because all its members are automatically sorted by the score.

Scores are numeric values that we will associate with votes. It is very easy to increment a score (add a vote) by using the ZINCRBY command.

We will also leverage scores for handling unmoderated questions by setting the score for them to 0. All approved questions will have a score of 1+.

It allows us to fetch all unmoderated questions by simply using the ZRANGEBYSCORE command specifying the min and max arguments as 0.

To fetch all approved questions sorted by the score (highest first) we can use the ZREVRANGEBYSCORE command setting the min score argument to 1.

This is great that by using just a few Redis commands we can also solve logical tasks along the way. Lower complexity is a huge benefit.

We will also use sorted sets for sorting questions by date or filtering questions that have answers. I will explain it in more detail in a moment.

Less frequent operations, namely creating, updating and deleting questions are also easy to accomplish using hashes.

Implementation details

The most interesting part is always the actual implementation. I use serverless functions and the ioredis library and I will link the source code explaining what it does.

This article is dedicated to client-facing functionality. Although I will explain admin-related functions, in the final source code there will be no backend interface. You will need to use Postman or a similar tool to call the admin related endpoints.

Let’s take a look at the API endpoints and what they do.

Add a question

Users can create questions. All questions require moderation before they become visible.

A question is an object and Redis hash is a perfect data type to represent objects.

This is the structure of a questions: {"datetime":"1633992009", "question":"What are Frontend technologies?", "author":"Alex", "email":"alex@email.com", “score:” “0”, “url”: “www.answer.com” }

We will store questions in hashes using the HMSET command which takes a key and multiple key-value pairs.

The key schema is question:{ID} where ID is the question ID generated using the uuid library.

This is a new question and there is no answer yet. We skip the url property but it will be an easy task to add it later using the HSET command.

The score for a newly created question is 0 by default. By our design, it means that this question needs moderation and will not be listed because we only fetch questions with scores starting from 1.

Since we keep the score value in a hash, we’ll need to update it whenever it changes. There is a HINCRBY command that we can use to easily increment values in hashes.

As you can see, using Redis hashes solves a lot more for us than just storing data.

Now that we know how we’ll store questions, we also need to keep track of questions to be able to fetch them later.

For that, we add the ID of a question to a sorted set with a score of 0 using the ZADD command. A sorted set will allow us to fetch question IDs sorted by scores.

As you can see, we are setting the score to 0 just like we do it for the score property in the hash above. The reason why we duplicate the score in a hash is that we need it when showing the most recent questions or questions that have answers.

For instance, the most recent questions are stored in a separate sorted set with timestamp as a score hence the original score value is not available unless it’s duplicated in a hash.

Since we store the score in two places, we need to make sure that values are updated both in a hash and in a sorted set. We use the MULTI command to execute commands in a manner where either all commands are executed successfully or they are rolled back. Check Redis Transactions for more details.

We will use this approach where applicable. For example, HMSET and ZADD will also be executed in a transaction (see source code below).

ZADD command takes a key and our schema for it is questions:{boardID}

All questions are mapped to a boardID. For now, it’s a hardcoded value because I need one board only. In the future, I may decide to introduce more boards, for example, separately for Frontend, Backend, QA and so on. It’s good to have the needed structure in place.

Endpoint: POST /api/create_question

Here is the source code for the create_question serverless function.

Approve a question

Before a question becomes available for voting, it needs to be approved. Approving a question means the following:

1. Update the score value in hash from 0 to 1 using HINCRBY command.
2. Update the score value in the questions:{boardID} sorted set from 0 to 1 using the ZADD command.
3. Add the question ID to the questions:{boardID}:time sorted set with the timestamp as the score to fetch questions sorted by date (most recent questions) using the same ZADD command.

We can get the timestamp by looking up the question by its ID using the HGET command.

Once we have it, we can execute the remaining three commands in a transaction. This will ensure that the score value is identical in the hash and the sorted set.

To fetch all unapproved questions the ZRANGEBYSCORE command is used with the min and max values as 0.

ZRANGEBYSCORE returns elements ordered by a score from low to high while ZREVRANGEBYSCORE - from high to low. We’ll use the latter to fetch questions ordered by the number of votes.

Endpoint for fetching all unapproved questions: GET /api/questions_unapproved

Endpoint for approving a question: PUT: /api/question_approve

Here is the source code for the questions_unapproved serverless function. For the most part, this code is similar to other GET endpoints and I will explain it in the next section.

Here is the source code for the question_approve serverless function.

Fetch approved questions

To fetch all approved questions we use the ZREVRANGEBYSCORE command setting the min argument to 1 in order to skip all unapproved questions.

As a result, we get a list of IDs only. We will need to iterate over them to fetch question details using the HGETALL command.

Depending on the number of questions fetched, this approach can become expensive and block the event loop in Node (I am using Node.js). There are a few ways to mitigate this potential problem.

For example, we can use ZREVRANGEBYSCORE with the optional LIMIT argument to only get a range of elements. However, if the offset is large, it can add up to O(N) time complexity.

Or we can use a Lua script to extend Redis by adding a custom command to fetch question details based on IDs from a stored set without us doing it manually in the application layer.

In my opinion, it would be overhead in this case. Besides that, one must be very careful with Lua scripts because they block Redis and you can’t do expensive tasks with them without introducing performance degradation. This approach may be cleaner however we would still use the LIMIT to avoid large amounts of data.

Always research the pros and cons before the final implementation. As long as you understand the potential issues and have evaluated ways to mitigate them, you are safe.

In my case, I know that it will take significant time before I will have enough questions to face this issue. No need for premature optimization.

Endpoint: GET /api/questions

Here is the source code for the questions serverless function.

Vote for a question

The process of upvoting a question consists of two important steps that both need to be executed as a transaction.

However, before manipulating the score, we need to check if this question has no answer (url property). In other words, we do not allow anyone to vote for questions that have been answered.

The vote button is disabled for such questions. But we do not trust anyone on the internet and therefore check on the server if a given ID exists in the questions:{boardID}:answered sorted set using the ZSCORE command. If so, we do nothing.

We use the HINCRBY command to increment the score in the hash by 1 and the ZINCRBY command to increment the score in the sorted set by 1.

Endpoint: PATCH /api/question_upvote

Here is the source code for the question_upvote serverless function.

Fetch most recent approved questions

It’s very similar to how we fetch all approved questions with the only difference being that we read another sorted set where the key schema is questions:{boardID}:time. Since we used the timestamp as a score, the ZREVRANGEBYSCORE command returns IDs sorted in descending order.

Endpoint: PATCH /api/questions_recent

Here is the source code for the questions_recent serverless function.

Update a question with an answer

Updating or adding new properties to hashes is simple with the HSET command. However, when we add an answer, we move the question from the questions:{boardID} sorted set to the questions:{boardID}:answered one preserving the score.

To do so, we need to know the score of the question and we obtain it using the ZSCORE command. Answered questions will be sorted by score in descending order.

Then we can:

1. update the hash with the url property using the HSET command;
2. add the hash to the questions:{boardID}:answered sorted set using ZADD;
3. remove the question from the questions:{boardID} sorted set running the ZREM command.
4. remove the question from the questions:{boardID}:time sorted set running the ZREM command.

All four commands are executed in a transaction.

Endpoint: PATCH /api/question_add_answer

Here is the source code for the question_add_answer serverless function.

Fetch questions with answers

Again, the process is similar to fetching all approved questions. This time from the questions:{boardID}:answered sorted set.

Endpoint: PATCH /api/questions_unswered

Here is the source code for the questions_unswered serverless function.

Full source code. Working DEMO on my website.

Conclusion

Redis has a lot of use-cases going way beyond cache. I’ve demonstrated only one of the multiple applications for Redis that one can consider instead of reaching for an SQL database right away.

Of course, if you already use a database, adding yet another one may be an overhead.

Redis is very fast and scales well. Most commercial projects have Redis in their tech stack and often use them as an auxiliary database, not just in-memory cache.

I strongly recommend learning about Redis data patterns and best practices to realize how powerful it is and benefit from this knowledge in the long run.

Check my previous article where I created LinkedIn-like reactions with Serverless Redis if you haven’t already.

Here is You don't know Redis (Part 2)

Follow for more.