DEV Community: Saurav Dhakal

The Likes Table Problem: Why We Went Polymorphic.

Saurav Dhakal — Sat, 21 Feb 2026 16:26:32 +0000

A few days ago, I was working on adding a Community section to an application. The idea was simple, users should be able to:

Create posts
Leave comments
Like posts
Like comments

We also had a separate News section. The new requirement was users should be able to like news articles as well.

Building model for posts and comments was pretty straight forward. The real challenge was to model thelikestable.

The Problem: How Do We Store Likes?

We’re using PostgreSQL, so enforcing relationships with foreign keys is easy and clean.

If only one thing could be liked (say, News), the schema would be simple, we would have a news_like table which could look something like this:

user_id	news_id	timestamp
(foreign key)	(foreign key)

But we didn’t have one entity. We had three. posts, comments and news.

We had to decide:

Do we create three separate like tables? Or do we design one flexible solution?

Option 1: Three Separate Tables

We could create three tables: post_likes , comment_likes and news_likes . Each table would have proper foreign key relationships. This approach would be a clean relational way of doing things. It:

Keeps strong relational integrity
Makes joins easy
Keeps structure explicit

This is the most “pure relational” approach. But it felt repetitive. The schema grows horizontally.

And if tomorrow we add something else that can be liked, we’d need yet another table.

It works, but it doesn’t scale elegantly.

Option 2: A Polymorphic Table (What We Chose)

Instead of multiple tables, we created a single polymorphic likes table.

What is a Polymorphic Table?

A polymorphic table can reference multiple types of resources using a shared structure.

We designed our likes table to look something like this:

user_id	resource_id	resource_type	timestamp
(foreign key)	(uuid)	(POST / COMMENT / NEWS)

Here’s how it works:

user_id: who liked, foreign key to users table.
resource_id : the UUID of the item, just the uuid, no foreign key relation.
resource_type : what type of item it is
timestamp : timestamp

Instead of a strict foreign key to one table, we store:

The ID
The type of resource

Together, they uniquely identify what was liked.

With this approach, we had one clean and centralized table to store all kinds of likes. It’s much easier to expand and flexible. Since “like” is a feature common to many parts of the system, this design keeps it generic and reusable.

But it does has a major downside. We lose direct foreign key enforcement on resource_id. Because PostgreSQL can’t enforce a foreign key that dynamically points to multiple tables, referential integrity must be handled at the application level. We cannot write a simple join query to join from comments table or posts table.

For example, to fetch likes for a resource:

SELECT COUNT(*)
FROM likes
WHERE resource_id = 'some-uuid'
AND resource_type = 'POST';

Now, if we need resource details plus likes, we may need separate queries or application-side logic.

For our use case though, that trade-off was acceptable. We don’t perform heavy cross-entity joins on likes, so the downside was minimal.

Why This Design Felt Right

The key insight was this:

“Like” is not tightly coupled to Posts, Comments, or News. It’s a behavior shared across resources.

By modeling it polymorphically, we treated “like” as a reusable system capability rather than a feature embedded in each entity.

And as our application grows, this decision will likely save us refactoring time.

Why I Ended Up Adding Sessions to a JWT-Based System

Saurav Dhakal — Thu, 19 Feb 2026 16:33:19 +0000

Recently, I was working on an application where a new requirement came up: users should be able to see all the devices they are logged in from and log out from a specific device if needed.

This was something I hadn’t implemented before, which made it an interesting challenge.

At that point, the application was using JWT-based authentication. After a successful login, a JWT was generated and stored on client's side, and every request sent this token back to the server for authentication.

This approach worked well and had a major advantage: the server didn’t need to store any authentication state. That made the system simple, scalable, and easy to reason about.

But it also came with a limitation.

The Limitation of Stateless JWTs

JWTs are stateless by design. Once a token is issued, the server has no native way to know how many devices a user is logged in from, which device a request is coming from, or whether access from a specific device should be revoked.

As soon as features like device management or remote logout are needed, this lack of state becomes a real problem.

At that point, it became clear that the backend needed some form of state.

Introducing Session Storage

The solution I ended up with was introducing a sessions table.

Each successful login creates a session record representing a single device or login instance. Along with the user reference, the session stores lightweight metadata such as device information, approximate location, login time, and last activity. This gives the system visibility into active logins without becoming overly complex.

At this point, the system becomes session-aware, but JWTs are still kept in place.

JWTs with a Session Reference

Instead of replacing JWTs, a small change was made: the generated JWT now includes a sessionId in its payload. The token is still signed, still validated as usual, but now it also carries a reference to server-side state.

On each authenticated request, the server validates the JWT and then checks whether the referenced session still exists. If it does, the request is allowed. If it doesn’t, the request is rejected.

This single check enables remote logout.

When a user logs out from a specific device, the corresponding session record is deleted. Any future request from that device will fail authentication, even if the JWT itself hasn’t expired yet.

This also made it possible to list the devices a user is logged in from. Since the sessions table stores the userId, a single user logging in from multiple devices simply results in multiple session entries. Logging out from a specific device is then just a matter of deleting the corresponding session record. The next time that device makes a request, authentication fails.

Understanding Providers and Dependency Injection in NestJS

Saurav Dhakal — Tue, 10 Feb 2026 17:03:40 +0000

When I first started working with NestJS, registering providers (and controllers) inside a module felt like nothing more than a chore.

It was one of those things I did because “that’s just how Nest is designed.”

Even after I learned that modules exist to build an application graph, which it uses internally to resolve relationships and dependencies between modules and providers, the idea still felt vague and abstract. I understood what was happening, but not really why it worked the way it did.

Recently, I decided to take a deeper dive into how providers are registered and how Nest actually injects them. It turned out to be far more interesting than I expected.

Here’s what I learned.

First, let’s understand what Dependency Injection is.

Wikipedia defines Dependency Injection(DI) as:

Dependency Injection is a programming technique in which an object or function receives other objects or functions that it requires, as opposed to creating them internally.

Let’s look at a simple example.

Imagine a restaurant application. When a user’s order is ready for pickup, a notification needs to be sent.

class OrderService {
  // code operating over orders

  const notificationService = new NotificationService()
  notificationService.notify(userId, message)

  // ...
}

Here, OrderServicehandles order-related logic, and NotificationServicehandles notifications.

However, because NotificationServiceis instantiated directly inside OrderServiceusing new, this is not dependency injection.

Now compare that with this:

class OrderService {
  constructor(
    private readonly notificationService: NotificationService,
  ) {}

  // code operating over orders
  notificationService.notify(userId, message)

  // ...
}

This is dependency injection.

OrderService no longer cares about how NotificationService is created. It simply declares that it needs one, and something else provides it. That instance can also be reused or cached if the configuration is the same in multiple places.

Why Dependency Injection?

Dependency Injection helps by:

Reducing coupling between classes
Making testing easier (you can inject mock dependencies)
Encouraging modular, maintainable code

How Dependency Injection Works in NestJS

Alright, enough theory, this is where things start to get interesting.

In NestJS, the basic flow looks something like this:

Define a provider using @Injectable()
Register that provider with Nest
Ask Nest to inject it using constructor-based injection

Registration usually happens in a module:

@Module({
  providers: [DemoService],
  controllers: [DemoController],
})
export class DemoModule {}

At this point, Nest becomes responsible for creating and managing instances of DemoService.

Nest’s IoC Container (The Missing Piece)

NestJS uses an IoC (Inversion of Control) container to manage dependencies.

You can think of this container as a key-value registry:

Keys are called tokens
Values describe how to create or retrieve a dependency

When we write:

providers: [DemoService]

Nest internally expands it into a standard provider definition:

providers: [
  {
    provide: DemoService,
    useClass: DemoService,
  },
]

In this case:

The token is DemoService (the class itself)
useClass tells Nest which class to instantiate when that token is requested.

So when Nest encounters:

constructor(private readonly demoService: DemoService) {}

Nest looks up the DemoService token in the IoC container
It finds the matching provider record
It resolves the provider (useClass in this case)
The instance is created (or reused, since providers are singletons by default)
The resolved instance is injected into the class

A Quick Note on `useValue` and `useFactory`

useClass is the most common way to define a provider, but it’s not the only one.

useValue lets you inject a constant or pre-created object

Useful for configuration values, feature flags, or mocks.
useFactory allows you to create a value dynamically

Nest runs a function and injects whatever it returns.

All three (useClass, useValue, and useFactory) exist for the same reason:

they tell the IoC container how to resolve a token when it’s requested.

NestJS - Maintaining transactional integrity across services

Saurav Dhakal — Sun, 08 Feb 2026 08:45:51 +0000

I’ve been using NestJS for quite a while now, both professionally and for pet projects. The way it enforces certain design principles makes it easy to get started and, more importantly, helps keep projects maintainable in the long run. Compared to plain Express, which I used a few years back, Nest brings a lot of structure that naturally scales with application complexity.

That said, there was one thing I kept struggling with: maintaining transactional integrity across services.

In NestJS, we typically break applications into modules based on features or domains. Each module contains services, and those services encapsulate business logic. A single module may have multiple services, each exposing several methods that handle specific business actions. These services often call one another, sometimes even across module boundaries.

The problem starts when a service needs to orchestrate multiple other services, each of which performs changes in the database. In such cases, we often want all those changes to be atomic: either everything succeeds, or everything is rolled back.

Consider an order management system as an example. An OrderService might:

call an InventoryService to reduce stock,
call a LedgerService to record financial changes,
and possibly trigger other side effects.

All of these operations must succeed together. If any one of them fails, the system should revert all previously applied changes. This is where database transactions, commit and rollback, come into play.

Most ORMs make this relatively straightforward. For example, in Prisma:

prisma.$transaction((tx) => {
    // operations using tx
});

At this level, transactions are easy to work with. The real challenge, however, is how to pass this transaction context cleanly across multiple services without polluting method signatures or tightly coupling services together.

And that’s where things start to get tricky.

How do we pass this transaction around? One obvious and simple solution would be to make each service accept and optional argument, the transaction itself. Something like

async someService(argA:type, argB:type, ..., tx?:transaction){
  //code
}

This works, but as the application grows, it quickly becomes messy.

The transaction parameter starts appearing everywhere, even in methods that don’t always need it. Debugging becomes harder, method signatures become noisy, and transaction objects get passed deeper and deeper through the call stack.

After running into this a few times, I started wondering: isn’t there a cleaner way to do this?

As it turns out, there is. Before getting to that, though, we need to understand Node’s Async Local Storage.

What the hell is an Async Local Storage?

Node.js provides a feature called Async Local Storage (ALS), built on top of the async_hooks API.The official documentation describes it like this:

AsyncLocalStorage allows storing data throughout the lifetime of a web request or any other asynchronous duration. It is similar to thread-local storage in other languages.

In simpler terms, Async Local Storage lets you attach data to an asynchronous execution context and access it anywhere down the async call chain, without explicitly passing it around as a function argument.

If you come from languages like Java or C#, you can think of it as the Node.js equivalent of thread-local storage. Since JavaScript doesn’t have threads in the same way, ALS instead tracks async execution contexts.

You can think of it like a hidden backpack. You put something into the backpack at the start of a request, like a database transaction, and any code executed as part of that request can retrieve it later, without knowing who put it there or how it got passed down.

We can initialize ALS once (for example, in middleware) and then use it throughout the entire request lifecycle.

A minimal ALS Setup

First, we create a shared Async Local Storage instance:

// als.ts
import { AsyncLocalStorage } from 'node:async_hooks';

export const als = new AsyncLocalStorage<Map<string, any>>();

This is like defining the “backpack” where we’ll store transaction and other stuff and use per request.

Next, we initialize a new async context in middleware:

// als.middleware.ts
import { Request, Response, NextFunction } from 'express';
import { als } from './als';

export function alsMiddleware(
  req: Request,
  res: Response,
  next: NextFunction,
) {
  const store = new Map<string, any>();

  als.run(store, () => {
    next();
  });
}

Here, als.run(store, () => next()) creates a new async context and ensures that everything that happens after next() shares the same store.

Finally, we register the middleware:

// app.module.ts
import { MiddlewareConsumer, Module, NestModule } from '@nestjs/common';
import { alsMiddleware } from './als.middleware';

@Module({})
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer.apply(alsMiddleware).forRoutes('*');
  }
}

At this point, every request gets its own isolated context, which can be accessed anywhere during that request.

Reading and writing from the context

To store something in the ALS context:

import { als } from './als';

export class SomeService {
  doSomething() {
    const store = als.getStore();

    if (store) {
      store.set('foo', 'bar');
    }
  }
}

And to access:

const value = als.getStore()?.get('foo');

No extra parameters. No tight coupling. Just request-scoped state.

Using ALS with transactions

Now we can come back to the original problem.

Here’s a simple example using Prisma:

 import { als } from './als';

export class SomeService {
  async doSomething() {
    prisma.$transaction(async (tx) => {
      const store = als.getStore();

        if (store) {
          store.set('tx', tx);
        }

        await serviceA();
        await serviceB();
        //...
    }
  }
}

Inside the transaction callback, we store the Prisma transaction object in ALS. From this point on, any service called as part of this request can retrieve the transaction from ALS and use it, without having it explicitly passed in.

This keeps service APIs clean, avoids deeply nested transaction plumbing, and lets transactions remain a cross-cutting concern rather than a business-logic detail.

Learning this approach has been a nice win for me, and I’ve been happily using it ever since. It removed a lot of friction around transactions in NestJS. How are you solving this in your own applications?

Understanding JavaScript's Asynchronous Magic: Event Loop, Web APIs, and the Call Stack

Saurav Dhakal — Thu, 01 May 2025 14:50:45 +0000

When I first started working with JavaScript, I used async functions like 'fetch()' or 'setTimeout()' every day — but I never really understood how they worked behind the scenes.

It was just "magic": you call something, and sometime later, it gives you back a result.

Recently, I decided to dive deeper into how JavaScript handles asynchronous operations — and it completely changed the way I
see JavaScript.

In this post, I’ll explain (in simple terms) how the call stack, Web APIs, callback queues, and the event loop work together
to make async code possible.

JavaScript is Single Threaded

JavaScript is a single-threaded language.This means, JS uses a single call stack. So, only one piece of code can run at a time.

console.log(1);
console.log(2);
console.log(3);

For this simple program, single line is executed at a time. Each 'console.log()' is added to call stack, executed and poped off once completed. So code, executes synchronously, line by line, top to bottom.

That’s fine for most things — until we hit something that takes time.

The Problem with blocking code

Imagine calling a function that takes 5 second to execute. Since JS runs synchronously, it'll just.. wait. Nothing else runs until that function finishes. This blocks the stack — and with it, your entire app.

This is not ideal. Imagine a network request blocks the stack and makes our entire application unresponsive.

Enter Asynchronous Programming

To avoid blocking, JavaScript (along with the environment it runs in — like browsers or Node.js) uses a set of tools: Web APIs, callback/task queues, and the event loop.

This trio helps JS handle things like network requests, timers, or file operations without freezing the app.

Web APIs:
Web APIs are a set of features provided by the environment (like the browser or Node.js) to handle operations that might otherwise block the main call stack.
For example, the fetch function — used to retrieve data from the internet — is a Web API provided by the browser.
When you call fetch, it runs outside of the main call stack, so it doesn't block the rest of your code from running.
Callback/task queue
When you use Web APIs, you often provide a callback function — a piece of code that should run after the operation finishes.
```
    fetch("https://example-api.com/data", {
    }).then((res) => 
        // Do something with data returned
    );

    // Rest of code
```
In the above example, we make a fetch request. The .then method is used to register a callback function. When the response is available, the function you provided inside .then is queued — it waits in the callback queue.
The callback queue holds all such functions waiting to be executed.
But they don't immediately run — this is where the event loop comes in.
Event Loop
The event loop is a loop that constantly checks two things:
- Is the call stack empty?
- Are there any functions in the callback queue?

If the call stack is empty and there’s a function waiting in the callback queue, the event loop pushes that function onto the call stack, allowing it to run.
This is how JavaScript handles asynchronous behavior without blocking the main thread.

How it all works (High level)

When you run a function like fetch(), the browser (not JavaScript itself) handles it using its Web APIs. Once the operation completes, it doesn’t just jump back into the call stack. Instead, a callback function (or a resolve function in case of a promise) is queued.
That callback sits in a task queue or microtask queue. After the main code is done (i.e., the call stack is empty), the event loop starts checking the queues.
If it finds any callbacks, it pushes them onto the call stack — where they get executed like any other function.
This makes async feel synchronous in some cases, without actually blocking the code.

This system confused me for a long time. I used async code every day, but I never asked what actually happens. Once I saw the call stack, Web APIs, queue, and event loop as a team, it all made sense.

The JavaScript Course That Made Me Curious Again

Saurav Dhakal — Sun, 13 Apr 2025 07:48:22 +0000

I recently took a course on Frontend Masters — JavaScript: The Hard Parts, v2. This course made me realize how little I truly understood JavaScript.

I’ve been building web apps with JavaScript “professionally” as a backend engineer for a while now. I’ve gotten to a point where setting up new projects or making changes to existing ones feels almost effortless — the kind of stuff that used to scare me early on.

But maybe that’s exactly the problem. I stopped getting curious.

Back when I was just starting out, when I knew so little, I was desperate to understand it all. How Node works under the hood. What promises really are. What’s the deal with “this”. I’d question anything I could. And I loved it.

These days? I mostly do what I need to do — and move on. I don’t think much about what’s happening behind the scenes. Maybe it’s the “professional” mindset kicking in. Or maybe somewhere along the way, I started losing the sense of play that got me into this field in the first place.

I came across this course through a blog post. I don’t remember what blog it was, but the course seemed interesting. I was on my semester break, had plenty of free time — so I decided to take it. And I’m so glad I did.

Because taking this course made me realize how much I didn’t know — even though I use most of this stuff every day.

And honestly, that’s okay. Not knowing isn’t the problem. What matters is the curiosity. The urge to dig deeper, to play around, to ask “why” even when things seem to work fine.

That’s how I grew in the beginning. That’s what got me hooked.

Somewhere along the way, I lost that.

So, what I aim for in the days to come is to be more curious — to find time, now and then, to question what I know and how things actually work. To check if I really understand it, or if it’s just muscle memory getting me by.

Because this — this urge to dig deeper — is what keeps the craft alive.

It’s how we grow. It’s how we keep learning. And maybe most importantly, it’s what keeps the joy alive.

And I don’t want to lose that again.

(Originally published on https://www.sauravdhakal.com.np)