{"id":394127,"date":"2024-06-29T11:25:10","date_gmt":"2024-06-29T11:25:10","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=394127"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=394127","title":{"rendered":"You don’t know Redis (Part 2)<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

In the first part of\u00a0You don’t know Redis<\/u><\/a>, I built an app using Redis as a primary database. For most people, it might sound unusual simply because the key-value data structure seems suboptimal for handling complex data models.<\/p>\n

In practice, the choice of a database often depends on the application\u2019s data-access patterns as well as the current and possible future requirements.<\/p>\n

Redis was a perfect database for a\u00a0Q&A board<\/u><\/a>. I described how I took advantage of\u00a0sorted sets<\/u><\/a>\u00a0and\u00a0hashes<\/u><\/a>\u00a0data types to build features efficiently with less code.<\/p>\n

Now I need to extend the Q&A board with registration\/login functionality.<\/p>\n

I will use Redis again. There are two reasons for that.<\/p>\n

Firstly, I want to avoid the extra complexity that comes with adding yet another database.<\/p>\n

Secondly, based on the requirements that I have, Redis is suitable for the task.<\/p>\n

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.<\/p>\n

Despite Redis being suitable for my task, it may not be a good choice for other projects.<\/p>\n

Always define what data structure you need now and may need in the future to pick the right database.<\/p>\n

Implementation<\/h3>\n

I use serverless functions, the\u00a0ioredis<\/u><\/a>\u00a0library and\u00a0Upstash Serverless Redis<\/u><\/a>.<\/p>\n

I can\u2019t 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.<\/p>\n

I have zero work with setting up Redis. Moreover, I am using Upstash both in development and production.<\/p>\n

Registration flow<\/h3>\n

During registration, we collect the user\u00a0name<\/code>,\u00a0email<\/code>\u00a0and\u00a0password<\/code>. Before registering a user, we need to make sure that the email has not been registered already (is unique in the system).<\/p>\n

Redis does not support constraints. However, we can keep track of all registered emails using a sorted set named\u00a0emails<\/code>.<\/p>\n

On every new registration, we can use the\u00a0ZSCORE<\/u><\/a>\u00a0command to check whether the provided email is already registered.<\/p>\n

If the email is taken, we need to notify the user about it.<\/p>\n

\u200b Note, that this isn\u2019t 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\u2019s not a big security issue.<\/p>\n

Before we can save a new user, we need to:<\/p>\n