DEV Community: Neel-Vekariya

Next step to client-side storage

Neel-Vekariya — Sun, 23 Aug 2026 09:44:40 +0000

Next step to client-side storage

In my past one blog, I wrote about how I improve the performance of the application using the local storage. And the problem local storage solves.

But now I face another problem about the client storage. My project is simply about order management software for the rental clothing industry.

In the rental clothing industry, Showrooms or small shops have a big problem. The problem starts when one order has a single or multiple items that are booked in a particular time range.

Now, a second order wants the same item in between that particular time range. If, by mistake, the second order books that item, then the problem starts.

The item is booked two times in that particular time range. That is called double booking of the item.

This mistake is created by the use of traditional register booking. Now, when I need to store the items data, that is a small amount of data, so I simply use the local storage.

But now I need another and a big storage for storing order details. I build two features: first one is for showing all the orders and second one is for showing the full order.

To implement those features and to maintain the user experience, I decide to store a small amount of data about the order on the client side. First, I decide to store data in local storage.

But to store data in the local storage is not a good option because the local storage is used for storing small details about the application, and storing order details in the local storage compromises the performance of the application.

Now I want a new storage option for storing order details. And again I find out, and that is the IndexedDB.

To integrate IndexedDB in my application, I want to learn about that storage. I search multiple videos about IndexedDB, but no one is teaching me properly.

After finding hundreds of tutorials, I finally found one tutorial that is teaching properly how to integrate IndexedDB in the application. Now I want to share that learning with you.

To integrate IndexedDB, we want to create first one database in IndexedDB. The dbConnect is built for that and used to get the reference of the created database.

To build that function, we want to create first two environment variables: db_name and version. Those two variables describe the name and the version of that database.

If any updation happens in the version variable, then this function will execute and update the database.

const dbConnect = () => {

  const req = indexedDB.open(db_name, version);

  req.onupgradeneeded = () => {

    const db = req.result;

    // Access the reference of the database.

    const payload = {
      keyPath: "id",
      autoIncrement: true
    };

    // The payload is for creating a primary key.

    db.createObjectStore("orders", payload);

    // Create the object that is called store in IndexedDB.
  };

  req.onsuccess = () => {
    console.log("Success", req.result);
  };

  req.onerror = () => {
    console.log("Failed", req.error);
  };
};

Now, in the function, we create first one database and get the reference of that database. The req.onupgradeneeded is an event for updating the database when the version variable is changed, then this event is run and updates the database.

The req variable sends the request to open the database, and after the request is complete, we now have access to the database connection reference. The payload is the rule for how the primary key of that particular store will be generated.

To create a store, first we access the result object, and in the result object, we use the createObjectStore method. onsuccess and onerror are events that indicate the success or failure of the connection.

The function dbConnect is an asynchronous function, so the next step is to convert this asynchronous function to a synchronous function. To create a synchronous function, we simply wrap this function into the promise.

Let's do that.

We do this promise in the req.onsuccess or req.onerror event. If the req is successful, we resolve the promise; otherwise, we reject the promise.

The updated event is:

req.onsuccess = resolve();
req.onerror = reject();

const dbConnect = () => {

  return new Promise((resolve, reject) => {

    const req = indexedDB.open(db_name, version);

    req.onupgradeneeded = () => {

    };

    req.onsuccess = () => resolve(req.result);

    req.onerror = () => reject(req.error);

  });
};

Now our function is converted into the synchronous function. Now, the next step we explore is how to store, update, read and delete the data.

In IndexedDB, all the operations are transactions. Means if any error happens, then all the started operations are undone.

Now the next step is to get knowledge about the permission. When we want to store or delete or update the data, the first step is to define the permission.

readonly, readwrite are the types of permission.

const storeData = async () => {

  try {

    const db = await dbConnect();

    const transaction = db.transaction("orders", "readwrite");

    // Define the permission.

    const payload = {
      name: "Neel",
      email: "neel@gmail.com"
    };

    // The data to store.

    transaction.objectStore("orders").add(payload);

    transaction.oncomplete = () => {
      console.log("Data Stored Successfully.");
    };

  } catch (error) {
    console.log(error);
  }
};

This is all about storing the data. Now we learn about reading the data.

For reading the data, we use readonly permission. The getAll() function is used to get all the data, and get() is used to get particular data.

const readData = async () => {

  try {

    const db = await dbConnect();

    const transaction = db.transaction("orders", "readonly");

    // Define the permission.

    const request = transaction.objectStore("orders").getAll();

    request.onsuccess = () => {
      console.log("Data Fetched Successfully.", request.result);
    };

  } catch (error) {
    console.log(error);
  }
};

This is all about how to read the data. Now next, we learn how to update the data.

To update the data, we use the readwrite permission.

const updateData = async () => {

  try {

    const db = await dbConnect();

    const transaction = db.transaction("orders", "readwrite");

    // Define the permission.

    const store = transaction.objectStore("orders");

    // In this store we do not use any function; either we get the reference.

    const req = store.get(id); // Get old data.

    req.onsuccess = () => {

      const data = req.result;

      if (!data) return;

      const payload = {
        ...data,
        name: "Jay",
        email: "Jay@gmail.com"
      };

      // Only change name and email and other data store as it is.

      store.put(payload);
    };

  } catch (error) {
    console.log(error);
  }
};

This is all about how to update the data. Now next, we learn how to delete the data.

To delete the data, we use the .delete() method.

const deleteData = async () => {

  try {

    const db = await dbConnect();

    const transaction = db.transaction("orders", "readwrite");

    // Define the permission.

    const store = transaction.objectStore("orders");

    // In this store we do not use any function; either we get the reference.

    const req = store.delete(id); // Delete data.

  } catch (error) {
    console.log(error);
  }
};

Now we successfully implemented the IndexedDB in our project.

If I made any mistake, then share my mistake in the comments.

Then My Project Needed This

Neel-Vekariya — Sat, 15 Aug 2026 07:33:22 +0000

Finally, I Integrated the Multiselect Autocomplete Dropdown

In the past few months, I learned a lot of things and also made a project after many retries. The project taught me many important concepts that I didn’t know after learning languages, frameworks, or even in lectures.

These were concepts that I only came across when I wanted to use them in my project or when I faced some issues. The Multiselect Autocomplete Dropdown is one of the concepts that I didn’t learn when I was actually in the learning phase, but I learned it when I was building something on top of my learnings.

In my project, I wanted a feature in the frontend where a user could send me multiple-selected values of one field, and I also wanted that field to be searchable and autocomplete.

Then I noticed that this type of feature is also provided in HTML with the select tag, but there was an exception with this tag, and the exception was that the tag is not searchable and does not support multiple values.

So, I needed a different solution, and I wanted to figure out that solution.

In the age of AI, finding a solution is very easy, but the difficult part was integrating it into my project.

I found the solution with the help of AI, and now the next step is to integrate it into my project.

I think this type of feature is learned only for a purpose. The topic is learned when the functionality is needed.

When the topic is learned only for the purpose of learning, then the topic is not available in the course we want to learn from, documentation, or some video where the topic is not fully explained.

In this case, I faced the same problem.

If you face the same problem, please share your experience in the comments.

Finally I access The Child Element

Neel-Vekariya — Tue, 11 Aug 2026 04:21:58 +0000

Recently, if you read my little weird blogs, you know I learn React.js and build one project. In the project, I made many mistakes like creating a complex component structure. Later I removed all components and made a clear folder structure.

I created cards that did not show data, and I don’t know why. And so on. But one problem came when I used the React-Hook-Forms and my custom input field.

This problem gave me more knowledge as well as an idea about how react-hook-form works. The problem is like this. When I want to access the child component from the parent component to access the data entered by the user.

That gave me undefined instead of the value which was passed by the user. I was not able to find out why that happened. Later I found out that my parent element does not have access to the input field. That is the problem.

Now I don’t know why the parent element does not access the child element. In the parent element, I did not make a mistake in using the child element. Then why did that happen.

Subsequently, I found out that the register which is used for accessing the value from the child element sends one ref to the child element. But I did not define that or use that. Now I found out the method that is used to pass reference to the child component.

React provides a higher order function named forwardRef to solve the problem of passing the reference to the child component. The forwardRef is not needed in a normal input or select field.

The custom component built for reusability blocks the reference. In this situation, we need a service that passes the reference from the parent to the child component.

The service is provided by the higher order function forwardRef. To use forwardRef in the custom component, you need to import it from React. And pass it as a secondary separate parameter ref in the function.

Now pass this parameter as a ref property in the custom input component. And wrap your exported component in forwardRef. Now you have access to the child component in the parent.

And also have the value which is passed in your child component. Now this function solved my problem of passing undefined value.

If I have done something wrong, please let me know in the comments.

How I Prevent unauthorized user to access restricted routes

Neel-Vekariya — Fri, 07 Aug 2026 04:55:29 +0000

In my last post, I talked about how I simplified managing all my components. After building all the components for my backend project, I assembled them into the home page and created a flow between them to navigate from one feature to another.

But, I didn’t run the frontend for testing. Consequently, I did that, and obviously, I had many errors on the screen.

Firstly, I solved all the errors I had and checked whether all the components were working properly or not. After checking all components, suddenly I found one security issue in my application.

When I wanted to switch from one feature to another feature, I tried some kind of shortcut in the URL, and it worked. How, I don’t know.

As a result, it rendered my component that was restricted for the user I logged in. This was a problem for me due to data security and the exposure of protected routes.

I needed a solution. As a result, I searched about the problem and found out this is not only my problem but also a problem that all developers face.

They have a centralized solution for that, in addition to using a Protected component. The main idea of the protected component is to check given conditions.

If the conditions are true, then render the protected component, else navigate them to the login or register page. The component is also used to boost user experience.

Due to redirecting the user to the login or register page, this creates a smooth path for the user to use your application.

Now let’s understand the working of the protected component. The component generally takes two parameters.

The first one is children, which is the component we want to protect from unauthorized users. The second one is whether the user is logged in or not.

Now in the component, we need access to the state that shows whether the user is logged in or not. Now we have two variables that decide whether the user is authenticated or not.

Now one question may come to your mind: why do we give the second parameter when we already have access to the state that represents whether the user is logged in or not?

The reason is that if you want optional control over the controller, as a result, you have special control over this component. Now we check the condition.

For checking conditions, we use useEffect to track all variable or state changes. Now if the condition is fulfilled, then render the protected component, else navigate.

In the code section, I have done the same thing I mentioned.


export default function Protected({ children, authenticated = true }) {
  const navigate = useNavigate();
  const authstatus = useSelector((state) => state.auth.authstatus);

  useEffect(() => {
    if (authenticated && authstatus !== authenticated) {
      navigate("/login");
    } else if (!authenticated && authstatus !== authenticated) {
      navigate("/home");
    }
  }, [authenticated, navigate, authstatus]);

  return children ? children : <h1>Loading...</h1>;
}

I am still learning frontend development, so if you find anything wrong or have suggestions, feel free to share your thoughts in the comments.

Thanks for reading!

How I Simplified My React Project Using Feature-Based Component Structure

Neel-Vekariya — Tue, 04 Aug 2026 04:44:50 +0000

Recently, I learned React.js, including how frontend development works, how to make the frontend responsive, and how to make reusable components. The only part that was missing to become a full-stack developer is now fulfilled.

Now, I am officially a full-stack developer.

In the journey of becoming a full-stack developer, I picked one project and improved it. First, I learned Node.js, Express.js, and MongoDB and developed one project using these technologies.

The project I developed had many issues, so I built the same project again from scratch using the same technologies. At this point, I learned how to make a backend, but I wanted to learn Fastify and PostgreSQL, so I learned both of them.

After learning Fastify and PostgreSQL, I built the same project using these technologies, and this helped me understand the backend deeply. Now, I have learned how to make backend APIs and databases.

But one part was missing to develop a full product, and that is the frontend. I only knew how to make backend APIs and design databases.

A month ago, I started learning how the frontend works, learned React.js, and other things like routers, hook-forms, localStorage, stores, etc. After learning the frontend, I made a React app for my backend project.

But I didn’t know how to manage components, so I created components in a way that made my project complex to manage. I simply created one parent folder named "components", and in the parent folder, I created multiple subfolders like Button for the Button component, Login for the login page, Input for input fields, Register for the register page, Select for the dropdown component, Footer for the footer component, and so on.

This means that I made one subfolder for each component, and now I realize this structure made it complex to manage all components.

Why I Chose Feature-Wise Component Structure

At this point, I decided to learn component structure next. I found many structures for managing components, but feature-wise component management is best for me.

Why is it best for me? The answer is the backend project I built. In the project, I built role-wise login, logout, and features.

Due to my backend project, I needed login, logout, register pages, and components for both roles. The feature-wise structure is best for me.

How Feature-Wise Structure Works

In a feature-wise structure, we build two main folders — the first one is "components" and the second one is "features". Now, we build role-wise subfolders in the "features" folder.

In the "components" folder, we build components that are reusable for other components like Input, Button, and Select components. This is the main concept of the feature-wise component structure.

The pages or components used for a specific feature that refers to a specific role are created in the role-wise folder. This structure removes complexity, which was a problem for me.

Now, I add more components or features, and I manage all of this in a simple way. You get an idea from the reference image that I attached.

I am still learning frontend development, so if you find anything wrong or have suggestions, feel free to share your thoughts in the comments.

Thanks for reading!

How Local Storage improves the Frontend performance

Neel-Vekariya — Sat, 01 Aug 2026 07:19:58 +0000

How Local Storage improves the performance

In the past many days, I learned about how frontend actually works and I learned lots of things. React is one of them. I learned how to manage state, how hooks work, how to make frontend faster and reliable, and the most important thing is how client-side data is actually stored using the local storage object.

If you don’t know, the local storage object is provided by all web platforms by default.

How Local Storage Works

Now that we know where local storage actually lives, the next question is how local storage actually works. Let’s imagine you open one website, you change the theme, you select your preference, and you refresh the page.

Now all your selected things or preferences get reset. And this is the problem. If your selected preferences or theme get reset, this creates a lack of user experience. To solve this problem, we actually use local storage.

Now you know about which problem we face and how it can be solved by local storage. So the next question may come: how does it work?

The working mechanism is when a user selects the preference or theme or any other things which boost user experience, then it is stored in client-side storage using local storage.

The data is stored in object format. All browsers provide around 5MB of local storage for one domain. When you first time access the local storage data, it is read from the disk and loaded into the RAM, and the browser keeps that data in cache for faster access in the future. Now the second time you need data, we don’t carry data from the disk, we already have it in cache. That improves the user experience.

Implementation of Local Storage

Now you know how local storage actually works under the hood. The next question might come: how do we implement local storage?

The answer is using the setItem and getItem methods of local storage. First we know about how to store created items or data in localStorage, after that we talk about how the API data is stored.

1) Store Created Data in Local Storage

To store data into local storage, we need two types of data. First is created data or data which is extracted from the response, and second is already stored data in localStorage.

Before combining, we need to convert stored data into an object. Now we combine both data and create one object. But we can’t store it directly into localStorage. To store data, first we need to convert that object into JSON format or string format. After converting into JSON or string format, we store it in localStorage using the setItem method.

This is the code:


const res = await axios.post("https://example.com/users");   
const newData = response.data.data; 

const existingData = JSON.parse(localStorage.getItem("user")) || {};     // Get old data   

const mergedData = {     
  ...existingData,     
  ...newData   
};    // Merge    

localStorage.setItem("user", JSON.stringify(mergedData)); // Save again

In the code, “user” is the object where data is stored.

2) Store API Data with Deduplication

Now talk about the data which comes from the API. In this case, we again need two types of data. First is response data and second is the stored data which we need to convert into an object. After that, we combine both data, but we need to implement a filter for the data which is present in response and also in stored data, so we remove duplicate data. Now we merge into the object, convert into string, and store it into localStorage. This is the code:


const localData = JSON.parse(localStorage.getItem("bookings")) || []; // Get old data 

const res = await axios.get("/api/shop/orders"); 
const apiData = res.data;  // New data

const merged = [ 
  ...localData, 
  ...apiData.filter((api) => !localData.some((local) => local.id === api.id)), // Filter the data which is already present
];  // Combine the data

localStorage.setItem('bookings', JSON.stringify(merged)); // Store the data

I am still learning frontend development, so if you find anything wrong or have suggestions, feel free to share your thoughts in the comments.

Thanks for reading!

How to Prevent Hanging Network Calls — What I Found After Investigating a Real Performance Issue

Neel-Vekariya — Mon, 13 Jul 2026 03:26:53 +0000

In the past two months I explored a lot of things Express, Fastify, MongoDB, PostgreSQL, Node.js. I built around three to four projects in this time.

All of them focused on backend because I haven't learned React yet. But the next one will be full stack.

While building these projects, I noticed one issue that kept repeatedly coming back.

Every time I called a database or an external service something that depends on a network call things would get weird.

Sometimes the response never came. Sometimes it took way longer than it should. And this was creating a performance issue in my application that I couldn't ignore.

So I investigated it properly. And I found that this is actually a common problem a lot of developers face this. And there's a standard solution for it.

The Solution is a Timeout Wrapper

The idea is simple. When you make a network call, instead of just calling it directly, you pass it through a timeout wrapper.

If the call takes more time than it should, the wrapper skips or terminates the call and moves on.

This keeps your application from getting stuck waiting on something that's never going to respond in time.

Two Functions : Two Different Approaches In Timeout

While building this, I found there are two ways to implement a timeout wrapper. Both solve the same problem but work very differently.

1. withTimeout()

export function withTimeout(promise, ms, errorMessage = "Operation timed out") {
    const timeout = new Promise((_, reject) =>
        setTimeout(() => reject(new Error(errorMessage)), ms)
    )
    return Promise.race([promise, timeout])
}

This function takes two things the promise (which is your network call) and the time limit in milliseconds.

Inside, it creates a second promise called timeout. This promise does one thing if the given time runs out, it rejects with an error message.

Then it uses Promise.race(). This function takes both promises and returns whichever one finishes first.

If your network call responds in time, Promise.race gives you that response. If the timeout fires first, you get the error.

Simple. Clean. Works.

But there's a catch I found and this is the important part.

withTimeout() doesn't actually terminate the original network call. If the timeout fires and you move on, the network call is still running in the background.

The socket is still open. Memory is still being used. CPU is still consumed. The request finishes eventually you just stopped waiting for it. The resources are still gone.

This is where the second function solves a different problem.

2. fetchWithTimeout()

export function fetchWithTimeout(url, options = {}, timeoutMs = 10_000) {
    const controller = new AbortController()
    const timer = setTimeout(() => controller.abort(), timeoutMs)

    return fetch(url, { ...options, signal: controller.signal })
        .finally(() => clearTimeout(timer))
}

This function takes the URL, options for the network call, and the timeout.

The key difference here is AbortController. This is a browser and Node.js API specifically built for canceling asynchronous operations without creating memory leaks.

You create a controller, attach its signal to the fetch call, and start a timer. If the timer runs out before the call responds controller.abort() is called.

The fetch is terminated. Not just skipped actually terminated. All the resources that were being consumed get freed.

And the finally() at the end makes sure the timer gets cleared if the call does respond in time. No timer left hanging.

The Real Difference Between Both

This is the thing I want to make clear because it took me a bit to fully understand it.

withTimeout() skips the wait. If the call takes too long, you move on. But the call is still running. Resources are still being consumed. You just stopped caring about the response.

fetchWithTimeout() terminates the call. If it takes too long, the request is actually cancelled. Network socket freed. Memory freed. CPU freed.

For most external API calls where you're using fetch, fetchWithTimeout is the right choice because it actually cleans up after itself.

For other types of async operations database queries, file reads, anything that returns a promise withTimeout is what you'd use. Just know that the operation continues in the background even after the timeout fires.

Why This Actually Matters

When I was building my projects and network calls were just hanging my application was stuck. The user was waiting. The server was waiting. Nothing was happening.

After adding timeout wrappers, if a call hangs, the application moves on. The user gets a proper error response instead of waiting forever. And with fetchWithTimeout, the resources actually get freed instead of piling up in the background.

This is the kind of thing that feels small but makes a real difference in how your application behaves under real conditions.

One investigation. One problem. Two functions that solved it.

If I got something wrong or anything can be improved please drop it in the comments. I'm still learning and I want to get this right.

The Next Token, Not the Next Script

Neel-Vekariya — Wed, 08 Jul 2026 05:45:51 +0000

Everyone is using AI to write code now. But I think the real future of programming isn't AI generating full scripts or full products it's AI predicting the next token, and us deciding whether that token is right or not.

Here's why. When you write code manually, you're already doing something similar in your head predicting the next line based on patterns you've seen before, then checking if it's correct as you write it. Every line passes through your judgment.

When AI generates a full script or product, that judgment gets skipped. You review the code, sure, but not the way you'd review your own. You skim "this line does X, this line does Y" and move on. You're checking outcomes, not making decisions. That's a completely different mental process, and it's shallower.

But when AI suggests the next token, or the next line, instead of the next thousand lines, you're forced back into the same loop you'd use writing manually: is this right, or not? You stay the one making the call.

That's why I think the best use of AI in programming isn't generate my whole app. It's predict what comes next, and let me decide. Smaller suggestions keep engineers in the driver's seat. Full generations quietly take the wheel.

Request Scoped Context – How I Stopped Passing Arguments Everywhere

Neel-Vekariya — Mon, 29 Jun 2026 07:40:02 +0000

In my past two backend projects, I use to pass info about user manually. I thought this is the right method. Every time some function need info, I pass it as parameter. Simple. Direct. Clean enough.

Then I started building a cloth rent booking app.

In start everything was fine. I had orderId coming in with the request. I pass it to my booking service. Service pass it to availability checker. I thought — this is clean approach. I feel good about the code.

Then the app start getting more complex.

Now my orderId need to travel from controller to booking service to availability checker to pricing calculator to logger. Every function in this chain need that orderId as parameter.

Even functions which are not using orderId directly they just holding it for a moment and passing it to next function. Function is doing nothing with this parameter except passing it forward.

Like a relay race where some runners are not actually running. They just standing there, holding the baton, waiting to give it to someone else.

This is what called parameter pollution. I didn't know the name then. I just knew something is wrong.

The second problem hit me when I need to add new info deep in the execution. That mean I go back and add that parameter to every function in the chain.

Not because all function use it just because they are sitting in the middle. One change, five files touched. This is tight coupling. Changing something simple create maintenance overhead everywhere.

Third problem is logging. To attach orderId to every log entry I need to carry it all the way down the entire execution path. More parameters. More same work again and again. Copy paste same argument in every function signature.

I was writing same thing again and again. This kind of repetition is not productive. This is just noise.

So I start searching for better approach. How to pass context without manually threading it through every call. And I found something I never heard before.

AsyncLocalStorage.

My first reaction was wow. This is exact solution for my problem.

AsyncLocalStorage is a Node.js feature from the async_hooks module. The idea is simple. You create a storage that is scoped to a specific async execution meaning one request get its own private storage.

You store your orderId, userId, or any context once at the entry point of the request. After that, any function in the entire execution chain can read it directly. No passing. No threading. No pollution.

Node.js track async context internally. When you start a new context using AsyncLocalStorage, every async function running inside it inherit access to that same storage. No matter how deep the call stack goes. The info is just there, available, without anyone carrying it.

To build this in your project you need two functions only.

import { AsyncLocalStorage } from "async_hooks";

const requestContext = new AsyncLocalStorage();

export function runWithContext(context, fn) {
  return requestContext.run(context, fn);
}

export function getContext() {
  return requestContext.getStore() || {};
}

runWithContext is called at the entrance of your request in your middleware or route handler. You pass the context object with whatever info you need, and the function to run. Everything inside that function now have access to the same storage automatically.

getContext is called anywhere inside the execution deep inside a service, inside a logger, inside a helper. It reads from the current async context. No parameters needed. No importing shared state. Just call it and get what you need.

Now my logger not need orderId as a parameter. Just call getContext() and read it. My availability checker not carrying a parameter it don't use. My pricing calculator is clean. Every function only take what it actually need to do its job.

The code became honest. Functions stop pretending to care about things they don't care about.

When I first saw this working in my booking app the feeling was like finally. Not just because code was cleaner. But because I understand why the old approach was a problem in first place.

Small codebase hide these problems. You don't feel the pain until complexity grows. By then bad pattern is already everywhere and refactoring is expensive.

This is one thing I wish I know earlier. Not because it is hard to understand it is actually simple. But because the problem it solve only become visible at certain scale. And when you finally see it, you can't unsee it.

If you are building something today and passing same parameter through three or more functions just to reach one inner function this is your solution.

Store it once at the entry point. Read it anywhere. Let your functions stay focused on what they actually do.

If I made any mistakes in this — please mention in the comments. I'll correct it.

Why Problems Keep Me Going in Tech

Neel-Vekariya — Thu, 25 Jun 2026 07:40:29 +0000

As a learner in tech, Every day somehow I face a new problem I didn't even know existed yesterday.

And honestly I love this.

When something crashes, when a feature breaks, when I have no idea why the code is doing what it's doing and that struggle of finding the bug, digging into it, understanding it that gives me a kinda of motivation I can't explain. It's like a dopamine hit. The feeling after solving that problem is incredible.

I realized something because of this. Without problems, writing code becomes a repetitive, boring task. Zero motivation. Zero excitement. Just the same thing again and again.

But when something breaks when I actually have to think, investigate, sit with the problem that's when my boundaries expand. That's when I actually learn something.

The Comfort Zone

But I also noticed something else about myself.

The moment I get comfortable with something I lose interest in it.

It starts in the learning phase. Everything is new, everything is a problem, everything is exciting.

I'm struggling, I'm figuring things out, I'm building. And then slowly I get comfortable. That struggle disappears.

The thing that was exciting becomes a repetitive task. Boring. Routine.

And then I move on to the next thing.

This happened with MongoDB. I started learning it, faced problems connection issues, queries not giving correct responses, things not working the way I expected.

I struggled. I used it in my backend project. And then I got comfortable. The interest just went away. MongoDB became something I already knew.

So I moved to PostgreSQL.

Same thing happened with Express. I got comfortable, lost interest.

That's actually one of the reasons I moved to Fastify I needed something new to struggle with again.

The Interesting Part

At first I thought this was a problem. Like maybe I'm not focusing enough. Maybe I should stay with one thing longer.

But then I noticed something.

Express took me two and a half months to learn. Fastify took one week.

PostgreSQL took even less time than that.

The time it takes me to learn something new keeps getting smaller. Each thing I learn becomes the foundation for the next thing. The struggles I had before make the new struggles easier to work through.

Someone once said "Tomorrow's knowledge becomes the foundation of today."

I think about this a lot, And Thats True. Every uncomfortable thing I pushed through, every bug that frustrated me, every late night trying to figure out why something wasn't working all of that is why the next hard thing feels a little less hard.

What I Actually Think This Is

I don't think I get bored of things. I think I outgrow them.
The problems that once challenged me stop being problems. And without problems, there's no growth. So naturally I move toward the next thing that will challenge me again.

That feeling the discomfort, the struggle, the not knowing that's not a sign something is wrong. That's actually the sign that learning is happening.

I want to stay in that feeling as long as I can.

If I made any mistakes in this — please mention in the comments. I'll correct it.

Circuit Breaker Explained Through Real Failure Experience

Neel-Vekariya — Mon, 22 Jun 2026 06:33:06 +0000

In the past few days I faced something I didn't expect.

Features breaking one after another. Endpoints not working. Failures coming in a chain one failing, that causing another to fail, and that causing another. And I had no control over any of it. No way to stop it. No way to understand why it was happening. The failures just kept coming and my system kept getting more overloaded.

I won't lie I wanted to quit. Multiple times. I hit a point where I thought maybe this is not for me.

But there's something that keeps pulling me back. Curiosity. That one feeling of I want to understand this. I want to fix this. That's the fuel that kept me going even when I was completely frustrated.

And I gave it another chance. I sat with the problem again. And this time I found something that explained exactly what was happening and gave me a way to fix it.

That thing is called a circuit breaker.

What Was Actually Happening

Before I found this solution, my system was doing something really inefficient and I didn't even realize it.

Every time a service was failing, I was still sending requests to it. The service is down, failing, completely broken and I'm still passing requests through the router to it. Every single one of them failing. My server kept trying, resources kept getting consumed, and nothing was recovering. The failures were just piling up.

What I needed was a way to say okay, this service has failed too many times. Stop sending requests to it. Give it time to recover. Then try again carefully.

That's exactly what a circuit breaker does.

The Electrical Analogy

Think about an electrical circuit breaker in your home. When too much current flows something is overloaded, something is wrong the breaker trips. It opens the circuit. Power stops flowing. This protects everything from burning out.

Then after a while, you reset it carefully. If everything is fine, the circuit closes again and power flows normally.

Code circuit breakers work exactly the same way.

Three States: This is the Core Idea

CLOSED

Normal operation. All requests are allowed through. But failures are being tracked. If the number of failures crosses the threshold you set, the circuit opens.

OPEN

The circuit has tripped. All requests are blocked immediately. No function even runs. The system waits for the cooldown period to pass. This is the healing time your server recovers, the failing service gets time to come back up.

HALF_OPEN

After the cooldown, the circuit doesn't immediately go back to CLOSED. It moves to HALF_OPEN first. A limited number of requests are allowed through just enough to test whether the service has actually recovered. If those requests succeed, the circuit closes again and everything goes back to normal. If they fail, the circuit opens again and the cooldown starts over.

The Code


export class CircuitBreaker {
    constructor(failureThreshold, cooldownMs) {
        this.failureThreshold = failureThreshold
        this.cooldownMs = cooldownMs
        this.state = "CLOSED"
        this.failureCount = 0
        this.lastFailureTime = null
    }

    openCircuit() {
        this.state = "OPEN"
        this.lastFailureTime = Date.now()
    }

    closeCircuit() {
        this.state = "CLOSED"
        this.failureCount = 0
        this.lastFailureTime = null
    }

    halfOpenCircuit() {
        this.state = "HALF_OPEN"
    }

    async execute(fn) {
        if (this.state === "OPEN") {
            const cooldownExpired = Date.now() - this.lastFailureTime >= this.cooldownMs
            if (!cooldownExpired) {
                throw new ApiError(503, "Circuit is open.")
            }
            this.halfOpenCircuit();
        }

        try {
            const result = await fn()
            if (this.state === "HALF_OPEN") {
                this.closeCircuit()
            }
            return result;
        } catch (error) {
            if (this.state === "HALF_OPEN") {
                this.openCircuit()
                throw error;
            }
            this.failureCount++
            if (this.failureCount >= this.failureThreshold) {
                this.openCircuit()
            }
            throw error
        }
    }
}

Where This Actually Gets Used

This isn't just for one specific case. Any time your system depends on an external service that can fail, a circuit breaker makes sense.

Payment gateways. External APIs. Microservices talking to each other. Database connections. Third party integrations. All of these can fail temporarily. And without a circuit breaker, your system will keep hammering them even when they're down wasting resources, slowing everything else down, and making recovery harder.

What This Actually Fixed for Me

Before circuit breaker failures came in a chain. One service went down, requests kept hitting it, my system kept consuming resources on requests that were definitely going to fail, and everything got worse.

After circuit breaker the moment failures cross the threshold, the circuit opens. Requests stop hitting the failing service. The system gets breathing room. The service gets time to recover. And when it comes back, HALF_OPEN tests it carefully before trusting it again.

That frustration I had the failures I couldn't control, the system I couldn't stabilize all of it was because I had no mechanism to stop the bleeding when something went wrong.

Circuit breaker is that mechanism.

If I got something wrong or anything can be improved — please drop it in the comments. I'm still learning and I want to get this right.

Semaphore — How to Control How Many Operations Run at the Same Time

Neel-Vekariya — Wed, 17 Jun 2026 06:45:03 +0000

What if 100 requests hit your server at the same time and all of them try to connect to your database simultaneously?

I started thinking about this while building my project. I had worker threads running, multiple operations happening at once, and at some point I realized there's no control here. Everything is just running at the same time. No limit. No waiting. Just all of it, at once.
And that's a problem.

What the actual means

Think about a restaurant with only 10 tables.
100 people want to eat. But only 10 can sit at a time. The rest wait outside. When one table frees up, the next person in line comes in. Nobody rushes in randomly. There's order. There's control.

That's exactly what a semaphore does for your code.

A semaphore controls how many operations can run at the same time. If the limit is reached, the rest wait in a queue. When one operation finishes and releases its slot, the next one in the queue gets to run.

Why This Actually Matters

Without this kind of control, you can easily overwhelm a resource.

Your database has a connection limit. Your external API has a rate limit.

Your file system slows down if too many things try to write at the same time. If you just let everything run at once without any control, you're not managing your resources you're just hoping nothing breaks.

I kept seeing this pattern while building production-level infrastructure. Every piece of it has some form of concurrency control. Rate limiting for incoming requests. Connection pooling for databases. And semaphore for controlling how many operations run at a time inside your own system.

How the Semaphore Works

The implementation is simpler than it sounds.

export class Semaphore {
    constructor(maxConcurrent) {
        this.maxConcurrent = maxConcurrent
        this.current = 0
        this.queue = []
    }

    acquire() {
        return new Promise((resolve) => {
            if (this.current < this.maxConcurrent) {
                this.current++;
                resolve();
            } else {
                this.queue.push(resolve)
            }
        })
    }

    release() {
        this.current--;
        if (this.queue.length > 0) {
            this.current++;
            const next = this.queue.shift()
            next();
        }
    }

    async run(fn) {
        await this.acquire();
        try {
            return await fn()
        } finally {
            this.release()
        }
    }
}

Three parts. That's it.

acquire() — before an operation starts, it asks the semaphore for a slot. If a slot is available, it gets one and runs immediately. If not, it waits in the queue. That waiting is handled by a Promise that only resolves when a slot opens up.

release() — when an operation finishes, it gives the slot back. And if there's anything waiting in the queue, the next one gets the slot immediately.

run() — this is the wrapper you actually use. It acquires the slot, runs your function, and releases in a finally block. The finally is important it makes sure the slot is always released, even if the operation throws an error. No slot gets stuck.

What This Looks Like in Practice

Say you have 50 API calls to make but you only want 5 running at the same time.

const semaphore = new Semaphore(5);

const results = await Promise.all(
    requests.map(req => semaphore.run(() => callAPI(req)))
);

All 50 are queued up. But only 5 run at a time. As each one finishes, the next one in line starts. Controlled. Predictable. Your API doesn't get overwhelmed.

What I Realized

When I first wrote concurrent code, I just used Promise.all()and let everything run at the same time. It worked. Until it didn't.

The moment the load increased too many database connections, too many simultaneous operations,things started breaking. And I didn't understand why at first because the code looked fine.

That's the thing about concurrency. It's not just about making things run at the same time. It's about controlling how many things run at the same time. That control is what keeps your system stable under real load.
Semaphore is one of the simplest ways to add that control. And once you understand it, you start seeing places where you need it everywhere.

If I got something wrong or anything can be improved — please drop it in the comments. I'm still learning and I want to get this right.