DEV Community: Rakshyak Satpathy

"Works on My Machine" Is Not a Dev Strategy

Rakshyak Satpathy — Sun, 12 Apr 2026 16:51:16 +0000

New dev joins the team. Day 1: can't run the app 😅 Day 2: still can't run the app 💀 Day 3: senior dev drops everything to help 🫠 Sound familiar? I fixed this with Docker Compose and I'm never going back. Here's the full breakdown 🐳🔥

How I stopped losing half my day to environment issues and gave our team a production-like local stack that just works.

The Setup
I work on a property management system — the kind of software that hotels, hostels, and rental operators use to manage bookings, guests, room inventory, and payments. On the surface it sounds like a straightforward CRUD app. But in practice, a PMS is a web of interdependent services: a reservation API, a worker that processes booking events, a cache layer, a notification system, and a relational database holding years of critical guest and room data.
For a long time, running this system locally meant one thing: pain.

Part 1 — Why We Needed to Change

The "Works on My Machine" Graveyard

Every team reaches a point where the phrase "it works on my machine" stops being a joke and starts being a root cause in post-mortems. We reached that point.

Our team had three engineers, three different operating systems, and no agreed-upon way to run the stack locally. One person was on macOS with Node 18, another on Ubuntu with Node 20, and a third on Windows with WSL2. Dependency versions drifted silently. Environment variables were passed around in Slack DMs. npm install on a fresh clone would fail with cryptic native module errors that took an hour to debug — not because the code was wrong, but because the environment was wrong.

This is not a team problem. It is a systems problem. And it compounds fast.

The True Cost of Environment Inconsistency

Let's be honest about what we were actually losing. Every new engineer onboarding spent the better part of a day — sometimes two — just getting the app to run locally. Senior engineers would pair with them, pulling them away from actual feature work. The entire overhead was invisible in sprint planning because nobody tracked it as a cost.

Beyond onboarding, there was the subtler daily tax: environment-related bugs. A query that worked locally against a developer's personal Postgres instance would behave differently against staging because the database versions didn't match. Redis cache behavior differed between developers because some had it installed globally, some via Homebrew, and one was mocking it entirely. We were not testing the application; we were testing our individual setups.

Why a PMS Specifically Needs This Solved

A property management system is not a single service. It is at minimum:

A reservation API handling room availability, booking creation, and guest management
A worker service processing booking events — sending confirmation emails, updating inventory, triggering payment captures
A PostgreSQL database storing rooms, bookings, guests, pricing rules, and audit logs
A Redis instance acting as a job queue and session cache
A reverse proxy routing external requests to the right internal service

These components have hard dependencies on each other. The API cannot start without the database being ready. The worker cannot function without Redis. The proxy cannot route without both application services being up. Running these independently, manually, in the correct order, every single time a developer sits down to work — is a coordination problem that scales terribly.

The solution is not discipline. The solution is removing the coordination problem entirely.

Part 2 — The Problem Statement

What We Actually Needed

Before reaching for a tool, it is worth being precise about the problem.

We needed local environments that were:

Reproducible — same behavior across macOS, Linux, and Windows
Isolated — no dependency on globally installed software
Ordered — services that start in the correct sequence, automatically
Realistic — close enough to production that bugs caught locally stay caught
Fast to start — from a fresh clone to a running stack in under two minutes

We did not have any of this. What we had was a collection of README sections titled "Prerequisites" that slowly fell out of date, a global Postgres installation that lived only on one developer's machine, and a habit of keeping services running in background terminal tabs and praying nobody rebooted.

The Specific Failure Modes We Kept Hitting

Race conditions on startup. The API would try to connect to Postgres before Postgres had finished initializing. The fix was manually waiting, which meant either a sleep 5 in a shell script or just re-running the API and hoping. Neither is acceptable.

Seed data drift. Each developer had a slightly different local database state. Testing the same feature against different data produced different results, making it impossible to reproduce bugs reliably. "Send me your database dump" became a recurring request.

No queue visibility. The worker service processed jobs from Redis. Locally, most developers skipped Redis entirely and mocked the queue. This meant an entire class of bugs — failed retries, duplicate processing, stale jobs — was completely invisible until staging.

Onboarding friction as a product problem. When a new engineer cannot contribute for two days because of environment setup, that is not just a developer experience issue. It is a product velocity issue. It delays features, drains senior engineering time, and signals to new team members that the codebase is harder to work with than it needs to be.

Part 3 — The Solution and Migration Approach

Why Docker Compose

Docker Compose solves exactly the class of problem described above. It lets you define your entire application stack — every service, every dependency, every network connection, every volume — in a single declarative file. Running docker compose up becomes the one command that does everything.

More importantly, it makes the environment part of the codebase. The docker-compose.yml file lives in version control alongside the application code. When the Postgres version changes, that change is tracked, reviewed, and deployed consistently to every developer the next time they pull.

The Target Architecture

Before writing a single line of configuration, it helps to have a clear picture of what you are building.

The stack has five core services and two optional observability services:

Nginx sits at the edge, receiving traffic on port 80 and routing it to the appropriate internal service
Next.js API handles all reservation, room, and guest operations
Booking Worker is a Node.js process that consumes jobs from a Redis queue and handles side effects — emails, inventory updates, payment triggers
PostgreSQL is the source of truth for all relational data, seeded with realistic room and booking fixtures
Redis serves two roles: session cache for the API and job queue for the worker
Adminer is a lightweight database UI exposed only in development
Prometheus + Grafana form an optional observability layer for developers who want to understand service behavior under load

The Repository Structure

Keeping the project navigable matters. Here is the structure that works well:

pms-local-dev/
├── docker-compose.yml          # development stack
├── docker-compose.prod.yml     # production overrides
├── .env.example                # all variables documented, no secrets committed
├── Makefile                    # human-friendly command aliases
├── nginx/
│   └── nginx.conf              # routing rules, rate limiting
├── services/
│   ├── api/
│   │   ├── Dockerfile          # multi-stage: builder → runner
│   │   └── ...                 # Next.js application
│   └── worker/
│       ├── Dockerfile
│       └── ...                 # event processor
└── db/
    ├── seed.sql                # rooms, booking types, guest schema
    └── migrations/             # version-controlled schema changes

Step 1 — Write Multi-Stage Dockerfiles

The single biggest mistake in containerizing a Node.js application is treating the development image and the production image as the same thing. They are not.

A development image needs devDependencies, source maps, and a file watcher for hot-reload. A production image needs none of that. Shipping a production image with everything included is how you end up with a 900MB container that takes three minutes to pull in CI.

Multi-stage builds solve this cleanly:

# Stage 1: install all dependencies and build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: production image — only what runs
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/public ./public
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

In development, you override the command via Compose to run npm run dev and mount the source directory as a bind volume. The container runs, the watcher picks up file changes, and hot-reload works exactly as it would outside Docker — without the environment fragmentation.

Step 2 — Write the Compose File with Health Checks

This is the core of the solution. The key insight is the depends_on condition. By attaching a health check to each dependency service and using condition: service_healthy in the dependent service, you eliminate the startup race condition entirely. Postgres will be accepting connections before the API attempts its first query.

services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
      - ./db/seed.sql:/docker-entrypoint-initdb.d/seed.sql
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
      interval: 5s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 5

  api:
    build:
      context: ./services/api
      target: builder # use builder stage in dev for hot-reload
    volumes:
      - ./services/api:/app # bind mount for live code changes
      - /app/node_modules # anonymous volume prevents host modules overwriting container
    environment:
      DATABASE_URL: postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}
      REDIS_URL: redis://redis:6379
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    command: npm run dev

  worker:
    build:
      context: ./services/worker
    environment:
      DATABASE_URL: postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}
      REDIS_URL: redis://redis:6379
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - api

  adminer:
    image: adminer
    ports:
      - "8080:8080"
    depends_on:
      - postgres

volumes:
  pg_data:

A few things worth noting here. The pg_data named volume means your database persists across docker compose down and docker compose up cycles — you do not lose seed data every time you restart. The anonymous volume for node_modules is a subtlety that trips people up: without it, the host's node_modules (or lack thereof) would overwrite the container's, breaking native modules compiled inside the container.

Step 3 — Handle the Dev vs Production Split

You do not want Adminer, bind mounts, and the builder stage target in production. The cleanest way to handle this is a Compose override file.

docker-compose.prod.yml extends the base file and applies production-specific values:

services:
  api:
    build:
      target: runner # use the lean production stage
    volumes: [] # no bind mounts
    command: npm start
    restart: unless-stopped

  worker:
    restart: unless-stopped

  adminer:
    profiles:
      - dev # only runs if explicitly activated

In production or CI, you run:

docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

In development, you just run docker compose up. The override pattern keeps both worlds maintainable in the same repository without duplication.

Step 4 — Add a Makefile for Developer Ergonomics

Nobody should have to remember docker compose -f docker-compose.yml -f docker-compose.prod.yml up --build -d. A Makefile wraps the commands you actually use:

up:
    docker compose up --build

down:
    docker compose down

logs:
    docker compose logs -f

seed:
    docker compose exec postgres psql -U $$POSTGRES_USER -d $$POSTGRES_DB -f /docker-entrypoint-initdb.d/seed.sql

reset:
    docker compose down -v && docker compose up --build

shell-api:
    docker compose exec api sh

shell-db:
    docker compose exec postgres psql -U $$POSTGRES_USER -d $$POSTGRES_DB

Now onboarding is:

git clone <repo>
cp .env.example .env
make up

That is it. Three commands. No prerequisite installations. No version mismatches. No Slack DMs about which version of Postgres to use.

Step 5 — The Migration Path for Existing Teams

If you are retrofitting an existing PMS codebase rather than starting fresh, the migration does not need to happen all at once.

Week 1 — containerize the database only. Get Postgres and Redis running in Docker while keeping the application running natively. This alone solves the most common source of environment drift and is the lowest-risk change. Developers connect to localhost:5432 as before — nothing about the application changes.

Week 2 — containerize the worker. The worker is usually stateless and has no hot-reload requirements, making it the easiest service to containerize fully. Move it into Docker and verify it processes jobs from the Redis container correctly.

Week 3 — containerize the API. This is the most involved step. Set up the multi-stage Dockerfile, configure bind mounts for hot-reload, and verify the development experience matches what developers had before. Test on all three operating systems your team uses.

Week 4 — add Nginx and the Makefile. Complete the stack with the reverse proxy, verify the full startup sequence with health checks, document the commands in the Makefile, and update the README.

This incremental approach means you can stop at any step if something is blocking, and you get value from each step independently. The full stack is the goal, but you do not need to pause feature work to get there.

Fixing Kafka Connectivity Issues Between Node.js and Docker Containers

Rakshyak Satpathy — Sun, 16 Feb 2025 20:22:25 +0000

Introduction

Apache Kafka is a powerful event streaming platform, but setting it up in a Docker environment while ensuring seamless connectivity with an external Node.js service can be challenging. This article explores two key challenges:

Connecting a Local Node.js Server as an External Host Machine with a Kafka Broker in Docker
Understanding and Fixing Docker DNS Resolution Issues for Local Machine Communication

We'll walk through the problems faced, their root causes, and step-by-step solutions.

Setting Up Kafka in a Docker Container

We are using Bitnami's Kafka image, which supports KRaft mode (Kafka's built-in metadata management) without requiring ZooKeeper.

1. Create a Docker Network

To ensure seamless communication between services, create a dedicated network:

docker network create app-tier

2. Run Kafka in KRaft Mode

docker run -d --name kafka-server -p 9092:9092 --hostname kafka-server \  
    --network app-tier \  
    -e KAFKA_CFG_NODE_ID=0 \  
    -e KAFKA_CFG_PROCESS_ROLES=controller,broker \  
    -e KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093 \  
    -e KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT \  
    -e KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://192.168.1.10:9092 \  
    -e KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=0@kafka-server:9093 \  
    -e KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER \  
bitnami/kafka:latest

Understanding `advertised.listeners`

listeners=PLAINTEXT://:9092 → Kafka listens on all interfaces inside the container.
advertised.listeners=PLAINTEXT://192.168.1.10:9092 → External clients connect using the host machine's IP.

This prevents Kafka from advertising its internal container IP, which would make it unreachable from the local machine.

Challenge 1: Connecting a Local Node.js Server to Docker Kafka

By default, a Docker container runs in an isolated network. This means localhost:9092 inside the container does not refer to the host machine’s localhost. If a Node.js service runs outside Docker, it cannot connect to Kafka using localhost:9092 unless Kafka explicitly advertises the host machine's IP.

Solution: Use the Host IP

Find your machine's IP address:

ip a | grep inet

Then, update Kafka’s advertised.listeners to point to this IP.

Challenge 2: Docker DNS Resolution and Communication

Even after setting the correct advertised.listeners, issues may arise if:

Kafka and Node.js services are on different networks.
Docker’s DNS resolution prevents local services from reaching Kafka.

Solution: Use Docker’s Built-in DNS

Containers in the same network can resolve each other by name.
Use kafka-server:9092 inside Docker.
Use 192.168.1.10:9092 outside Docker.

Fixing Docker Name Resolution for Node.js

If your Node.js service runs inside a container, ensure it is in the same network:

docker network connect app-tier nodejs-container

Then, use:

const kafka = new Kafka({
    clientId: 'cart.service',
    brokers: ['localhost:9092'],
    retry: { retries: 3 }
});

Final Working Node.js Kafka Integration

Kafka Producer & Consumer Code

import express from "express";
import { Kafka, Partitioners } from "kafkajs";

const app = express();
app.use(express.json());

const kafka = new Kafka({
    clientId: 'cart.service',
    brokers: ['localhost:9092'],
    retry: { retries: 3 }
});

const producer = kafka.producer({ createPartitioner: Partitioners.DefaultPartitioner });
const consumer = kafka.consumer({ groupId: 'cart.service' });

const runConsumer = async () => {
    await consumer.connect();
    await consumer.subscribe({ topic: "cart.item.add" });
    await consumer.run({
        eachMessage: async ({ message }) => {
            console.log("Received message:", message.value?.toString());
        }
    });
};

runConsumer().catch(console.error);

export const kafkaProducer = async (topic: string, message: Record<string, any>) => {
    await producer.connect();
    await producer.send({
        topic,
        messages: [{ value: JSON.stringify(message) }]
    });
};

app.get("/health-check", (_, res) => res.send("OK"));

app.post("/cart", async (req, res) => {
    const { productId, quantity } = req.body;
    await kafkaProducer("cart.item.add", { productId, quantity });
    res.send("OK");
});

app.listen(3000, () => console.log("Cart service is running on port 3000"));

app.on("close", async () => {
    await consumer.disconnect();
    await producer.disconnect();
});

Conclusion

By addressing Kafka’s networking challenges in Docker, we ensured seamless communication between a local Node.js service and a Kafka broker running in a container. Key takeaways:

✅ Use advertised.listeners to expose Kafka correctly
✅ Leverage Docker DNS for intra-container communication
✅ Ensure Kafka and Node.js services are in communication with the docker container kafka broker

Photo by Mélanie THESE on Unsplash

🏗️ Building an Inventory Management System with Robust Error Handling in Node.js

Rakshyak Satpathy — Fri, 14 Feb 2025 15:15:01 +0000

Introduction

🚀 Building a reliable inventory management system isn’t just about storing and retrieving data—it’s about ensuring your application gracefully handles errors. Imagine a customer trying to update inventory with negative stock or incorrect pricing. Without proper error handling, things could go very wrong! 😱

In this guide, we’ll walk through a real-world CRUD implementation using Node.js, Express, and MongoDB, all while exploring best practices for error handling. And to make things fun, let’s check in with our two developers: Junior Dev 👶 and Senior Dev 🧙‍♂️

👶 Junior Dev: “Why do I even need to handle errors? Can’t I just let the server explode?”

🧙‍♂️ Senior Dev: “Sure, and then watch as your customers rage-quit your app! Let me show you how to do it right.”

🛠️ Setting Up the Project

First, let’s create our project and install the necessary dependencies:

mkdir inventory-management
cd inventory-management
npm init -y
npm install express mongoose dotenv

👶 Junior Dev: “Done! Now what?”

🧙‍♂️ Senior Dev: “Now we define the inventory model. And no, you can’t store ‘infinite’ items in your database.”

🏗️ Defining the Inventory Model

Every inventory item needs a name, quantity, and price. To enforce data integrity, we define a schema with validation rules:

const mongoose = require('mongoose');

const inventorySchema = new mongoose.Schema({
    name: { type: String, required: true },
    quantity: { type: Number, required: true, min: 0 },
    price: { type: Number, required: true, min: 0 }
});

const Inventory = mongoose.model('Inventory', inventorySchema);

module.exports = Inventory;

👶 Junior Dev: “Wait, why do I need ‘min: 0’? Can’t I just check it later?”

🧙‍♂️ Senior Dev: “Because catching bad data early means fewer fires to put out later! 🔥”

🚀 Setting Up the Express Server

Our server will connect to MongoDB and handle API requests:

require('dotenv').config();
const express = require('express');
const mongoose = require('mongoose');
const inventoryRoutes = require('./routes/inventory');

const app = express();
app.use(express.json());
app.use('/api/inventory', inventoryRoutes);

mongoose.connect(process.env.MONGO_URI, { useNewUrlParser: true, useUnifiedTopology: true })
    .then(() => app.listen(3000, () => console.log('🚀 Server running on port 3000')))
    .catch(err => console.error('❌ Database connection error:', err));

👶 Junior Dev: “Cool! So if something breaks, the server just dies, right?”

🧙‍♂️ Senior Dev: “NO! We handle errors properly. Let’s implement CRUD operations with structured error handling.” 😤

📝 Implementing CRUD Operations with Error Handling

API Routes (`routes/inventory.js`)

const express = require('express');
const router = express.Router();
const Inventory = require('../models/Inventory');

// Custom Error Class
class ValidationError extends Error {
    constructor(message) {
        super(message);
        this.name = 'ValidationError';
    }
}

// Create an Item
router.post('/', async (req, res) => {
    try {
        const { name, quantity, price } = req.body;
        if (!name || quantity < 0 || price < 0) {
            throw new ValidationError('Invalid input data');
        }
        const item = new Inventory({ name, quantity, price });
        await item.save();
        res.status(201).json(item);
    } catch (err) {
        handleErrors(res, err);
    }
});

// Centralized Error Handling Function
function handleErrors(res, err) {
    if (err instanceof ValidationError) {
        res.status(400).json({ error: err.message });
    } else {
        res.status(500).json({ error: 'Internal Server Error' });
    }
}

module.exports = router;

👶 Junior Dev: “Why do we need this fancy error class? Can’t I just console.log errors?” 🤔

🧙‍♂️ Senior Dev: “If you do that, debugging production errors will be a nightmare! This way, we categorize issues properly.” 🎯

💡 Why This Approach Works

Handling errors properly improves reliability and usability. Here’s how we achieve that:

✅ Prevention First – Validate data before it enters the database.

✅ Clear Error Messages – Users get meaningful errors instead of cryptic system messages.

✅ Custom Error Handling – Distinguish between validation errors and system errors.

✅ Consistent API Responses – Every response follows the same structured format.

👶 Junior Dev: “Alright, I see the point. But what happens when I forget to handle an error?” 😬

🧙‍♂️ Senior Dev: “That’s when production crashes at 2 AM, and your phone won’t stop ringing.” 📞🔥

🎯 Wrapping Up

A well-structured inventory management system isn’t just about CRUD operations—it’s about making sure errors are handled smartly. This makes your application more resilient and easier to maintain.

Start integrating these techniques into your projects today, and you’ll write cleaner, more professional code. And remember—always handle errors before they handle you! ⚡

👶 Junior Dev: “Thanks, sensei! Now I won’t fear errors anymore.” 😎

🧙‍♂️ Senior Dev: “Good. Now go forth and build error-free apps… or at least fewer 500 errors.” 😉

Cover Photo by Uriel Soberanes on Unsplash

design pattern in react

Rakshyak Satpathy — Fri, 31 Jan 2025 10:10:54 +0000

Avoiding State Inconsistencies: The Pitfall of Multiple React Context Providers

Rakshyak Satpathy — Fri, 31 Jan 2025 09:56:40 +0000

The Hidden Pitfall of Using Multiple Context Providers in React

Introduction

React Context API is a powerful tool for managing state across components. However, a common mistake developers make is wrapping different sections of their app with separate instances of the same Context Provider, leading to unexpected behavior.

In this post, we’ll explore why this happens, its impact, and the correct way to use Context to avoid these pitfalls.

The Mistake: Multiple Instances of the Same Provider

Consider this React component structure:

<CartProvider>
  <Navbar />
</CartProvider>

<h1 className="text-4xl font-semibold mt-20">Products</h1>

<CartProvider>
  <div className="flex gap-4">
    <Products products={products} />
    {/* <Cart /> */}
  </div>
</CartProvider>

At first glance, this looks fine. But there’s a major issue: each <CartProvider> creates a new, separate context instance. This means:

The Navbar is inside the first <CartProvider>, while Products is inside another.
When Products updates the cart, the change is only reflected inside its provider.
The Navbar, wrapped in a separate provider, does not see these updates.

This results in an inconsistent UI, where the cart count in the Navbar does not update when products are added.

Why This Happens

React Context works by creating a Provider that passes state down to its children. However, each Provider instance manages its own independent state. When you wrap different sections of your UI in separate <CartProvider> components, they function as isolated stores rather than a shared state.

How Context Providers Work Internally

Each <CartProvider> creates its own state using useState or useReducer.
The context value (cart, setCart) is unique to that instance.
Consumers (useContext(CartContext)) only receive updates from the nearest provider.

Thus, if you have two providers, they do not share state, leading to desynchronized data across components.

The Correct Approach: A Single Context Provider

To ensure all components share the same state, wrap the entire app (or the relevant section) inside one <CartProvider>:

<CartProvider>
  <Navbar />
  <h1 className="text-4xl font-semibold mt-20">Products</h1>
  <div className="flex gap-4">
    <Products products={products} />
    {/* <Cart /> */}
  </div>
</CartProvider>

Why This Works

✔️ Single source of truth: All components access the same CartContext instance.
✔️ State updates propagate correctly: When Products updates the cart, Navbar reflects the changes.
✔️ Better performance: Reduces unnecessary re-renders from multiple context providers.
✔️ Easier debugging: Avoids confusion caused by desynchronized states.

How to Detect This Issue in Your App

If you suspect multiple context providers are causing state inconsistencies, try these debugging steps:

1. Log the Context Value

Add a console.log inside a component consuming the context:

const cart = useContext(CartContext);
console.log("Cart context: ", cart);

If you see multiple logs with different values, you likely have multiple providers.

2. Use React DevTools

Open React Developer Tools.
Look for multiple <CartProvider> instances.
Check if different components are consuming different instances.

Conclusion

Using multiple instances of the same Context Provider in different sections of your app breaks state synchronization. To avoid this:

Use a single provider for globally shared state.
Ensure all consumers are wrapped under the same provider.
Use debugging tools to detect multiple providers.

By structuring your Context usage correctly, you ensure a predictable, seamless state management experience in your React applications.

Have you faced issues with React Context before? Share your experience in the comments!

say thanks for the image RichardsDrawings

Understanding Stream Methods in Node.js: A Guide to `read` and `write`

Rakshyak Satpathy — Sat, 16 Nov 2024 05:50:18 +0000

Node.js provides powerful stream capabilities that allow developers to handle data efficiently. By utilizing stream methods like read and write alongside event listeners, developers can effectively consume streams. This article will delve into the mechanics of streams, focusing on the interplay between readable and writable streams, backpressure management, and error handling.

Stream Basics

In Node.js, streams are objects that facilitate reading and writing data in a continuous manner. They can be classified into four types: readable, writable, duplex (both readable and writable), and transform (a type of duplex stream that can modify data as it is read or written).

Example of Using `read` and `write`

The following code snippet demonstrates how to use readable and writable streams together:

readable.on('data', chunk => {
    writable.write(chunk);
});

readable.on('end', () => {
    writable.end();
});

In this example:

The data event is emitted when there is data available to read from the readable stream. Each chunk of data is written to the writable stream.
The end event signifies that there are no more data chunks to read, prompting the writable stream to end.

Understanding Stream Pressure

The rate at which data flows through a stream is referred to as pressure. When a writable stream processes data at a slower rate than a readable stream pushes data, it leads to backpressure. This situation occurs when the writable stream's buffer fills up, causing it to temporarily stop accepting new data until it can process the buffered data.

Handling Backpressure

When managing backpressure, it's crucial to check the return value of the write method:

If the writable stream can accept more data, write returns true.
If the memory limit is reached, it returns false, indicating that further writes should pause until the drain event is emitted.

if (!writable.write(chunk)) {
    // Stop reading from the readable stream until drain event
    readable.pause();
}

writable.on('drain', () => {
    // Resume reading from the readable stream
    readable.resume();
});

Error Handling in Streams

Streams can emit errors at any time, making it essential to handle them properly. This is particularly important when using the pipe method, which automatically manages data flow between streams.

Example of Error Handling

Here’s how you can handle errors for both readable and writable streams:

readable.pipe(writable);

readable.on('error', (err) => {
    console.error('Read error:', err);
});

writable.on('error', (err) => {
    console.error('Write error:', err);
});

By listening for the error event on both streams, you ensure that any issues encountered during reading or writing are appropriately managed.

Why Developers Choose Databases Over File Storage for Scalable Data Management💾 ➡️ 🗄️

Rakshyak Satpathy — Sun, 03 Nov 2024 08:26:27 +0000

As data grows, developers often shift from simple file storage to databases. Let’s dive into why databases make managing data easier and more reliable for coding projects.

1. Data Consistency and ACID Compliance 🔄

Most databases are ACID-compliant (Atomicity, Consistency, Isolation, Durability), meaning they provide reliable data handling, which is challenging with file storage.

Fact: ACID compliance allows a database to handle billions of transactions daily without errors. Many financial services rely on ACID compliance to ensure accuracy.

2. Indexing for Faster Data Retrieval 📈

Databases have built-in indexing to speed up data retrieval by creating optimized access paths.

Fact: Indexing can improve query speeds by over 100x in large datasets. Without indexing, complex searches on millions of entries would take hours instead of seconds.

3. Concurrency Control for Multi-User Access 👥

Databases offer concurrent access features, allowing multiple users or processes to interact with data simultaneously.

Fact: Databases like PostgreSQL and MySQL support thousands of simultaneous users, thanks to concurrency control mechanisms, ensuring data integrity under heavy loads.

4. Optimized Storage and Query Processing 🗃️

Databases store data in optimized formats (e.g., binary storage, columnar storage for analytics), which allows for fast retrieval and efficient use of storage.

Fact: Columnar databases, popular in data analytics, can reduce storage by up to 90% and accelerate aggregation queries by processing only necessary columns.

5. SQL for Flexible Data Queries 📝

SQL provides flexible, powerful commands to quickly search, update, and analyze data.

Fact: SQL, invented in the 1970s, is still the dominant query language for databases. Around 80% of data management jobs list SQL as a required skill due to its efficiency in handling complex data operations.

6. Automated Data Integrity and Constraints ✅

Databases enforce constraints (like primary keys and unique constraints) to maintain data relationships and integrity.

Fact: In MySQL, constraints reduce coding errors and increase database reliability, enabling developers to store millions of unique values without duplicates.

7. Built-in Backup, Replication, and Recovery 🔄

Database systems come with automated backup, replication, and recovery options, ensuring high availability and data safety.

Fact: Many databases support replication, creating multiple synchronized copies of data across locations to prevent data loss and reduce downtime, which is crucial for business continuity.

For developers, databases offer reliable performance, reduced coding complexity, and scalability—all critical for data-intensive applications in a coding environment.

How SSH-Agent Transforms SSH Authentication into a Breeze

Rakshyak Satpathy — Sat, 12 Oct 2024 16:01:04 +0000

🤔 "SSH-Agent: Because typing your passphrase every time is so 2001!"

What is SSH-Agent?

SSH-Agent is a utility that securely manages your SSH keys and automates the authentication process for SSH connections. It eliminates the need to type in your passphrase each time you connect to a server.

Real-World Example: Setting Up SSH-Agent for Accessing a Remote Server

Let’s walk through the exact steps to configure SSH-Agent on a local machine (Linux/macOS) and connect to a remote server using a private key.

1. Generate an SSH Key Pair (If You Don't Have One)

Before using SSH-Agent, you need to create an SSH key pair (public and private). Here’s how you can do that:

Open your terminal.
Run this command to create a new key pair:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Press Enter to accept the default file location (~/.ssh/id_rsa).
Set a strong passphrase (optional but recommended) for your private key.

This will create two files:

id_rsa (your private key)
id_rsa.pub (your public key)

2. Start the SSH-Agent

Now that your SSH key is created, let’s start the SSH-Agent.

Run the following command in your terminal to start the agent:

eval $(ssh-agent -s)

This will start the SSH agent and display the agent's process ID.

3. Add Your Private Key to the SSH-Agent

Next, you’ll add the private key to the agent so it can be used for authentication:

Add the private key to the SSH-Agent:

ssh-add ~/.ssh/id_rsa

You’ll be prompted for the passphrase you set earlier (if you set one).

4. Copy Your Public Key to the Remote Server

You need to place your public key on the remote server where you want to connect. Here’s a simple way to do that:

Use the ssh-copy-id command to copy your public key:

ssh-copy-id user@remote-server

Replace user with your remote server’s username and remote-server with the server's IP address or hostname.

You may be prompted to enter the password for the remote user. Once this is done, the server will have your public key, and you can authenticate using your private key.

5. Connect to the Remote Server Using SSH

Now you can SSH into the remote server without typing the passphrase every time:

ssh user@remote-server

SSH-Agent will automatically use the private key stored in memory for authentication.

6. Forwarding Your SSH-Agent (Optional)

If you need to access another server from the first one, you can forward your SSH keys. This means the remote server will use your local machine's SSH-Agent.

To enable forwarding, simply add the -A flag when connecting:

ssh -A user@remote-server

This ensures that the keys are forwarded to the remote machine.

Summary of Commands

Generate SSH Key:

   ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Start SSH-Agent:

   eval $(ssh-agent -s)

Add Private Key:

   ssh-add ~/.ssh/id_rsa

Copy Public Key to Remote Server:

   ssh-copy-id user@remote-server

SSH into Remote Server:

   ssh user@remote-server

SSH with Key Forwarding (Optional):

   ssh -A user@remote-server

SSH-Agent is like your personal valet for remote server connections—it takes care of the key authentication so you don’t have to. No more typing in your passphrase every time you SSH into a server! This guide will walk you through setting it up, and before you know it, you’ll be breezing through connections like a pro.

Fun Fact: Did you know that SSH (Secure Shell) was originally developed in 1995 as a secure way to replace old, insecure protocols? And now, thanks to SSH-Agent, we don’t even have to think about it! 😎

Data Manipulation with Strings and Arrays in Bash

Rakshyak Satpathy — Sun, 06 Oct 2024 17:17:11 +0000

When it comes to data manipulation in Bash, there’s a broad array of techniques that you can apply, building on foundational skills. This post will explore practical approaches to manipulating data structures like arrays and strings using Bash. It also covers some advanced techniques such as parsing character-delimited records, reading data files, and using Bash’s parameter expansion to manipulate data.

Key Concepts Covered:

Arrays in Bash
Parameter Expansion
Parsing Data with Character Delimiters
Reading Data Files
Functions for Two-Dimensional Grids
Sorting and Searching Arrays

What you will from this:

Data manipulation in Bash, particularly with strings and arrays, offers flexibility in handling structured and unstructured data. From parsing character-delimited records to simulating two-dimensional grids, the power of Bash scripting comes from its ability to handle various data types efficiently.

These techniques can help you create robust Bash scripts to automate data manipulation tasks. For freshers, mastering these concepts can help in building a strong foundation for more complex automation scripts.

1. Arrays in Bash

Arrays are essential in Bash scripting, allowing you to store and manipulate lists of values efficiently. While you may already know the basic syntax (covered in Chapter 5), it’s time to dive deeper into their uses for handling more complex data.

Example:

# Declaring an array
my_array=(apple orange banana)

# Accessing array elements
echo ${my_array[1]}   # Outputs: orange

Arrays can store lists of data, making them useful for organizing and processing sequences of items.

Advantages of Arrays:

Easy to store multiple values
Faster data manipulation in sequential operations

Disadvantages:

Limited to numerical indices (can’t use keys like in dictionaries)
Lacks complex data structures like other programming languages

2. Parameter Expansion for Data Parsing

Parameter expansion offers many ways to manipulate strings and arrays in Bash, such as slicing, substitution, and removing patterns. Though used across many Bash scripts, it’s crucial for data parsing, especially when handling character-delimited data.

Example: Splitting a String by Delimiters

string="apple,orange,banana"
IFS=',' read -r -a array <<< "$string"

# Outputs each element in the array
for element in "${array[@]}"; do
  echo $element
done

This approach splits a comma-separated string into an array, a common scenario when dealing with CSV or other delimited data files.

3. Parsing Character-Delimited Records

When dealing with data structured as character-delimited records (e.g., CSV), parsing them into individual fields allows for easier processing. Arrays and loops in Bash make this task simple.

Example: Parsing CSV Data

while IFS=',' read -r col1 col2 col3; do
  echo "Col1: $col1, Col2: $col2, Col3: $col3"
done < file.csv

This reads each line in a CSV file and splits it into separate columns, which can be manipulated as individual fields.

4. Reading Data Files in Bash

One common use of Bash is processing data from files. Whether you are reading structured data like CSV files or unstructured text, understanding how to read and process files is a must.

Example: Reading a File Line by Line

while IFS= read -r line; do
  echo "$line"
done < file.txt

This loop reads each line of a file, making it useful for file parsing and manipulation.

5. Functions for Two-Dimensional Grids

Manipulating two-dimensional data structures like tables or grids can be done using arrays of arrays. Though Bash doesn’t natively support two-dimensional arrays, you can simulate them using associative arrays or nested arrays.

Example: Simulating 2D Array

declare -A matrix
matrix[0,0]="apple"
matrix[0,1]="orange"
matrix[1,0]="banana"
matrix[1,1]="grape"

echo "${matrix[0,1]}"  # Outputs: orange

6. Sorting and Searching Arrays

For sorting and searching arrays, Bash provides utilities like sort and grep which allow you to manipulate data quickly.

Example: Sorting an Array

my_array=(banana apple grape orange)
sorted_array=($(echo ${my_array[@]} | tr ' ' '\n' | sort))

echo ${sorted_array[@]}  # Outputs: apple banana grape orange

Searching an Array

You can search arrays for specific elements using loops or grep:

if [[ " ${my_array[@]} " =~ " apple " ]]; then
  echo "Apple found!"
fi

GitHub Workflow and Automation: Streamlining Project Management 🚀

Rakshyak Satpathy — Sun, 29 Sep 2024 16:12:16 +0000

Introduction

While GitHub offers powerful workflow automation for free, surprisingly, only a small percentage of users take full advantage of it. Despite this, the learning curve is minimal, and GitHub has made the integration of workflows straightforward, even for beginners. By using workflows effectively, teams can automate repetitive tasks, streamline project management, and improve productivity without additional cost. 🌟

How to Automate with GitHub Actions

GitHub Actions enables you to automate your workflows based on specific events in your repository. Here’s how to get started:

Step 1: Create a GitHub Action

Navigate to your repository on GitHub.
Click on the Actions tab.
Choose a template or click on set up a workflow yourself.

Step 2: Define Your Workflow

Create a YAML file (e.g., main.yml) in the .github/workflows directory of your repository. Here’s a simple example:

name: CI

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

Explanation:

This workflow runs on every push to the main branch.
It checks out the code using the checkout action.

For more help on setting up GitHub Actions, click here.

Using Webhooks for Automation

Webhooks allow you to send real-time data from one application to another whenever an event occurs. Here’s how to set up a Webhook in your GitHub repository:

Step 1: Create a Webhook

Go to your repository settings.
Click on Webhooks in the sidebar.
Click on Add webhook.

Step 2: Configure the Webhook

Payload URL: Enter the URL where you want to receive the webhook payload.
Content type: Select application/json.
Which events would you like to trigger this webhook? Choose the events that trigger the webhook (e.g., push, issues).

Example Webhook JSON Payload:

{
  "action": "opened",
  "issue": {
    "title": "Issue Title",
    "body": "Issue body content"
  }
}

Explanation:

This payload is sent when an issue is opened, containing details about the issue.

For detailed instructions on setting up Webhooks, click here.

Focus on GitHub Project Feature Integration

GitHub Projects allow you to manage your work with Kanban-style boards. Here’s how to integrate an automation workflow with GitHub Projects.

Automation Workflow

Creating a Task Template in "To Do" Column:
- When someone creates a task in the "To Do" column, automate the generation of a task template. This template will include:
  - References for the task
  - Specific requirements
  - Author name
  - File attachments

You can use GitHub Actions to achieve this. An example YAML configuration might look like this:

   name: Create Task Template

   on:
     project_card:
       created:
         types: [moved]

   jobs:
     create_template:
       runs-on: ubuntu-latest
       steps:
         - name: Create Template
           run: echo "Create your template here!"

Creating an Issue and Branch in "In Progress" Column:
- When someone moves a task to the "In Progress" column, automate the creation of a new issue and branch. The issue title will be the task title, and the branch name follows this convention:
```
 feature-{date of issue created}/issue-title-{issue number}
```

Example workflow snippet for creating an issue might be:

   name: Create Issue and Branch

   on:
     project_card:
       moved:
         from: "To Do"
         to: "In Progress"

   jobs:
     create_issue_and_branch:
       runs-on: ubuntu-latest
       steps:
         - name: Create Issue
           run: |
             echo "Create issue with title ${{ github.event.project_card.note }}"
             echo "Create branch with naming convention"

Conclusion

Understanding and utilizing GitHub workflows can significantly enhance your project management capabilities. By automating tasks and integrating features like GitHub Actions and Webhooks, you can streamline your development process efficiently. As a fellow developer, I encourage freshers to explore these tools and reach out with any questions or for guidance. 🌟🚀

Understanding How Your OS Handles Print Requests to the Console 🖥️

Rakshyak Satpathy — Fri, 27 Sep 2024 15:40:08 +0000

When you run a program and ask it to print something to the console, have you ever wondered what happens behind the scenes? 🤔 In this post, we’ll dive into the fascinating world of standard output (stdout) and how your operating system (OS) manages these requests.

What is Standard Output? 📢

Standard Output (stdout) is a predefined channel through which programs send their output data. It’s like a direct line to your console or terminal, allowing you to see results, messages, and more.

File Descriptor: In most systems, stdout is represented by the file descriptor 1. In C programming, it’s represented by FILE* stdout.

Why Use Standard Output?

Using stdout allows programmers to communicate with users effectively. It separates regular output from error messages, making it easier to debug applications.

How Does the OS Handle Output Requests? ⚙️

1. Buffering: The Efficiency Booster 🚀

When you print something, the OS doesn’t immediately send it to the console. Instead, it uses buffering to improve performance. By default:

Line-buffered: In interactive environments (like terminals), data is sent when a newline character (\n) is encountered.
Flushing: You can manually flush the buffer to force output to appear immediately.

Example in C:

#include <stdio.h>

int main() {
    printf("Hello, World!\n"); // This will be buffered until the newline.
    fflush(stdout); // Forces the buffer to flush.
    return 0;
}

Example in Python:

print("Hello, World!") # Automatically flushed when a newline is printed.
import sys
sys.stdout.flush() # Manually flushes stdout if needed.

2. Redirection: Flexibility at Its Best 🔄

One of the powerful features of stdout is its ability to be redirected. This means you can send output not just to the console but also to files or other devices.

How to Redirect Output:

In the Terminal: You can run your program and redirect output like this:

  ./your_program > output.txt

This command sends all stdout data to output.txt instead of displaying it on the console.

3. Error Handling: Keeping Things Separate ⚠️

Alongside stdout, there’s also Standard Error (stderr) for error messages. Stderr operates similarly but is typically unbuffered. This means that error messages appear immediately, even if stdout is redirected.

Conclusion: The Magic Behind Printing 🎩✨

When you request a print in your program, the OS plays a crucial role in managing that request through standard streams. By understanding how stdout works—through buffering, redirection, and error handling—you can write more efficient and user-friendly applications.

Resources for Further Learning 📚

C Programming Language: Learn C
Python Documentation: Python Official Docs
Unix/Linux Redirection: Linux Command Line

Feel free to explore these resources and enhance your understanding of standard output and its management by the operating system!

Happy coding! 💻✨

Unlocking the Power of Git Worktree: A Game-Changer for Developers 🚀

Rakshyak Satpathy — Thu, 19 Sep 2024 17:54:04 +0000

As developers, we often find ourselves juggling multiple branches, features, and bug fixes. Enter Git Worktree—a feature that has transformed the way I manage my projects and has the potential to do the same for you! Here’s a deep dive into what I’ve learned about this incredible tool and how it can elevate your Git game.

🌳 What is Git Worktree?

Imagine being able to work on multiple branches simultaneously without the hassle of constantly switching contexts or worrying about conflicts. Git Worktree allows you to create additional working trees linked to a single repository. This means you can have separate directories for different branches, all while sharing the same underlying Git database. It’s like having multiple branches of a tree, each flourishing in its own space!

🔄 Seamless Branch Switching

One of the standout features of Git Worktree is the ability to switch between branches effortlessly. Instead of waiting for lengthy checkouts or risking merge conflicts, you can simply create a new worktree for each branch. Here’s how to do it:

# Start by creating a new branch
git checkout -b feature/new-awesome-feature

# Now create a worktree for another branch
git worktree add ../new-feature-worktree feature/new-awesome-feature

Now you can navigate to ../new-feature-worktree and start working on your feature without interrupting your main development flow!

💾 Save Space, Stay Efficient

Worried about disk space? Fear not! Since all worktrees share the same object database, you won’t be duplicating data unnecessarily. This makes Git Worktree not only efficient but also a great option for those working on larger projects where every megabyte counts.

🛠️ Streamline Your Workflow

Imagine being able to run tests on one branch while developing features on another—all without any interruptions. With Git Worktree, this becomes a reality. You can easily rebase, merge, and push changes independently in each worktree. Here’s an example:

# In your main worktree, let's say you're on the main branch
git checkout main

# Meanwhile, in your new worktree for the feature branch
cd ../new-feature-worktree
# Make changes and commit them
git add .
git commit -m "Implement new awesome feature"

This flexibility allows you to maintain focus and productivity, no matter how complex your project becomes.

📚 A Learning Playground

Git Worktree isn’t just a productivity tool; it’s also an excellent learning resource. By creating worktrees for different branches or commits, you can experiment freely without fear of messing up your main project. Want to see how a feature evolved? Jump into its worktree and explore!

For instance:

# Create a worktree from an older commit to analyze changes
git worktree add ../old-version-worktree <commit-hash>

This hands-on approach deepens your understanding of Git and enhances your coding skills.

🌟 Why You Should Try It

If you haven’t yet explored Git Worktree, I encourage you to give it a shot! Not only will it simplify your workflow, but it will also open up new avenues for collaboration and experimentation. Whether you’re tackling a complex project or just want to streamline your daily tasks, Git Worktree is a tool that deserves a place in your development toolkit.

🤔 What Are Your Thoughts?

Have you used Git Worktree before? What insights or tips do you have to share? Let’s spark a conversation in the comments below! Together, we can master this powerful feature and elevate our coding journeys. Happy coding! 💻✨

Special Thanks👏👏👏👏

A huge thank you to the amazing developers and contributors in the Git community who brought us the Git Worktree feature! Your hard work and dedication have made it easier for developers like me to manage multiple branches seamlessly.
Special mention to ThePrimeagen, whose engaging tutorials and insights on Git have helped countless developers enhance their skills.
If you haven't checked out his content yet, you're missing out! His course on mastering Git is a must-watch for anyone looking to level up their version control game.
Keep up the great work, everyone! Let's continue to learn and grow together in this incredible coding journey! 💻✨

DEV Community: Rakshyak Satpathy

"Works on My Machine" Is Not a Dev Strategy

Part 1 — Why We Needed to Change

The "Works on My Machine" Graveyard

The True Cost of Environment Inconsistency

Why a PMS Specifically Needs This Solved

Part 2 — The Problem Statement

What We Actually Needed

The Specific Failure Modes We Kept Hitting

Part 3 — The Solution and Migration Approach

Why Docker Compose

The Target Architecture

The Repository Structure

Step 1 — Write Multi-Stage Dockerfiles

Step 2 — Write the Compose File with Health Checks

Step 3 — Handle the Dev vs Production Split

Step 4 — Add a Makefile for Developer Ergonomics

Step 5 — The Migration Path for Existing Teams

Fixing Kafka Connectivity Issues Between Node.js and Docker Containers

Introduction

Setting Up Kafka in a Docker Container

1. Create a Docker Network

2. Run Kafka in KRaft Mode

Understanding advertised.listeners

Challenge 1: Connecting a Local Node.js Server to Docker Kafka

Solution: Use the Host IP

Challenge 2: Docker DNS Resolution and Communication

Solution: Use Docker’s Built-in DNS

Fixing Docker Name Resolution for Node.js

Final Working Node.js Kafka Integration

Kafka Producer & Consumer Code

Conclusion

🏗️ Building an Inventory Management System with Robust Error Handling in Node.js

Introduction

👶 Junior Dev: “Why do I even need to handle errors? Can’t I just let the server explode?”

🧙‍♂️ Senior Dev: “Sure, and then watch as your customers rage-quit your app! Let me show you how to do it right.”

🛠️ Setting Up the Project

👶 Junior Dev: “Done! Now what?”

🧙‍♂️ Senior Dev: “Now we define the inventory model. And no, you can’t store ‘infinite’ items in your database.”

🏗️ Defining the Inventory Model

👶 Junior Dev: “Wait, why do I need ‘min: 0’? Can’t I just check it later?”

🧙‍♂️ Senior Dev: “Because catching bad data early means fewer fires to put out later! 🔥”

🚀 Setting Up the Express Server

👶 Junior Dev: “Cool! So if something breaks, the server just dies, right?”

🧙‍♂️ Senior Dev: “NO! We handle errors properly. Let’s implement CRUD operations with structured error handling.” 😤

📝 Implementing CRUD Operations with Error Handling

API Routes (routes/inventory.js)

👶 Junior Dev: “Why do we need this fancy error class? Can’t I just console.log errors?” 🤔

🧙‍♂️ Senior Dev: “If you do that, debugging production errors will be a nightmare! This way, we categorize issues properly.” 🎯

💡 Why This Approach Works

👶 Junior Dev: “Alright, I see the point. But what happens when I forget to handle an error?” 😬

🧙‍♂️ Senior Dev: “That’s when production crashes at 2 AM, and your phone won’t stop ringing.” 📞🔥

🎯 Wrapping Up

👶 Junior Dev: “Thanks, sensei! Now I won’t fear errors anymore.” 😎

🧙‍♂️ Senior Dev: “Good. Now go forth and build error-free apps… or at least fewer 500 errors.” 😉

design pattern in react

Avoiding State Inconsistencies: The Pitfall of Multiple React Context Providers

The Hidden Pitfall of Using Multiple Context Providers in React

Introduction

The Mistake: Multiple Instances of the Same Provider

Why This Happens

How Context Providers Work Internally

The Correct Approach: A Single Context Provider

Why This Works

How to Detect This Issue in Your App

1. Log the Context Value

2. Use React DevTools

Conclusion

Have you faced issues with React Context before? Share your experience in the comments!

Understanding Stream Methods in Node.js: A Guide to `read` and `write`

Stream Basics

Example of Using read and write

Understanding Stream Pressure

Handling Backpressure

Error Handling in Streams

Example of Error Handling

Why Developers Choose Databases Over File Storage for Scalable Data Management💾 ➡️ 🗄️

1. Data Consistency and ACID Compliance 🔄

2. Indexing for Faster Data Retrieval 📈

3. Concurrency Control for Multi-User Access 👥

Understanding `advertised.listeners`

API Routes (`routes/inventory.js`)

Example of Using `read` and `write`