DEV Community: Md Mohosin Ali Shah

React Query Showed the Wrong User's Data — Here's How to Reproduce and Fix It

Md Mohosin Ali Shah — Tue, 10 Nov 2026 23:24:49 +0000

A React dashboard can display the wrong user's data even when the API is returning the correct response.

One of the easiest ways to introduce this bug is by using a query key that doesn't account for the current user.

Consider this:

const { data } = useQuery({
  queryKey: ["orders"],
  queryFn: () => fetchOrders(userId),
});

It looks perfectly reasonable.

But there's a problem.

The query function depends on userId, while the cache key doesn't.

If Alice's orders are already cached and the application switches to Bob, both users can end up sharing the same cache entry.

Depending on the query's freshness settings, Bob's dashboard could display Alice's previously cached orders.

I wanted to break down why this happens because it's the kind of issue that's easy to overlook when testing with only one account.

We'll reproduce it in a small React application, fix the query key, and then look at what changes when authentication, logout, and multiple SaaS workspaces are involved.

Alice logs in and opens her orders page. Everything looks fine.

She logs out, and Bob logs in using the same browser.

But Bob sees something unexpected.

Alice's orders are still showing on his dashboard.

You check the backend. The API works. The database queries are correct. Your authorization checks appear to be doing their job.

So why is Bob seeing Alice's data?

The issue might be hiding in one line of React Query code:

queryKey: ["orders"]

That looks harmless, doesn't it?

But when the data depends on the authenticated user, this query key doesn't tell TanStack Query whose orders it's caching.

Let's reproduce the issue, understand why it happens, and fix it properly.

We'll also look at a few related problems that are easy to miss in production: switching workspaces, logging out, and displaying previous data while a new request loads.

1. The bug starts with a perfectly normal-looking query

Consider a React component that fetches the current user's orders.

import { useQuery } from "@tanstack/react-query";

function Orders({ userId }) {
  const { data, isPending } = useQuery({
    queryKey: ["orders"],
    queryFn: () => fetchOrders(userId),
  });

  if (isPending) {
    return <p>Loading orders...</p>;
  }

  return <OrdersTable orders={data} />;
}

At first glance, there's nothing unusual here.

We have a query key, a query function, and a loading state.

The problem is that fetchOrders() depends on userId, but the query key doesn't.

Let's say Alice has these orders:

[
  { "id": 101, "product": "MacBook Pro" },
  { "id": 102, "product": "Keyboard" }
]

And Bob has these:

[
  { "id": 201, "product": "Monitor" },
  { "id": 202, "product": "Mouse" }
]

Our React component requests different data depending on the user.

But TanStack Query sees this:

Alice → ["orders"]

Bob   → ["orders"]

It's the same cache key.

TanStack Query doesn't automatically inspect the variables inside your query function to identify the data.

It relies on the query key you provide.

If two requests use the same key, they're treated as requests for the same cached query.

And that's where things can go wrong.

2. Let's reproduce the problem

Instead of stopping at the explanation, let's create a small React application where you can see the bug yourself.

We'll use Vite and TanStack Query.

No backend or database is required for this demonstration.

The data is mocked so we can focus entirely on caching behavior. We're simulating account switching, not implementing real authentication.

Step 1: Create the project

Run:

npm create vite@latest react-query-cache-demo -- --template react

cd react-query-cache-demo

npm install

npm install @tanstack/react-query

npm run dev

Step 2: Configure QueryClient

Open src/main.jsx and replace its contents with:

import React from "react";
import ReactDOM from "react-dom/client";

import {
  QueryClient,
  QueryClientProvider,
} from "@tanstack/react-query";

import App from "./App.jsx";

const queryClient = new QueryClient();

ReactDOM.createRoot(
  document.getElementById("root")
).render(
  <React.StrictMode>
    <QueryClientProvider client={queryClient}>
      <App />
    </QueryClientProvider>
  </React.StrictMode>
);

Step 3: Create the demo

Now replace src/App.jsx with:

import { useState } from "react";
import { useQuery } from "@tanstack/react-query";

const ordersDatabase = {
  alice: [
    { id: 101, product: "MacBook Pro" },
    { id: 102, product: "Keyboard" },
  ],
  bob: [
    { id: 201, product: "Monitor" },
    { id: 202, product: "Mouse" },
  ],
};

async function fetchOrders(userId) {
  // Simulate network latency
  await new Promise((resolve) =>
    setTimeout(resolve, 500)
  );

  return ordersDatabase[userId];
}

export default function App() {
  const [userId, setUserId] = useState("alice");
  const [fixed, setFixed] = useState(false);

  const {
    data: orders = [],
    isPending,
  } = useQuery({
    queryKey: fixed
      ? ["orders", userId]
      : ["orders"],

    queryFn: () => fetchOrders(userId),

    // Keep cached data fresh for this demo
    staleTime: Infinity,
  });

  return (
    <div style={{ padding: 24 }}>
      <h1>Orders Dashboard</h1>

      <p>
        Logged in as: <strong>{userId}</strong>
      </p>

      <button onClick={() => setUserId("alice")}>
        Switch to Alice
      </button>

      <button onClick={() => setUserId("bob")}>
        Switch to Bob
      </button>

      <hr />

      <label>
        <input
          type="checkbox"
          checked={fixed}
          onChange={(event) =>
            setFixed(event.target.checked)
          }
        />
        Use correct query key
      </label>

      <h2>Orders</h2>

      {isPending ? (
        <p>Loading...</p>
      ) : (
        <ul>
          {orders.map((order) => (
            <li key={order.id}>
              #{order.id} - {order.product}
            </li>
          ))}
        </ul>
      )}
    </div>
  );
}

Step 4: See what happens

Open the application.

Initially, Alice is selected.

Wait for her orders to load.

You should see:

Logged in as: alice

Orders:
#101 - MacBook Pro
#102 - Keyboard

Now click Switch to Bob without enabling the checkbox.

You might expect Bob's orders to appear.

But the screen still shows:

Logged in as: bob

Orders:
#101 - MacBook Pro
#102 - Keyboard

That's the bug.

We're displaying Alice's cached orders while the interface says Bob is the current user.

Why does this happen?

Our query key hasn't changed:

queryKey: ["orders"]

We also deliberately configured:

staleTime: Infinity

This tells TanStack Query to consider the cached data fresh indefinitely, unless it is manually invalidated.

Because the cache key remains unchanged and the data is considered fresh, changing userId doesn't trigger a new query.

This setting makes the problem easy to reproduce.

With the default stale-time configuration, you may see different refetching behavior depending on when the query mounts or is invalidated. But the underlying problem remains: two different datasets are sharing one cache identity.

3. Fixing it with the correct query key

The fix is straightforward.

Instead of:

const { data } = useQuery({
  queryKey: ["orders"],
  queryFn: () => fetchOrders(userId),
});

Use:

const { data } = useQuery({
  queryKey: ["orders", userId],
  queryFn: () => fetchOrders(userId),
});

Now the cache keys are different:

Alice → ["orders", "alice"]

Bob   → ["orders", "bob"]

TanStack Query can distinguish the two datasets.

Go back to the demo and enable Use correct query key.

Switch between Alice and Bob again.

The orders should now match the selected account.

When you switch back to Alice, her previously fetched data can be retrieved from her own cache entry.

That's exactly the behavior we want.

Here's the principle I follow:

If a variable changes which data your query returns, it probably belongs in the query key.

Not every variable needs to be part of the key. But variables that determine the identity of the requested data do.

4. The same mistake becomes more complicated in multi-tenant SaaS applications

Now imagine a more realistic application.

You're working on a SaaS platform where a single account can belong to multiple organizations.

For example:

Alice
  |
  |-- Company A
  |     |-- Orders
  |     |-- Customers
  |
  |-- Company B
        |-- Orders
        |-- Customers

Alice can switch between Company A and Company B without logging out.

You might already be using this query key:

queryKey: ["orders", userId]

It separates Alice's data from Bob's.

But it doesn't separate Company A's orders from Company B's.

Both organizations still share the same key for Alice.

A better key would be:

queryKey: [
  "orders",
  userId,
  organizationId,
]

And what if the orders table has filters?

Suppose users can filter by order status, search terms, or pages.

Those variables also affect the result.

queryKey: [
  "orders",
  userId,
  organizationId,
  {
    status,
    page,
    search,
  },
]

Now each dataset has its own cache identity.

For example:

["orders", "alice", "company-a", { page: 1 }]

["orders", "alice", "company-b", { page: 1 }]

["orders", "bob", "company-b", { page: 1 }]

One important detail: don't include access tokens, passwords, or other secrets in query keys.

Use stable, non-secret identifiers.

And remember that cache scoping is not authorization. Even if a user manipulates a query key, the backend must independently check permissions.

5. How I'd structure the query in a real application

For a workspace-based SaaS application, I prefer keeping the query logic inside a reusable hook.

Something like this:

import { useQuery } from "@tanstack/react-query";

async function fetchWorkspaceOrders({
  workspaceId,
  status,
  page,
  signal,
}) {
  const params = new URLSearchParams({
    status,
    page: String(page),
  });

  const response = await fetch(
    `/api/workspaces/${encodeURIComponent(workspaceId)}/orders?${params}`,
    {
      credentials: "include",
      signal,
    }
  );

  if (response.status === 401) {
    throw new Error("Authentication required");
  }

  if (response.status === 403) {
    throw new Error("Access denied");
  }

  if (!response.ok) {
    throw new Error("Failed to fetch orders");
  }

  return response.json();
}

export function useWorkspaceOrders({
  userId,
  workspaceId,
  status = "all",
  page = 1,
}) {
  return useQuery({
    queryKey: [
      "orders",
      userId,
      workspaceId,
      { status, page },
    ],

    queryFn: ({ signal }) =>
      fetchWorkspaceOrders({
        workspaceId,
        status,
        page,
        signal,
      }),

    enabled: Boolean(userId && workspaceId),
  });
}

There are a few details worth understanding.

The query key describes the data. It includes the account, workspace, and filters that determine the response.

The enabled option prevents automatic fetching until the required identifiers are available. It doesn't remove cached data or enforce access control.

The query function uses the supplied AbortSignal. This allows obsolete requests to be cancelled when TanStack Query cancels the query.

HTTP errors are handled explicitly. The browser's fetch() function doesn't automatically reject a promise for responses such as 403 or 500.

For this example, I'm assuming the backend uses cookie-based authentication. If your application uses bearer tokens or another mechanism, the request implementation will be different.

The query key should still reflect the authenticated data context.

6. Don't forget what happens on logout

Correct query keys solve an important problem, but I wouldn't stop there.

Consider a shared computer.

Alice logs in, opens her dashboard, and logs out.

Then Bob logs in using the same browser tab.

If both sessions use the same QueryClient, Alice's previously fetched data can remain in its in-memory cache even after her session ends.

Correctly scoped keys help prevent the new session from accidentally requesting Alice's cached data.

But for private information, I generally prefer clearing the previous session's cached state when the authentication boundary changes.

TanStack Query provides:

queryClient.clear();

This clears both the query cache and mutation cache associated with that client.

You can also cancel active queries:

await queryClient.cancelQueries();

But the order of operations matters.

A safer logout strategy

The application should immediately stop displaying authenticated screens when logout begins.

Then it should coordinate request cancellation, cache cleanup, and session revocation.

Here's a simplified example:

async function handleLogout() {
  // The application must stop rendering private screens.
  setAuthStatus("signing-out");

  // Cancel active queries.
  await queryClient.cancelQueries();

  // Clear in-memory query and mutation caches.
  queryClient.clear();

  // Revoke the authenticated session on the server.
  const response = await fetch("/api/logout", {
    method: "POST",
    credentials: "include",
  });

  if (!response.ok) {
    // Keep private screens hidden and provide
    // a way to retry or recover from this error.
    setAuthStatus("logout-error");
    return;
  }

  setAuthStatus("signed-out");
}

This assumes your application uses authStatus to stop rendering all protected components when the value isn't an authenticated state.

It's an example of the sequence, not a complete authentication implementation.

A few things are important here:

Clearing React Query's cache doesn't revoke a server session.
Cancelling a query doesn't undo a request the server has already processed.
An unsuccessful logout request must not be presented as successful server-side logout.
If you're persisting queries to browser storage, that persisted data must be handled separately.
Other caches, global stores, service workers, and open browser tabs may also need attention.

For applications with sensitive information, the full authentication lifecycle deserves its own design and testing.

A cache clear is useful, but it isn't a complete security solution.

7. Another mistake: showing previous data during account switches

There's another subtle situation worth understanding.

TanStack Query supports showing previous query data while the next result loads.

For example:

import {
  keepPreviousData,
  useQuery,
} from "@tanstack/react-query";

const { data } = useQuery({
  queryKey: ["products", page],
  queryFn: () => fetchProducts(page),
  placeholderData: keepPreviousData,
});

This is often useful for pagination.

Instead of briefly displaying an empty table whenever the page changes, you can keep showing the previous page until the new result arrives.

That's a good experience for many interfaces.

But imagine using the same approach when switching between private workspaces.

Even with correctly scoped query keys, previous-data placeholders can temporarily display information belonging to the previous workspace.

The query cache entries may be isolated correctly, while the component still renders the previous result as placeholder data.

These are different behaviors.

For public product listings, this might be harmless.

For customer invoices, medical records, financial reports, or private business dashboards, it could be unacceptable.

A smoother loading experience isn't always the correct loading experience.

When the authenticated user or tenant changes, I generally prefer a loading or empty state over showing data from the previous context.

8. Is this actually a security vulnerability?

It's important to be precise here.

A wrong query key can cause the frontend to display data fetched under a previous authenticated context.

That can create a confidentiality problem, especially on shared devices or when sensitive information remains visible after switching accounts.

But this doesn't automatically mean the backend has an authorization vulnerability.

Consider two different scenarios.

Scenario A: Client-side cache isolation failure

Alice is authorized to access Company A.

The backend correctly returns Company A's orders.

Later, the frontend switches to Company B but mistakenly displays the previously cached Company A orders.

The UI has displayed inappropriate cached data.

That doesn't necessarily mean the server authorized an invalid request.

Scenario B: Broken backend authorization

Alice requests:

GET /api/workspaces/company-b/orders

Even though she doesn't have permission to access Company B.

The server returns Company B's private orders anyway.

That's a backend authorization failure.

Correcting React Query keys won't fix it.

The backend must verify that the authenticated user has access to the requested resource, regardless of what the frontend sends.

In a multi-tenant application, I would treat both areas seriously:

Frontend isolation: Make sure cached data is associated with the correct user and tenant.

Backend authorization: Enforce resource access permissions on every protected request.

Neither replaces the other.

9. Let's add a test for the cache behavior

It's easy to assume a bug is fixed because switching users appears to work manually.

I'd also want a small automated test that verifies how the cache behaves.

Install Vitest:

npm install -D vitest

Create src/query-cache.test.js:

import { describe, expect, it } from "vitest";
import { QueryClient } from "@tanstack/react-query";

const orders = {
  alice: ["Alice Order"],
  bob: ["Bob Order"],
};

describe("React Query cache isolation", () => {
  it("demonstrates the shared-key mistake", async () => {
    const client = new QueryClient();

    const aliceOrders = await client.fetchQuery({
      queryKey: ["orders"],
      queryFn: async () => orders.alice,
      staleTime: Infinity,
    });

    const bobOrders = await client.fetchQuery({
      queryKey: ["orders"],
      queryFn: async () => orders.bob,
      staleTime: Infinity,
    });

    expect(aliceOrders).toEqual(["Alice Order"]);

    // Bob receives the cached result for Alice.
    expect(bobOrders).toEqual(["Alice Order"]);

    client.clear();
  });

  it("keeps each user's orders separate", async () => {
    const client = new QueryClient();

    const aliceOrders = await client.fetchQuery({
      queryKey: ["orders", "alice"],
      queryFn: async () => orders.alice,
    });

    const bobOrders = await client.fetchQuery({
      queryKey: ["orders", "bob"],
      queryFn: async () => orders.bob,
    });

    expect(aliceOrders).toEqual(["Alice Order"]);
    expect(bobOrders).toEqual(["Bob Order"]);

    client.clear();
  });
});

Run:

npx vitest run

Notice that the first test deliberately expects the wrong result.

It's a regression demonstration: it confirms that the same fresh cache key is being reused.

The second test verifies that distinct keys keep the data separate.

This doesn't replace UI-level or authentication testing. In a production application, I'd also test account switching while requests are in progress, logout behavior, tenant authorization, and persisted cache cleanup.

10. My checklist before shipping a multi-tenant dashboard

When reviewing a React Query implementation, these are the cases I'd verify:

Scenario	Expected behavior
Alice opens her orders	Alice's orders appear
Alice switches to Bob in the demo	Bob's orders appear with a different key
A user switches organizations	Only the selected organization's orders appear
Filters or pagination change	The query uses the correct cache identity
A user logs out	Protected screens stop rendering and cached session data is cleaned up
An old request resolves after logout	Its result doesn't reappear in the new session's private UI
An unauthorized workspace is requested	The server rejects access
Previous-data placeholders are enabled	Private data isn't shown across authentication or tenant boundaries

One detail I find especially important is testing with more than one account.

An application can look completely correct during development when you always test with the same user and workspace.

Context-switching bugs often become visible only when you deliberately switch accounts, organizations, or permissions.

Final thoughts

TanStack Query makes it much easier to manage server state in React applications.

Caching, refetching, request deduplication, loading states, and error handling are all valuable features.

But caching introduces a responsibility that we shouldn't overlook.

The cache needs to know what makes one dataset different from another.

Sometimes that difference is a product ID.

Sometimes it's a page number or filter.

And in SaaS applications, it might be the current user, organization, or workspace.

This small change:

// Too generic for user-specific data
queryKey: ["orders"]

to:

// Separates users and workspaces
queryKey: ["orders", userId, workspaceId]

can prevent a surprisingly confusing class of bugs.

But the bigger lesson isn't simply to add more identifiers to every query key.

It's to think carefully about data ownership, cache lifetime, authentication boundaries, and what the user is actually allowed to see.

A working API doesn't guarantee that the interface is displaying the right data.

That's something worth testing before calling a feature production-ready.

How do you handle React Query caching when users log out or switch workspaces? Do you clear the cache, use user-scoped query keys, or combine both approaches?

I'd be interested to hear how others handle this in production.

Why Disabling the Submit Button Isn't Enough: Preventing Duplicate Requests in React & Node.js

Md Mohosin Ali Shah — Mon, 09 Nov 2026 23:05:19 +0000

Imagine this scenario:

A customer clicks Place Order.

The request reaches your server, the database successfully creates the order, but the response never reaches the browser because of a network issue.

The customer assumes something went wrong and clicks again.

Now you have two orders instead of one.

This is a common reliability problem in web applications.

Disabling a submit button might prevent accidental double-clicks, but it doesn't guarantee that an operation will execute only once.

Let's explore how to handle this properly using React, Node.js, and PostgreSQL.

1. Frontend protection is only the first layer

In React, we often prevent repeated submissions using a loading state:

const [isSubmitting, setIsSubmitting] = useState(false);

async function handleSubmit() {
  if (isSubmitting) return;

  setIsSubmitting(true);

  try {
    await createOrder();
  } finally {
    setIsSubmitting(false);
  }
}

This is useful for improving the user experience.

But there is a problem.

Duplicate requests can still happen because of:

Network retries
Multiple browser tabs
Concurrent API calls
Repeated webhook deliveries
Client or server failures

Even rapid calls within the same render cycle can observe the same React state before an update takes effect.

The important lesson: frontend protection improves UX, but backend protection ensures data integrity.

2. Understanding idempotency

An operation is idempotent when performing it multiple times has the same intended effect as performing it once.

For example:

POST /api/orders
Idempotency-Key: order-abc-123

If the same request is submitted again with the same idempotency key, the server should recognize that the operation has already been processed.

Instead of creating a new order, it can return the result of the original operation.

This is particularly important for:

Order creation
Payment processing
Subscription activation
Inventory adjustments
Financial transactions

However, an important distinction is that an idempotency key represents one intended operation, not an entire user session.

Retrying the same order should reuse the original key. Creating a genuinely new order should use a new one.

3. Implementing idempotency in React

We can generate a unique idempotency key using the browser's built-in Web Crypto API.

import { useRef } from "react";

function OrderForm() {
  const idempotencyKeyRef = useRef(null);

  async function createOrder(order) {
    // Generate once for this intended operation.
    if (!idempotencyKeyRef.current) {
      idempotencyKeyRef.current = crypto.randomUUID();
    }

    const key = idempotencyKeyRef.current;

    const response = await fetch("/api/orders", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "Idempotency-Key": key,
      },
      body: JSON.stringify(order),
    });

    if (!response.ok) {
      throw new Error("Order request failed");
    }

    const result = await response.json();

    // Reset only after confirmed completion.
    idempotencyKeyRef.current = null;

    return result;
  }

  // Use createOrder in your submission flow.
  // Prevent concurrent submissions from this form.
}

There are two important details here.

First: Reuse the same key when retrying an uncertain operation.

If the request reaches the server but the network fails before a response arrives, the client cannot know whether the order was created.

In that situation, we preserve the idempotency key so the same operation can be retried safely.

Second: Reset the key after confirmed success.

Once the server confirms the order was successfully created, the key is cleared.

This ensures the next legitimate order receives a new key instead of accidentally reusing the previous one.

For example:

Order A
  |
  Key: abc-123
  |
  Network failure
  |
  Retry with abc-123
  |
  Server returns existing Order A
  |
  Confirmed success
  |
  Clear key
  |
Order B
  |
  Generate new key: xyz-456

A few additional considerations for production applications:

Retry with the same order data, not a modified payload.
Prevent overlapping submissions of the same form operation.
Preserve an unfinished operation's key and payload across page refreshes if recovery is required.
Clear the key only after the operation's completion has been confirmed. A 202 Accepted response, for example, might only indicate that processing has started.
Handle validation failures separately from uncertain network failures.

The main principle remains the same:

One intended operation = one idempotency key.

4. Protecting the database against duplicate inserts

Frontend protection and idempotency middleware are useful, but concurrent requests can still introduce race conditions if the database isn't protected.

Consider this backend logic:

const existingOrder = await findOrder(key);

if (!existingOrder) {
  await createOrder(data);
}

Looks fine, right?

Not necessarily.

Two requests can execute simultaneously:

Request A                  Request B
    |                          |
Check existing order       Check existing order
    |                          |
Not found                  Not found
    |                          |
Create order               Create order
    |                          |
Success                    Success

Both requests can pass the check before either creates the record.

This is a classic check-then-insert race condition.

A better approach: Database uniqueness constraints

In PostgreSQL, enforce uniqueness at the database level.

CREATE UNIQUE INDEX unique_order_request
ON orders (user_id, idempotency_key);

This assumes your orders table contains the corresponding columns and that idempotency keys are required for this operation.

Now use PostgreSQL's ON CONFLICT functionality:

INSERT INTO orders (
  user_id,
  idempotency_key,
  product_id,
  quantity,
  request_hash
)
VALUES ($1, $2, $3, $4, $5)
ON CONFLICT (user_id, idempotency_key)
DO NOTHING
RETURNING id;

If the insert succeeds, the query returns the new order ID.

But there is an important detail.

When a conflict occurs, DO NOTHING RETURNING id returns zero rows.

It does not automatically return the existing order's ID.

So the backend needs to handle both cases.

Handling an existing order

If the insert returns no rows, retrieve the existing order using the same user ID and idempotency key.

SELECT id, request_hash
FROM orders
WHERE user_id = $1
  AND idempotency_key = $2;

Then compare the stored request hash with the incoming request's hash.

There are two possible outcomes:

Case 1: The request hashes match

The client is retrying the same intended operation.

Return the previously created order instead of creating another one.

Case 2: The request hashes don't match

The same idempotency key is being reused with different order parameters.

Reject the request:

HTTP 409 Conflict

{
  "error": "Idempotency key already used with different request data"
}

This prevents the application from silently treating two different operations as the same request.

For request hashing, both attempts must use a consistent representation of the relevant order data. The server should calculate or verify the hash rather than blindly trusting a value supplied by the client.

Why not use ON CONFLICT DO UPDATE?

Another approach is to perform an update during a conflict so PostgreSQL can return the existing row within the same statement.

For example, a no-op update can return the existing order ID and request hash.

However, this approach has trade-offs:

It can create a new row version even when values don't meaningfully change.
It acquires row locks.
It may trigger update-related behavior.
Some techniques for identifying whether the row was inserted rely on PostgreSQL implementation details.

For many applications, keeping DO NOTHING and performing a follow-up SELECT is a straightforward choice.

With PostgreSQL's default READ COMMITTED isolation, the follow-up query is a separate statement and can see the winning transaction's committed row.

The application should still handle unexpected missing rows or transaction failures appropriately.

Database constraints provide protection that application-level checks alone cannot guarantee.

5. What about transactions?

Preventing duplicate orders is only part of the problem.

Creating an order might involve multiple operations:

Create the order.
Reserve inventory.
Update related database records.
Record the transaction.
Send a notification.

If one operation fails halfway through, the system can end up in an inconsistent state.

Database transactions help ensure that related database modifications succeed or fail together.

For example, creating an order and reserving inventory should generally be part of the same database transaction when they must succeed together.

That way, a failure doesn't leave an order committed without its required inventory changes.

The idempotency check and the business operation also need to be coordinated correctly. Preventing duplicate inserts alone doesn't guarantee every related operation executes only once.

However, external operations such as sending emails or publishing messages are not automatically rolled back with a database transaction.

For these cases, patterns such as the transactional outbox and idempotent event consumers can improve reliability.

This is an important distinction when designing systems that interact with external services.

6. Test real failure scenarios

A feature working during normal testing doesn't necessarily mean it is reliable under failure conditions.

Here are some scenarios worth testing:

Scenario	Expected behavior
Two concurrent requests with the same key	Only one order is created
Retry after the original request commits	Existing order is returned
Same key with different request data	Request is rejected with `409 Conflict`
Failed database transaction	No partial order is committed
Two legitimate operations with different keys	Both can proceed
New order after successful submission	A fresh idempotency key is generated
Network failure after server commits	Retry returns the original order

One especially useful test is simulating a lost response after a successful database commit.

The client should be able to retry without accidentally creating another order.

These tests provide more confidence than simply checking whether a submit button becomes disabled.

7. The approach I recommend

For reliable applications, multiple layers should work together:

Frontend safeguards improve the user experience and discourage accidental repeated submissions.

Backend idempotency identifies repeated attempts to perform the same operation and distinguishes them from genuinely new requests.

Database constraints protect against duplicate inserts, including concurrent requests.

Transactions and carefully designed side effects help maintain consistency across the entire workflow.

Failure scenario testing verifies that retries and concurrency behave as expected outside the normal happy path.

No single layer solves every problem.

The goal isn't just to make an API request succeed.

It's to make sure retries, failures, and concurrent requests don't produce unintended results.

Final thoughts

Building reliable software requires thinking beyond the happy path.

A submit button can be disabled. A network request can fail. A server can process the same operation more than once.

The application should still behave predictably.

A combination of frontend safeguards, idempotency, database constraints, and transaction handling is generally more reliable than depending on any one of them.

There is also an important distinction between preventing duplicate requests and guaranteeing exactly-once processing across an entire distributed system. Idempotency makes repeated attempts safe, but external side effects still require careful coordination.

What's your approach to preventing duplicate requests in production applications?

Further reading: PostgreSQL INSERT / ON CONFLICT documentation

RepoLens Version 2 Ranked #7 on Product Hunt — Building AI for Code Change Intelligence

Md Mohosin Ali Shah — Sun, 29 Mar 2026 08:54:57 +0000

RepoLens Version 2 ranked #7 on Product Hunt this week.

That number was exciting, but what mattered more to me was what it represented.

It felt like a signal that this problem resonates with more people than just me.

Because RepoLens started from a frustration I kept running into again and again:

understanding a codebase takes too long.

When I opened a new repository, I would usually go through the same cycle:

open random folders
search for routes
trace imports manually
guess how modules fit together
try to understand the architecture from scattered files and tribal knowledge

That process was slow, repetitive, and mentally expensive.

So I built RepoLens Version 1 to solve that.

Version 1 was about helping developers understand a repository faster.

It could analyze repositories, detect stack and structure, map modules and dependencies, extract API endpoints, generate docs, support grounded repository chat, compare branches, and turn a codebase into something much more explorable.

That solved an important problem.

But while building it, I realized I had only solved the first half of the real pain.

Understanding a Repository Once Is Not Enough

A repository is not static.

It keeps moving.

Pull requests change behavior.

Endpoints shift.

Dependencies evolve.

Architecture drifts.

And teams are constantly trying to answer a harder question:

what changed, what was affected, and what actually matters?

That is where RepoLens Version 2 came from.

Version 2 is not just about repository understanding.

It is about change intelligence.

That shift changed how I thought about the product.

Instead of only helping someone understand a repository once, I wanted RepoLens to become useful inside the real engineering loop:

when a pull request opens
when a branch changes
when APIs move
when architecture starts drifting
when a team needs clarity before review or release

What Changed in Version 2

RepoLens Version 2 now focuses on helping teams understand change with more structure and more trust.

It can now:

analyze pull requests and generate engineering summaries
detect affected modules
detect changed endpoints
highlight likely review hotspots
support branch-aware and PR-aware repository chat
show exact code snippet references and confidence signals
run incremental analysis instead of full rebuilds every time
sync automatically from GitHub events
detect architecture drift
send alerts for important changes and failed analysis runs
track workspace usage and operational health

The product story became much clearer through this work:

Version 1: Know any repo fast
Version 2: Know what changed and what matters

That clarity was one of the biggest wins for me as a builder.

What I Learned Building It

One of the biggest lessons from building RepoLens is that generic AI output is not enough for engineering workflows.

It is easy to generate a summary.

It is much harder to generate something that engineers can actually trust.

That means the system has to do more than just “talk about code.”

It has to first build a structured understanding of the repository and its changes, then use AI on top of that structure to make the output more useful, grounded, and verifiable.

That has shaped almost every product decision in RepoLens so far.

I do not want RepoLens to be another tool that gives impressive-sounding answers without enough proof behind them.

I want it to help teams see:

where an answer came from
what changed
what was affected
what deserves attention

The Product Hunt Launch

Launching RepoLens Version 2 on Product Hunt and seeing it reach #7 was encouraging not just because of visibility, but because of the kinds of conversations it created.

The most interesting feedback was not about “AI” in the abstract.

It was about very practical engineering questions:

How do you handle overlapping PRs?
How reliable is changed endpoint detection?
Can this work beyond a single framework?
Which signals are actually useful in day-to-day development?

That is exactly the kind of feedback I hoped for.

It means the product is starting to move from “interesting demo” territory into “could this fit real engineering workflows?” territory.

That is the transition I care about most.

Where RepoLens Is Going

RepoLens started as a way to understand repositories faster.

Now it is becoming a way to understand change faster.

That feels like the more important problem.

Because teams do not just need help reading code.

They need help reasoning about evolving systems.

That is what I want RepoLens to keep getting better at.

RepoLens Version 2 - Know what changed and what matters

Md Mohosin Ali Shah — Wed, 25 Mar 2026 17:30:00 +0000

RepoLens Version 1 was about understanding a repository quickly.

It helped answer:
What is in this repository?
How is the codebase structured?
Where do I start?

But after building and using it more, I realized something important:

understanding a codebase once is not enough.

Repositories keep changing.
Pull requests introduce risk.
APIs evolve.
Architecture drifts.
And teams need better visibility into what changed, what was affected, and what actually matters.

So I built RepoLens Version 2.

RepoLens is no longer just a repository analysis dashboard.
It is becoming a change intelligence platform for engineering teams.

What RepoLens V2 Adds

RepoLens can now:

analyze pull requests and generate engineering summaries

show affected modules, changed endpoints, and likely review hotspots

run incremental analysis instead of reprocessing the whole repository every time

sync automatically from GitHub push, PR, and merge events

answer chat questions in repository, branch, PR, and branch-compare context

show exact code snippets, references, and confidence signals in chat answers

detect architecture drift and endpoint changes over time

send alerts for meaningful changes and failed analysis runs

track workspace usage, plan limits, and operational health

What This Changes

Version 1 helped understand a repository.

Version 2 helps understand change.

That means RepoLens starts becoming useful in everyday engineering workflows, not just onboarding.

For example:

reviewing pull requests

tracking architecture changes across runs

seeing what modules and endpoints were affected

understanding branch differences faster

getting grounded answers in the exact context you care about

receiving alerts instead of checking manually

Product Direction

The RepoLens product story is becoming clearer:

Version 1: Know any repo fast.
Version 2: Know what changed and what matters.

That shift is the part I’m most excited about.

RepoLens is moving from static repository understanding
to ongoing engineering intelligence.

Live Platform
https://repolensai.com

Open Source Repository

The open-source analysis engine is available here:

https://github.com/mohosin2126/repolens-community

Version 2 LinkedIn Post
https://www.linkedin.com/posts/mohosin2126_opensource-ai-github-activity-7442612868300234752-HWkc?utm_source=share&utm_medium=member_desktop&rcm=ACoAADpg8RMBJaipaeKrpBc7xSoC8S90bR4HWpk

Why I Built Version 2

I wanted RepoLens to be useful not only when someone first opens a repository,
but also when a team is actively changing it.

Especially when:

reviewing pull requests

tracking risky changes

watching API and architecture evolution

keeping teams aligned as systems grow

Open Core

RepoLens continues to follow an open-core model.

The reusable analysis engine remains open source, while the hosted platform builds on top of it with collaboration, change intelligence, notifications, workspace controls, and premium product features.

I Shipped v0.3.0 of My Open Source Project Scaffolding CLI

Md Mohosin Ali Shah — Wed, 18 Mar 2026 01:03:49 +0000

A few days ago, I published my open source npm package: starter-structure-cli.

It’s a Node.js CLI that scaffolds production-ready starter projects from simple stack tokens.

You can run something like:

npx starter-structure-cli my-app react vite ts tailwind express prisma postgres

and get a structured project generated for you instead of spending hours wiring everything manually.

Since publishing it, I’ve been improving it quickly, and today I shipped v0.3.0.

What made this update especially exciting for me is that the package also started getting real usage.

From March 3, 2026 to March 9, 2026, it got 480 downloads.
In the following week, it got 35 more downloads.
That brings it to 515 total downloads across the last two weeks.

It’s still early, but seeing people actually try something I built has been genuinely motivating.

What `starter-structure-cli` does

The goal is simple:

Start coding faster without repeating the same setup work again and again.

Instead of manually creating folder structures, wiring frontend and backend pieces together, setting up ORM config, styling, auth, and other repetitive boilerplate, the CLI gives you a working baseline from the stack you choose.

It currently supports technologies like:

React
Next.js
Vue
Vite
Tailwind CSS
shadcn/ui
Express
NestJS
Prisma
Mongoose
Sequelize
MongoDB
MySQL
PostgreSQL
JWT
NextAuth

And it organizes templates across these project types:

Single App
Frontend-only
Backend-only
Fullstack
Monorepo
Turbo Monorepo

With v0.3.0, the catalog now supports 36 production-ready starter templates.

What’s new in v0.3.0

This release focused on three things:

expanding the template catalog
cleaning up the CLI internally
strengthening release quality

New starters added

I added several new templates, including:

Fastify + Prisma + PostgreSQL backend starter
Next.js + TypeScript + shadcn/ui + Tailwind starter
React/Vite + Prisma + PostgreSQL fullstack starter
Vue/Vite + Prisma + PostgreSQL fullstack starter
additional backend, single-app, and fullstack combinations

That pushed the catalog to 36 starter templates.

A cleaner CLI internally

One of the biggest improvements in this release was refactoring the CLI into smaller, more maintainable modules.

I split the logic into separate parts for things like:

argument parsing
catalog discovery
template matching
prompts
scaffolding
constants and aliases

This made the codebase easier to understand and easier to extend as the number of templates keeps growing.

That cleanup mattered a lot, because once a scaffolding tool starts supporting many combinations, the matching and discovery flow can become messy very quickly.

I wanted to improve that before continuing to add more starters.

Stronger validation before release

I also improved the validation and release checks.

The project now verifies things like:

referenced bases and layers actually exist
built template outputs are valid
expected files are present
template integrity is preserved before publishing
release quality is more consistent

That gave me much more confidence when shipping updates to npm.

When a project becomes template-driven and composable, validation stops being optional very quickly.

Why I’m building this

I built this because I kept running into the same problem:

Every time I started a new project, I spent too much time on setup before I could start building the real thing.

Not just creating folders, but also:

organizing frontend and backend structure
connecting stack pieces together
configuring database tooling
choosing a maintainable baseline
reusing and cleaning up old boilerplate

I wanted a tool that could take simple stack words and give me a serious starting point.

Not a toy template.
Not an empty folder structure.
A real baseline that someone could actually continue building on.

Example usage

Interactive mode:

npx starter-structure-cli my-app

Natural stack-token mode:

npx starter-structure-cli my-app react vite ts tailwind express prisma postgres

List available templates:

npx starter-structure-cli --list

What I learned from shipping this

A few things became very clear while working on this release.

1. Template quality matters more than template count

Adding more starters is useful, but only if the generated output actually feels worth building on.

2. Validation becomes essential very quickly

As soon as templates become composable, release-time checks become necessary.

3. Internal cleanup is part of shipping

Adding features is exciting, but maintainability work is what keeps the project from collapsing under growth.

4. Real users change how you think

Once people start downloading a package, small details start to matter more:

naming
docs
consistency
output quality
error handling
discoverability

What’s next

I want to keep improving:

template coverage
matching quality
documentation
generated project quality
the contributor experience for adding new starters

I also want to make template authoring easier over time so the project can grow in a cleaner way.

Try it

npx starter-structure-cli my-app

GitHub: https://github.com/mohosin2126/starter-structure-cli
npm: https://www.npmjs.com/package/starter-structure-cli

If you try it, I’d genuinely love feedback on:

which stacks you want next
how useful the generated structure feels
what would make a tool like this part of your workflow

I Built a Tool That Turns GitHub Repositories Into Architecture Dashboards - RepoLens Version 01

Md Mohosin Ali Shah — Thu, 12 Mar 2026 15:32:08 +0000

RepoLens (Version 1) - Know any repo fast.

Understanding a new codebase is one of the hardest parts of software development.

You open a repository and immediately face questions like:

How are modules structured?
Which components depend on each other?
What APIs exist?
What does the architecture actually look like?

Developers often spend hours reading files just to understand the structure of a project.

So I built RepoLens.

RepoLens Version One analyzes GitHub repositories and turns them into a structured architecture dashboard.

Instead of manually exploring folders, you get:

module mapping
dependency graphs
API endpoint discovery
generated architecture documentation
repository chat grounded in code

Live Platform

https://repolensai.com

Open Source Repository

The open-source analysis engine is available here:

https://github.com/mohosin2126/repolens-community

What RepoLens V1 Does

RepoLens runs an analysis pipeline that:

Clones the repository
Scans project files
Detects languages and frameworks
Parses modules and dependencies
Extracts API routes
Generates architecture summaries
Generates project overview and onboarding docs
Persists structured analysis results for each run
Builds semantic chunks from repository content
Generates embeddings for retrieval and search
Grounds repo chat answers in indexed source files
Tracks branch-specific analysis history
Compares branches across key architecture signals
Exports reports and comparison results

Tech Stack

Node.js
Express
MySQL
Prisma
Redis
BullMQ
React
TypeScript
ts-morph
React Flow

Why I Built It

I wanted a tool that helps developers understand large repositories faster.

Especially when:

joining a new project
reviewing unfamiliar codebases
exploring open source projects
onboarding new developers

Open Core

RepoLens follows an open-core model.

The reusable repository analysis engine is open source, while the hosted platform builds on top of it with the full product experience.

I Built a CLI That Scaffolds 30+ Fullstack Projects From Natural Language

Md Mohosin Ali Shah — Sat, 07 Mar 2026 19:47:24 +0000

Ever typed something like this and wished it just worked?

npx starter-structure-cli my-app react vite ts tailwind express prisma mysql

Well, now it does. I built starter-structure-cli an open source Node.js CLI that generates production-ready starter projects from stack tokens you type in plain English.

The Problem

Every time I started a new project, I'd spend hours:

Setting up folder structure
Wiring up the frontend to the backend
Configuring ORMs, auth, styling
Copy-pasting boilerplate from old projects

I wanted one command that just gives me a working project with my exact stack.

What It Does

npx starter-structure-cli my-app

That's it. You get an interactive prompt that walks you through picking your stack. Or skip the prompts entirely:

npx starter-structure-cli my-app react vite ts tailwind express prisma mysql

It ships with 30+ templates across 6 categories:

Category	Example
Single App	`react-vite-ts-tailwind`
Frontend-only	`react-admin-dashboard`
Backend-only	`express-prisma-mysql-jwt`
Fullstack	`react-vite-ts-tailwind-express-prisma-mysql`
Monorepo (Client/Server)	`nextjs-express-prisma`
Monorepo (Turbo + pnpm)	`nextjs-api-nestjs-prisma`

Stacks covered: React, Next.js, Vue, Vite, Tailwind CSS, shadcn/ui, Express, NestJS, Prisma, Mongoose, Sequelize, MongoDB, MySQL, PostgreSQL, JWT, NextAuth — and growing.

The Cool Parts

1. Natural Language Matching

You don't need to memorize template names. Just throw stack words at it:

npx starter-structure-cli my-app reactjs tailwind css nodejs prisma mysql

The CLI normalizes aliases automatically:

reactjs → react
tailwindcss → tailwind
typescript → ts
next → nextjs

It even ignores filler words like with, project, app, and css.

2. Composable Template System

Templates aren't just static folders. They're built from composable layers:

template-sources/
  bases/       → shared project skeletons
  layers/      → stack-specific overlays
  presets/     → final template definitions (JSON)
  components/  → reusable snippets (package.json, README, styles)

A preset JSON file defines how layers compose:

{
  "output": "templates/fullstack/react-vite-ts-tailwind-express-prisma-mysql",
  "base": ["bases/fullstack/react-vite-ts-tailwind-express"],
  "layers": ["layers/backend-only/prisma-mysql"],
  "variables": { "DB": "mysql" }
}

This means adding a new database variant is just a new 5-line JSON preset — not a whole new template folder.

The system also supports {{ include: }} directives with cycle detection, so templates can reference shared snippets without infinite loops.

3. Interactive + Non-Interactive

Fully interactive with @clack/prompts:

npx starter-structure-cli my-app
# → Pick category → Pick stack options → Generate

Or fully automated for CI/scripts:

npx starter-structure-cli my-app \
  --category fullstack \
  --frontend react \
  --backend express \
  --orm prisma \
  --database mysql \
  -y

4. Smart Defaults

If both JS and TS variants exist, TypeScript is preferred unless you pass --language js
__APP_NAME__ placeholders are replaced in file names, folder names, and file contents
Auto-installs dependencies with --install (supports npm, pnpm, yarn)

Generated Project Structures

Fullstack:

my-app/
  client/    → React/Vue/Next.js frontend
  server/    → Express/NestJS backend

Monorepo (Turbo):

my-app/
  apps/
    web/     → frontend
    api/     → backend

Templates include starter structure for components, routes, hooks, services, controllers, and data modules — not just empty folders.

How I Built It

The entire CLI is built with:

Pure Node.js (ES Modules, zero build step)
@clack/prompts — beautiful terminal UI
picocolors — lightweight terminal colors
A custom template build pipeline that composes presets at publish time

The architecture is intentionally simple. No frameworks, no bundlers, no compilation. Just Node.js doing what it does best — file system operations and CLI parsing.

Try It

npx starter-structure-cli my-app

Or browse the templates:

npx starter-structure-cli --list

GitHub: github.com/mohosin2126/starter-structure-cli
npm: npmjs.com/package/starter-structure-cli

Star it if you find it useful ⭐ and feel free to open issues or contribute new templates!

What a monorepo needs (the real requirements)

Md Mohosin Ali Shah — Wed, 25 Feb 2026 15:35:57 +0000

A good monorepo package manager should handle:

Workspaces (multiple packages/apps)
Fast installs for big repos
Deterministic lockfile (same deps everywhere)
Good CI caching
Minimal “dependency weirdness” (phantom deps, hoisting surprises)
Good developer workflow (run scripts across packages, filtering, etc.)

pnpm in monorepos (why it’s usually best)

1) Speed (especially after first install)

pnpm keeps a global content-addressable store (one copy of each package version).
Each project uses hardlinks into node_modules. Result: repeated installs are very fast, and huge monorepos benefit a lot.

2) Disk usage (big win)

With npm, each workspace can duplicate the same packages across subprojects.
With pnpm, packages are reused from the store. Result: smaller repo footprint and faster docker/CI layers.

3) Strict dependency isolation (less “hidden bugs”)

pnpm is strict:
If package-a doesn’t declare lodash in its package.json, it can’t import it just because some other package installed it.

This prevents the classic monorepo bug:

“It worked on my machine because it was hoisted… but CI broke later.”

4) Workspace tooling feels made for monorepos

pnpm has very ergonomic workspace commands:

run scripts across all packages
filter to run on only affected packages
recursive installs/builds are clean

5) CI caching is usually better

Because pnpm’s store is reusable, caching is simpler and more effective.

In many CI pipelines, pnpm installs become consistently faster after the first cached run.

Best for:
New monorepos, medium/large repos, teams that care about correctness and speed, TurboRepo/Nx repos.

npm in monorepos (when it’s still a good choice)

1) Maximum compatibility / minimum friction

npm ships with Node by default.
Some older tools and scripts assume npm-style hoisting behavior. That makes npm “boring and safe” in some enterprise setups.

2) Simpler mental model for some teams

If the team already knows npm and the repo is small-ish, npm workspaces can be “good enough.”

3) Fewer edge cases with legacy tooling

pnpm’s strictness can expose issues in older packages that assumed hoisting.
That’s not pnpm’s fault—it’s correctness—but it can create migration work.

Best for:
Legacy repos, very strict “no new tooling” policy, or ecosystems with fragile dependencies.

Key Differences (quick but important)

Dependency layout

npm: often hoisted dependencies (deps can appear available even if not declared)
pnpm: uses a symlinked structure that enforces correctness

Bug prevention

pnpm catches missing dependencies earlier
npm may hide missing dependency problems until later

Performance

pnpm usually wins for bigger repos and repeated installs

Recommendation (simple decision guide)

Pick pnpm if you want:
fast installs
lower disk usage
fewer “phantom dependency” bugs
best monorepo ergonomics

Pick npm if you want:
maximum compatibility
simplest onboarding (no extra tool install)
legacy tooling expectations

My default in 2026: pnpm for almost every new monorepo.

Best-practice setup (works great)

If you choose pnpm, do this:

Keep one lockfile at repo root
Use pnpm workspaces
Add a pinned version for consistency across the team

Example idea (conceptual):

root package.json with "packageManager": "pnpm@X.Y.Z"
pnpm-workspace.yaml listing packages like:
- apps/*
- packages/*

365 Days, 2,010 Contributions: What I Learned from a Year of Zero Missed Days

Md Mohosin Ali Shah — Sun, 04 Jan 2026 05:30:21 +0000

In 2025, I made a silent promise to myself: Show up. No matter how I felt, no matter how busy the day was, I committed to pushing my craft forward every single day. Today, looking back at the green squares on my GitHub profile, the numbers tell one story, but the growth tells another.

The Stats

Days Commited: 365 / 365
Total Contributions: 2,010
Days Missed: 0
GitHub Handle: @mohosin2126

Beyond the Green Squares

While the GitHub contribution graph is a great motivator, it only scratches the surface. In the beginning, I was focused on the "streak." But as the months progressed, the focus shifted from quantity to quality.

I realized that 2,010 contributions aren't just lines of code; they are 2,010 moments of problem-solving, debugging, and architectural decision-making.

The Projects That Defined My Year

My year was largely defined by three major pillars:

@codethinker (Primary Focus): This has been my main driver. Building and scaling this project required me to move beyond basic implementation and think deeply about user experience and system reliability.
@orbillo & @perkoxofficial: Contributing to these organizations allowed me to collaborate and understand different codebases, which is essential for any developer looking to grow.

What I Learned When I Refused to Take a Day Off

1. Logic Over Syntax

When you code every day, syntax becomes second nature. This frees up your brain to focus on the truly hard parts: logic and architecture. I found myself spending more time planning my approach and less time looking up documentation for basic functions.

2. The Power of "Non-Zero" Days

There were days when I didn't feel like a "rockstar." There were days when I was tired or stuck. But I learned the value of the "Non-Zero Day." Even a small refactor or a documentation update keeps the momentum alive. Consistency beats intensity every single time.

3. Architecture is a Mindset

By maintaining a year-long streak, I was forced to live with my own code for 365 days straight. Nothing teaches you the importance of clean, maintainable architecture quite like having to fix a bug in code you wrote six months ago during a "daily streak" rush.

Looking Ahead

If 2025 was about discipline, 2026 will be about depth. I want to take the consistency I’ve built and apply it to even more complex architectural challenges and open-source contributions.

To anyone thinking about starting their own streak: Don't wait for the perfect moment. Just start. The growth happens in the struggle, not the success.

Let’s Connect!

GitHub: mohosin2126
Projects I'm working on: @codethinker, @orbillo, @perkoxofficial

How do you stay consistent in your coding journey? I’d love to hear your thoughts in the comments!

Primary Key vs Foreign Key: A Complete Guide for Developers

Md Mohosin Ali Shah — Mon, 29 Sep 2025 16:21:09 +0000

Relational databases power everything from small web apps to enterprise-grade systems. At the heart of relational database design are Primary Keys and Foreign Keys. These concepts define how data is uniquely identified and how different tables connect to each other. Whether you are designing your first database or optimizing a production system, understanding these keys is essential.

What is a Primary Key

A Primary Key is a column or a group of columns in a database table that uniquely identifies each record in that table.
It acts like a unique ID card for every row, ensuring there is no ambiguity when retrieving, updating, or deleting data.

Key Characteristics of a Primary Key

• Uniqueness Every row must have a unique primary key value.
• Non Null Primary keys cannot contain NULL values.
• Single Definition Each table can have only one primary key but it may consist of multiple columns which is known as a composite key.
• Immutable The value of a primary key should rarely change because it serves as the permanent identifier of the row.

Example of a Primary Key

Consider a Users table

user_id (Primary Key)	name	email
1	Alice	alice@email.com
2	Bob	bob@email.com
3	Carol	carol@email.com

Here user_id is the primary key. Even if two users share the same name or email domain their user_id remains unique.

What is a Foreign Key

A Foreign Key is a column or a group of columns in one table that references the primary key of another table.
Its purpose is to enforce referential integrity making sure that relationships between tables remain valid.

Key Characteristics of a Foreign Key

• Reference Points to the primary key of another parent table.
• Duplicates Allowed Multiple rows in the child table can reference the same parent record.
• Optional Relationship Can allow NULL values if the relationship is not mandatory.
• Multiple Allowed A table can have several foreign keys pointing to different parent tables.

Example of a Foreign Key

Consider an Orders table

order_id	user_id (Foreign Key)	product
101	1	Laptop
102	2	Keyboard
103	1	Mouse

Here the user_id column in the Orders table is a foreign key that references the user_id column in the Users table.
This ensures that every order is linked to a valid user. If you try to insert an order with a user_id that does not exist in the Users table the database will reject it.

Primary Key vs Foreign Key Side by Side Comparison

Feature	Primary Key	Foreign Key
Purpose	Uniquely identifies each record in a table	Creates a relationship between two tables
Uniqueness	Must be unique across all rows	Can have duplicate values
Nullability	Cannot contain `NULL` values	Can contain `NULL` values if the relationship is optional
Number per Table	Only one primary key is allowed	A table can have multiple foreign keys
Reference	Exists within its own table	References the primary key of another table
Integrity Role	Guarantees uniqueness within the table itself	Ensures valid links between child and parent tables

This comparison shows that while both keys are used to maintain order and integrity their roles are different.
The primary key focuses on identifying rows within a single table while the foreign key focuses on linking one table to another.

Real World Analogy

Think of a Primary Key as a passport number. Each passport number is unique to one person and cannot be duplicated.
A Foreign Key is like a visa stamp inside the passport. It connects your identity to another country’s system.
A visa is only valid if the passport exists just as a foreign key is only valid if the corresponding primary key exists.

Best Practices

To build strong and scalable databases keep these best practices in mind

• Use Simple and Stable Keys Choose primary keys that are simple and unlikely to change such as an auto incrementing integer.
• Avoid Changing Primary Key Values Because other tables may rely on them changing a primary key can cause cascading issues.
• Index Foreign Keys Adding indexes on foreign key columns can significantly improve join performance.
• Enforce Referential Integrity Use database constraints ON DELETE and ON UPDATE to control how changes in the parent table affect child tables.
• Avoid Using Business Data as Keys Columns like email or phone numbers can change and should not be primary keys.

Why These Keys Matter

Without a primary key it would be impossible to uniquely identify records making operations like updates or deletions unreliable.
Without a foreign key relationships between tables would be fragile allowing invalid or orphaned records to exist.
Together primary and foreign keys create a structured dependable and maintainable database design.

Conclusion

Primary keys and foreign keys are not just database jargon. They are fundamental to creating relational databases that are efficient scalable and consistent.
The primary key ensures that each row in a table is unique while the foreign key maintains valid connections between tables.
Mastering these concepts will help you design systems that handle growth gracefully and maintain data integrity in the real world.

GitHub on Windows: The Complete Guide to SSH, GitHub Desktop, and No Keygen Commits

Md Mohosin Ali Shah — Wed, 13 Aug 2025 18:08:16 +0000

Working with GitHub on Windows can be painless and secure if you set it up the right way.
In this article, you will learn three complete workflows

SSH from Command Prompt or PowerShell for passwordless, secure pushes and pulls
GitHub Desktop the GUI option no SSH setup required
No keygen methods working over HTTPS using a Personal Access Token or the GitHub web editor

Why SSH vs HTTPS on Windows

SSH uses a key pair stored on your machine. No password or token prompts once configured.
HTTPS uses your GitHub login or Personal Access Token PAT. Works out of the box with GitHub Desktop.
Web editor lets you make commits right in your browser with no local setup needed.

SSH from Windows CMD or PowerShell

Step 1 Check for existing SSH keys

dir %USERPROFILE%\.ssh

Look for
id_ed25519 private
id_ed25519.pub public

If they exist and you want to reuse them, skip to Step 4.

Step 2 Create a new SSH key

ssh-keygen -t ed25519 -C "you@example.com"

Press Enter to accept default path
%USERPROFILE%\.ssh\id_ed25519
Optionally set a passphrase.

If ed25519 is not supported

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

Step 3 Start the SSH agent and load your key

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

Step 4 Copy your public key

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | Set-Clipboard

Step 5 Add the key to GitHub

Go to Settings then SSH and GPG keys then New SSH key
Title it for example Windows Laptop
Paste your key
Save

Step 6 Test your connection

ssh -T git@github.com

If successful you will see

Hi <username> You have successfully authenticated...

Step 7 Use SSH in Git

Clone

git clone git@github.com:OWNER/REPO.git

Switch existing repo from HTTPS to SSH

git remote set-url origin git@github.com:OWNER/REPO.git

Step 8 Commit and push

git add .
git commit -m "feat: first SSH commit from Windows"
git push origin main

GitHub Desktop The GUI Method No SSH Needed

GitHub Desktop uses HTTPS by default and stores credentials securely. Perfect if you want to skip SSH.

Step 1 Install and sign in

Download from desktop.github.com
Sign in with your GitHub account.

Step 2 Add a repository

Clone from GitHub File → Clone Repository
Add existing project File → Add Local Repository

Step 3 Ensure HTTPS remote

Repository → Repository Settings
Ensure URL is https://github.com/...

Step 4 Commit changes

Edit files in your project folder.
In Desktop, select changed files, write a commit message, click Commit to branch.

Step 5 Push to GitHub

Click Push origin.
To create a PR, click Create Pull Request.

No Keygen Options

Option 1 HTTPS with Personal Access Token

Create a fine grained PAT in GitHub Settings → Developer settings → Personal Access Tokens
Switch remote to HTTPS

git remote set-url origin https://github.com/OWNER/REPO.git
git push origin main

Use your GitHub username and PAT when prompted.

Option 2 GitHub Web Commits

Open repo on github.com
Add file → Create new file or edit existing
Write changes and commit directly to main or via new branch and PR

Troubleshooting on Windows

Permission denied publickey
Check if your key is loaded

ssh-add -l

If none re-add

ssh-add $env:USERPROFILE\.ssh\id_ed25519

Verify your public key is in GitHub settings.

GitHub Desktop cannot push
Switch to HTTPS in Repository Settings.

Quick SSH Cheat Sheet Windows

ssh-keygen -t ed25519 -C "you@example.com"
Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519
Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | Set-Clipboard
ssh -T git@github.com
git add .
git commit -m "message"
git push origin main

Conclusion

SSH is best for developers who want secure passwordless Git operations.
GitHub Desktop is ideal for a quick GUI based workflow.
HTTPS with PAT or Web Commits let you skip SSH entirely.

Choose the method that fits your workflow and you will never dread pushing to GitHub on Windows again.

Build High-Performance Websites with React.js, Next.js, Vue.js and Tailwind CSS

Md Mohosin Ali Shah — Sat, 19 Jul 2025 18:10:50 +0000

Hello Dev Community,

I'm Md Mohosin Ali, a Full Stack Developer based in Bangladesh, specializing in React.js, Next.js, Vue.js, and Tailwind CSS. With over two years of professional experience, I help startups, designers, and businesses transform their design files (Figma, PSD, Adobe XD) into fully responsive, high-performance websites and web applications.

Services I Provide

I offer complete frontend and backend development services, with a focus on performance, scalability, and pixel-perfect precision.

Design to Code Conversion

Transform Figma, PSD, or XD designs into dynamic web applications using modern frameworks:

Semantic HTML5
Optimized performance with Next.js and Vue.js
Tailwind CSS for responsive, mobile-first design
SEO best practices included

Gig Link:

Convert Figma, PSD, or XD to React/Next.js

Custom Landing Page Development

Develop clean and modern landing pages optimized for conversions. Built with:

Next.js / React.js / Vue.js
Tailwind CSS
Responsive structure and reusable components

Gig Link:

Design a Custom React/Next.js Landing Page

Full Website Development

Get scalable websites or MVPs tailored for your startup or business:

Multi-page websites or SPAs
Clean, modular code
API integration and state management
Production-ready deployment setup

Gig Link:

Build Responsive Websites with React/Next.js

API Integration & Backend Logic

Connect your frontend to a secure, scalable backend with RESTful or GraphQL APIs:

Node.js + Express.js with MongoDB
JWT or OAuth2 authentication
Secure data handling, efficient queries, and well-documented endpoints

Gig Link:

Integrate REST API or GraphQL into Your Web App

Tech Stack

Frontend: React.js, Next.js, Vue.js, Tailwind CSS, Material UI, Shadcn UI
Backend: Node.js, Express.js, MongoDB, Prisma ORM, Firebase
State Management: Redux, Context API, TanStack Query
API: REST, GraphQL, Axios, Apollo Client
Dev Tools: Git, Vercel, Postman, JWT, Role-Based Access

Recent Projects

Career Props – Job Portal

A scalable HR platform with real-time updates, advanced search, and user roles.

Live: https://career-props.vercel.app

Other notable projects:

Addition (E-Commerce for Influencers)
Truthful Taxes (Financial Services)
HireMaster (Job Portal)
NestEgg (Financial Property Dashboard)

Why Work With Me?

Professional and scalable codebase
Responsive, mobile-friendly design
SEO optimization and fast loading times
Clean and maintainable architecture
Unlimited revisions on standard and premium packages
Clear documentation and post-delivery support

Get in Touch

If you're looking for a developer who values quality, speed, and clean code, I invite you to explore my Fiverr profile and contact me for collaboration.

My Fiverr Profile:

https://www.fiverr.com/mohosin2126

Let’s build something exceptional—custom-coded and performance-optimized.

DEV Community: Md Mohosin Ali Shah

React Query Showed the Wrong User's Data — Here's How to Reproduce and Fix It

1. The bug starts with a perfectly normal-looking query

2. Let's reproduce the problem

Step 1: Create the project

Step 2: Configure QueryClient

Step 3: Create the demo

Step 4: See what happens

Why does this happen?

3. Fixing it with the correct query key

4. The same mistake becomes more complicated in multi-tenant SaaS applications

5. How I'd structure the query in a real application

6. Don't forget what happens on logout

A safer logout strategy

7. Another mistake: showing previous data during account switches

8. Is this actually a security vulnerability?

Scenario A: Client-side cache isolation failure

Scenario B: Broken backend authorization

9. Let's add a test for the cache behavior

10. My checklist before shipping a multi-tenant dashboard

Final thoughts

Further reading

Why Disabling the Submit Button Isn't Enough: Preventing Duplicate Requests in React & Node.js

1. Frontend protection is only the first layer

2. Understanding idempotency

3. Implementing idempotency in React

4. Protecting the database against duplicate inserts

A better approach: Database uniqueness constraints

Handling an existing order

Why not use ON CONFLICT DO UPDATE?

5. What about transactions?

6. Test real failure scenarios

7. The approach I recommend

Final thoughts

RepoLens Version 2 Ranked #7 on Product Hunt — Building AI for Code Change Intelligence

Understanding a Repository Once Is Not Enough

What Changed in Version 2

What I Learned Building It

The Product Hunt Launch

Where RepoLens Is Going

Links

RepoLens Version 2 - Know what changed and what matters

I Shipped v0.3.0 of My Open Source Project Scaffolding CLI

What starter-structure-cli does

What’s new in v0.3.0

New starters added

A cleaner CLI internally

Stronger validation before release

Why I’m building this

Example usage

What I learned from shipping this

1. Template quality matters more than template count

2. Validation becomes essential very quickly

3. Internal cleanup is part of shipping

4. Real users change how you think

What’s next

Try it

I Built a Tool That Turns GitHub Repositories Into Architecture Dashboards - RepoLens Version 01

RepoLens (Version 1) - Know any repo fast.

Live Platform

Open Source Repository

What RepoLens V1 Does

Tech Stack

Why I Built It

Open Core

I Built a CLI That Scaffolds 30+ Fullstack Projects From Natural Language

The Problem

What It Does

The Cool Parts

1. Natural Language Matching

2. Composable Template System

3. Interactive + Non-Interactive

4. Smart Defaults

Generated Project Structures

How I Built It

Try It

What a monorepo needs (the real requirements)

pnpm in monorepos (why it’s usually best)

1) Speed (especially after first install)

2) Disk usage (big win)

What `starter-structure-cli` does