DEV Community: Nancy Kataria

Why don't more people know about this? 🤷‍♀️

Nancy Kataria — Wed, 25 Feb 2026 21:59:49 +0000

I’ve been using "Warp - best terminal for building with agents" - for a year now, and I just can't go back to a traditional CLI.

It’s not just a terminal; it’s a terminal-based agent that understands my workflow. Here are the three things I love about it:

Context Awareness: While other AI copilots often get stuck in a "reasoning and solution" loop, Warp acts with precision. It knows exactly which directory you're in and can even make global system modifications.
Command vs. Agent Logic: It’s incredibly smart at distinguishing between "typing a shell command" and "asking the agent a question". No awkward context-switching or copy-pasting into a browser.
Debug Speed: It autodetects errors in real-time and fixes the issue immediately.

If you’re still using a "dumb" terminal, you’re playing on hard mode.

Check it out: https://www.warp.dev/

Codebase Intelligence

Nancy Kataria — Wed, 18 Feb 2026 08:00:11 +0000

Navigating a new repository can be overwhelming. I built "Codebase Intelligence" tool to turn static code into an interactive knowledge base using Retrieval-Augmented Generation. Instead of the AI guessing what your code does, it reads the relevant files before answering.

By using semantic search and vector embeddings, you can ask questions like:
"How is the authentication flow handled?"
"Where are the API routes defined?"
Get a context-aware answer backed by your actual code.

I reached some key milestones while building this tool: automated an ingestion pipeline using LangChain and OpenAI embedding model to fetch, chunk, and embed GitHub repos. Leveraged Pinecone vector database for high-performance semantic search and metadata filtering. Integrated GPT 4.0 and Vercel AI SDK to manage the conversation flow. Implemented GitHub Actions to handle automated daily maintenance and cleanup of the database.

Check it out here: https://codebase-intelligence-nu.vercel.app/

Open Source and Contributions 🌟
I've made this tool open source! Whether you want to use it for your own repos or help improve the ingestion logic, feel free to check out the code or create an Issue.

Github Repository Link: https://github.com/nancy-kataria/codebase-intelligence

GPU Glossary

Nancy Kataria — Mon, 07 Jul 2025 06:48:18 +0000

Today, I came across a GPU Glossary by Modal while learning more about GPU architecture, and honestly, I haven’t found anything that explains GPU concepts this clearly and systematically before.
The best part? The Terminal-inspired UI. It’s so visually appealing that even someone not particularly interested in GPUs might be tempted to explore just because of how cool it looks.

What stood out to me is how interactive the site is. You can jump between sections effortlessly using the keyboard, explore nested topics like Streaming Multiprocessors or Warp Schedulers, and it all feels like navigating a live coding terminal. Every detail feels purposeful — it’s not just informative, it’s fun to use.
I have always been a fan of how creative Modal is with their interfaces, and this glossary is yet another example of their thoughtful design and developer-first thinking.

If you’re into GPUs or just want to see how documentation should be done, check this out! https://modal.com/gpu-glossary

Technical Interview Etiquette

Nancy Kataria — Mon, 31 Mar 2025 16:42:53 +0000

Technical Interviews are a key part of the hiring process. They’re designed to assess our problem-solving ability, technical knowledge, and coding skills. It involves two-way communication. It's important that the interviewer is able to understand us.

Read the problem carefully. Highlight the keywords in the problem. Look at the examples carefully. It might be a special case or might not be big enough.
To communicate understanding, repeat the question back in your own words and get clarification on any misunderstandings. Ask for as much information as the interviewer is willing to give you (e.g. input/output constraints) because it shows your problem-solving abilities to independently think of every possible detail. Ask if you can use a pen and paper to draw out your approach.
Come up with a very basic brute-force approach. Explain how it will work and what could be its runtime. Ask the interviewer what they think about your approach. Don't code until you are asked to.
If they ask you to go for a more optimized approach. Take a moment to think and explain your thought process. (Don't forget to communicate with the interviewer that you need a moment to process.)
Once the interviewer and you are on the same page and they ask you to code, write a beautiful code. Keep explaining what you are writing and for what purpose.
Focus on keeping your code intuitive and understandable. Demonstrate familiarity of clean coding best practices.
Run test cases when you are asked to. The interviewer might suggest some changes in your code before running the test cases.

It's always good to communicate with yourself for more practice while leet coding.

Limitations of React v19 `use` API in Full Stack Frameworks

Nancy Kataria — Fri, 31 Jan 2025 04:46:34 +0000

The use API significantly reduces the need for useState and useEffect in certain scenarios, particularly for handling asynchronous data fetching. Learn more: React v19 documentation.

How it Works:

use(promise) suspends rendering until the promise resolves.
You no longer need to manually handle loading states (useState).
useEffect is not required to trigger data fetching.

The Problem

While working with React v19 and Next.js for a full-stack application, a critical limitation arises when trying to fetch API data using the new use API. Let’s analyze an issue with a scenario where the goal is to stream data from the server component to the client component:

Fetching API Data in a Server Component:

Initially, an API call is made in a server component using:

import { Suspense } from "react";
import Feedbacks from "../../Components/Feedbacks";
import Feedback from "../../Models/Feedback";

const fetchFeedBacks = async (): Promise<FeedbackResponse[]> => {
  try {
    const res = await fetch(`http://localhost:3000/api/getFeedbacks`);
    if (res.ok) {
      throw new Error("Failed to fetch data");
    }
    return res.json();
  } catch (error) {
    console.log(error);
    return []
  }
};

export default function Home() {
  const feedbackPromise: Promise<FeedbackResponse[]> = fetchFeedBacks();

  return (
      <Suspense fallback={<p>waiting for message...</p>}>
        <Feedbacks feedbackPromise={feedbackPromise} />
      </Suspense>
  );
}

Client Component reading the promise values:

"use client";
import React, { use } from "react";

const Feedbacks = ({ feedbackPromise }: { feedbackPromise: Promise<FeedbackResponse[]> }) => {
  const feedbackList: FeedbackResponse[] = use(feedbackPromise);

  return (
    <div>
      {feedbackList?.map((record: FeedbackResponse) => (
        <div key={record._id}>
          <h5>{record.name}</h5>
          <p>{record.feedback}</p>
        </div>
      ))}
    </div>
  );
};

export default Feedbacks;

This works well in development but fails in production when building the app using next build && next start.
The error occurs because the fetch call inside the server component attempts to access the Next.js API route using http://localhost:3000, leading to a connection refusal. The server tries to connect to itself while processing a request, which is not feasible in the production execution context.

Attempted Solutions and Their Problems

1. Switching to a Client Component:

"use client";
const fetchFeedBacks = async (): Promise<FeedbackResponse[]> => {
  try {
    const res = await fetch(`/api/getFeedbacks`);
    if (res.ok) {
      throw new Error("Failed to fetch data");
    }
    return res.json();
  } catch (error) {
    console.log(error);
    return []
  }
};

Making the Home component as a client component and using a relative URL (/api/getFeedbacks) to call the API results in hydration issues.
The client and server reconciliation process does not align, leading to Next.js throwing hydration errors.

2. Fetching Data Where It's Needed:

Normally, you might think of moving the fetch logic to the client component where it's actually used.
However, with the use API, a promise must be passed to the component as a prop, making it harder to manage updates dynamically.

3. Fetching data directly in the Server Component

const fetchFeedBacks = async (): Promise<FeedbackResponse[]> => {
  try {
    await connectDB();
    const feedbackList: FeedbackResponse[] = await Feedback.find({});
    return feedbackList;
  } catch (error) {
    console.log(error);
    return [];
  }
};

export default function Home() {
  const feedbackPromise: Promise<FeedbackResponse[]> = fetchFeedBacks();

  return (
      <Suspense fallback={<p>waiting for message...</p>}>
        <Feedbacks feedbackPromise={feedbackPromise} />
      </Suspense>
  );
}

A potential workaround is to fetch data directly from the database inside the Home server component instead of calling the API route. While this initially works, it introduces another issue:

The fetchFeedbacks function works correctly in localhost, but the data becomes stale after building and deploying the app.
Even when submitting new responses through the form, the page displays old data, even after refreshing.

The Only Viable Solution

Given these limitations, the only working solution is to decouple the backend from Next.js entirely:

Keep the backend running on a different URL (e.g., a separate Node.js/Express server).
Serve the frontend separately using Next.js.
Ensure API calls are directed to an external backend rather than relying on Next.js API routes.

This separation avoids the self-referential API request issue and ensures fresh data is always fetched from the backend without running into hydration problems or infinite loops.

Conclusion

The use API in React 19 introduces powerful capabilities but has significant limitations in full-stack frameworks like Next.js. While it simplifies data fetching, it struggles in scenarios where:

API routes are hosted within Next.js itself.
Server components try to fetch from local API endpoints.
Data freshness is a concern in production.

For full-stack applications, separating the backend and frontend into distinct services seems to be the most reliable approach.

Github Repo for the code.

I would like to know about any possible solutions I might not have tried or comments on anything I might be doing wrong until now. If you have encountered similar issues or found alternative approaches, please feel free to share your insights!

Self-Reminder: "You must be imaginative and strong-hearted. You must try things that may not work. Don’t let anyone define your limits because of where you come from. Anyone can code but only the fearless can be great." - Auguste Gusteau, Ratatouille

A Beginner Story

Nancy Kataria — Tue, 14 Jan 2025 00:17:30 +0000

Learning something new can feel overwhelming. Every time I try to explore a new technology, I tend to quit at least once or twice. Sometimes, the documentation is unclear; other times, the technology feels too complex to grasp.

As a beginner, you may find yourself in a pool of bugs when you start coding with a new technology and the app might even crash. But over the years, I’ve realized one thing: you are just 4–5 Google searches away from finding a solution. The key is simple—don’t give up.

When you’re at a beginner level, it’s easy to judge yourself harshly. This feeling intensifies when you’re working in a team or joining a new one during an internship or a job. It’s like being a new character introduced in season 7 of a web series. You’re unfamiliar with the story of the product so far, the tools being used, and the workflows that are already in place.

The people around you seem more experienced, and it’s natural to feel like you’ll never measure up. But here’s the truth: it’s okay to feel like a beginner. Learning is a process, and even the most experienced ones started from 0.

Remember: Never compete or compare yourself with a pro-coder. Always learn from them.

Self-Reminder: "If only we started younger, we would have been so much better. If we knew back then what we do now, things would change. Here's the thing: Today is the youngest you ever will be again, and you still have enough time to become all you want to be in life. The best time to plant a tree may have been 20 years ago but the second best time is right now." - unknown