DEV Community: Atul Tripathi

How to Build a RAG App in Next.js (2026 Guide) — Claude, Pinecone, Voyage AI

Atul Tripathi — Sun, 12 Jul 2026 10:59:37 +0000

If you've tried to build an AI app that answers questions about your own content — docs, PDFs, a knowledge base — you've probably run into RAG (retrieval-augmented generation). It's the pattern behind almost every "chat with your documents" product, and it's simpler than it looks once you break it into pieces.

This guide walks through building one in Next.js: scraping content, embedding it, storing it in a vector database, and streaming answers back with citations. By the end you'll have a working doc-chat pipeline you can extend into your own product.

The four pieces of any RAG app

Every RAG system, no matter how fancy, is four steps wearing a trench coat:

Ingestion — get your content (a webpage, a PDF, a doc) into plain text
Embedding — turn chunks of that text into vectors (numbers that capture meaning)
Storage & retrieval — put those vectors in a database you can search by similarity
Generation — hand the most relevant chunks to an LLM along with the user's question, and stream back an answer

That's it. Everything else — chunking strategy, reranking, multi-tenancy — is refinement on top of these four steps. Let's build each one.

Step 1: Ingestion without a headless browser

If you've scraped web pages in a Next.js serverless function before, you've probably hit the Puppeteer/Playwright wall: huge bundle sizes, slow cold starts, and occasional ESM import conflicts on Vercel. For most content — docs sites, blog posts, articles — you don't need a full browser at all. A DOM parser like Cheerio is enough, because you're not interacting with the page, just reading it.

import * as cheerio from 'cheerio';

async function scrapeUrl(url) {
  const res = await fetch(url, {
    signal: AbortSignal.timeout(15000), // don't hang forever
  });
  const html = await res.text();
  const $ = cheerio.load(html);

  // Strip the noise before extracting text
  $('script, style, nav, footer, header, aside').remove();

  // Prefer semantic content zones, fall back to body
  const main = $('main').text() || $('article').text() || $('body').text();

  return main.replace(/\s+/g, ' ').trim();
}

This runs cleanly inside a standard serverless function — no special runtime config needed. It won't work on JS-rendered SPAs (you'd need a real browser for those), but for the majority of docs and content sites, it's faster and lighter.

Step 2: Chunking and embedding

Raw text is too long to embed as one block — you need to split it into chunks small enough to be semantically coherent but large enough to carry context.

import { RecursiveCharacterTextSplitter } from 'langchain/text_splitter';

const splitter = new RecursiveCharacterTextSplitter({
  chunkSize: 1000,
  chunkOverlap: 200,
});

const chunks = await splitter.splitText(scrapedText);

The overlap matters more than people expect — without it, a sentence that spans a chunk boundary gets cut in half and loses meaning in both halves.

Once you have chunks, you embed them — turn each one into a vector using an embedding model. Here's an underexplained detail worth knowing: most production RAG systems use two different embedding calls, one for documents and one for queries. This is called asymmetric retrieval. A short question ("how do I reset my password?") and a long passage that answers it aren't symmetric in structure, so some embedding models (Voyage AI's among them) let you specify an input_type to optimize the vector space for each side of that mismatch.

import { VoyageEmbeddings } from '@langchain/community/embeddings/voyage';

const documentEmbedder = new VoyageEmbeddings({
  apiKey: process.env.VOYAGEAI_API_KEY,
  modelName: 'voyage-3.5',
  inputType: 'document',
});

const queryEmbedder = new VoyageEmbeddings({
  apiKey: process.env.VOYAGEAI_API_KEY,
  modelName: 'voyage-3.5',
  inputType: 'query',
});

const vectors = await documentEmbedder.embedDocuments(chunks);

Step 3: Storing and retrieving with a vector database

Once you have vectors, you need somewhere to store and search them. Pinecone's serverless tier is a common choice for this because it needs no infrastructure management.

A detail that matters once you have more than one user: namespace-based multi-tenancy. Instead of provisioning a separate index per user or organization, you scope every upsert and query to a namespace string within a single index.

async function upsertVectors(vectors, chunks, namespace) {
  const index = pinecone.index(process.env.PINECONE_INDEX);

  const records = vectors.map((values, i) => ({
    id: `${namespace}-${i}-${Date.now()}`,
    values,
    metadata: { text: chunks[i] },
  }));

  await index.namespace(namespace).upsert(records);
}

async function querySimilar(queryVector, namespace, topK = 5) {
  const index = pinecone.index(process.env.PINECONE_INDEX);
  const results = await index.namespace(namespace).query({
    vector: queryVector,
    topK,
    includeMetadata: true,
  });

  // Filter out weak matches — don't force irrelevant context into the prompt
  return results.matches.filter(m => m.score >= 0.3);
}

One index, unlimited namespaces, and zero cross-contamination between tenants — swap namespace for a userId or orgId and you have multi-tenant isolation without any schema migration.

Step 4: Streaming the answer

This is where retrieval meets generation. You embed the user's question, retrieve the most relevant chunks, inject them into the system prompt, and stream the response back token by token.

export default async function handler(req, res) {
  const { query, namespace } = req.body;

  const queryVector = await queryEmbedder.embedQuery(query);
  const matches = await querySimilar(queryVector, namespace);

  const context = matches.map(m => m.metadata.text).join('\n\n');

  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    Connection: 'keep-alive',
  });

  const stream = anthropic.messages.stream({
    model: 'claude-haiku-4-5-20251001',
    max_tokens: 1024,
    system: `Answer using only the following context. If the context doesn't contain the answer, say so — don't make one up.\n\n<context>\n${context}\n</context>`,
    messages: [{ role: 'user', content: query }],
  });

  // Send sources before any text, so the UI can render citations immediately
  res.write(`data: ${JSON.stringify({ sources: matches.map(m => m.metadata) })}\n\n`);

  stream.on('text', (text) => {
    res.write(`data: ${JSON.stringify({ text })}\n\n`);
  });

  stream.on('end', () => {
    res.write(`data: ${JSON.stringify({ done: true })}\n\n`);
    res.end();
  });
}

Two things worth calling out here:

The system prompt explicitly permits "I don't know." Without that instruction, LLMs tend to answer confidently even when the retrieved context doesn't actually support an answer — graceful degradation beats confident fabrication.
Sending sources before text starts means your frontend can render citation cards immediately, instead of waiting for the full response to know what was cited.

Putting it together

That's a complete, working RAG pipeline: scrape or upload → chunk → embed → store → retrieve → stream. From here, the places to go deeper are chunking strategy (fixed-size vs. semantic chunking), reranking (a second, more expensive relevance pass on your top results), and hybrid search (combining vector similarity with keyword search for queries that need exact matches).

If you'd rather skip the wiring than build it from scratch, I packaged this exact pattern — plus PDF ingestion, demo rate limiting, and multi-tenant namespace isolation — into a Next.js starter kit called FastRAG. There's a live, unauthenticated demo at fastrag.live/demo if you want to see the retrieval quality before deciding either way.

How Forcing 1024-Dim Embeddings Cut Our Pinecone Bill by ~33%

Atul Tripathi — Sun, 05 Jul 2026 04:34:15 +0000

If you've built a RAG pipeline before, you know the pattern: hook up an embedding model, dump vectors into Pinecone, and forget about it until the invoice shows up. That invoice is where most people first realize embedding dimensionality isn't just a technical detail — it's a direct line item on your bill.

Here's what we found while building FastRAG, and why we ended up forcing 1024 dimensions instead of letting the default ride.

The problem: dimension count is a hidden cost multiplier

Pinecone (like most vector databases) charges based on storage, and storage scales linearly with vector dimensionality. A lot of popular embedding models default to 1536 or higher dimensions. That's not wrong, but it's often more resolution than the retrieval task actually needs — especially for the kind of document-chunk semantic search most RAG apps are doing.

The math is simple: every vector at 1536 dimensions costs roughly 50% more to store than the same vector at 1024 dimensions. Multiply that across every chunk of every document a user uploads, and it adds up fast once you have real usage.

Why 1024 and not lower

We didn't pick 1024 arbitrarily. A few considerations:

Retrieval quality holds up. For chunk-level semantic search (as opposed to fine-grained tasks like clustering or classification), 1024 dimensions preserves enough of the embedding space's structure that nearest-neighbor retrieval quality doesn't meaningfully degrade for most document types.
It's a clean truncation point. Many embedding models support Matryoshka-style representation learning or clean dimensionality reduction to 1024 without retraining, which means you're not fighting the model to get there.
Diminishing returns above it. Going from 512 → 1024 tends to show a noticeable jump in retrieval quality. Going from 1024 → 1536 shows a much smaller one, for most general-purpose RAG use cases. You're paying for resolution you can't fully use.

What this actually saved

Forcing this dimensionality across our ingestion pipeline reduced Pinecone storage costs by about a third compared to running with the un-truncated default. That's not a marginal optimization — for anyone running a document-chat product with meaningful upload volume, it's the difference between a Pinecone bill that scales sublinearly with growth and one that doesn't.

How it fits into the pipeline

In FastRAG's ingestion flow, this is enforced at the point of embedding generation, before anything touches the vector store — so it's not a post-hoc cleanup step, it's baked into lib/vector-store.ts from the start. Every chunk, whether it came from a scraped URL or an uploaded PDF, gets embedded and truncated consistently, which also avoids a subtler bug: mixing dimensions across your index, which some vector DBs won't even let you do without a full re-index.

The takeaway

If you're building a RAG app and haven't looked at your embedding dimensionality, it's worth five minutes to check. It's one of the few places where a config-level decision has a direct, compounding effect on unit economics — the kind of thing that's easy to ignore early and expensive to fix later once you have real data volume in the index.

If you want this pre-configured rather than tuning it yourself, that's exactly what FastRAG does out of the box — Pinecone and LangChain wired up with sane defaults, including this one.

Questions about the tradeoffs, or how this interacts with specific embedding models? Drop them in the comments — happy to go deeper on the retrieval-quality side too.

Why building RAG apps feels harder than it should and what I built to fix it

Atul Tripathi — Mon, 26 Jan 2026 12:15:29 +0000

Why building RAG apps feels harder than it should (and what I built to fix it)

Atul Tripathi ・ Jan 26

#webdev #rag #ai #buildinpublic

Why building RAG apps feels harder than it should (and what I built to fix it)

Atul Tripathi — Mon, 26 Jan 2026 12:13:50 +0000

I kept seeing the same pattern whenever someone attempted to create an AI app 🤖

The idea was always exciting 🚀
The demo was always ambitious 💡

Then everything came to a halt ⛔

This happened not because the idea was flawed, but due to messy foundations 🧱
PDF ingestion broke down 📄❌
Scrapers failed on random websites 🕷️⚠️
Embeddings were slow 🐌
The UI wasn’t set up correctly 🧩❌
Every small change brought about three new bugs 🐛🐛🐛

People didn’t quit because they were lazy 😴
They quit because the tools weren’t made for builders who need speed ⚡

So, I created Fastrag 🛠️

Fastrag is a ready-made backbone for RAG-based AI products 🧠
You can plug in PDFs or URLs, and it turns them into a searchable knowledge base with a working chat interface instantly 🔍💬

There’s no need to struggle with infrastructure 🏗️
No more stitching together half-working scripts 🧵❌
You won’t spend your first week on plumbing 🚿

You can start building features on day one 📅
Fastrag takes care of the rest 🤝

Because the real bottleneck in AI isn’t ideas 💭
It’s execution speed 🏎️

Build your AI product this weekend without burning out. 🔥

Uploaded a 120-page PDF instant AI chat. If you want the same setup, FastRAG is live - https://www.fastrag.live/

Atul Tripathi — Sat, 03 Jan 2026 05:37:48 +0000

FastRAG | Ship your AI App in days 🚀

Stop building RAG from scratch. Grab the starter kit with Pinecone & LangChain pre-configured.

fastrag.live

Uploaded a 120-page PDF instant AI chat. If you want the same setup, FastRAG is live - fastrag.live

Atul Tripathi — Sat, 03 Jan 2026 05:37:04 +0000

Uploaded a 120-page PDF instant AI chat. If you want the same setup, FastRAG is live - https://www.fastrag.live/

Atul Tripathi — Sat, 03 Jan 2026 04:59:51 +0000

FastRAG | Ship your AI App in days 🚀

Stop building RAG from scratch. Grab the starter kit with Pinecone & LangChain pre-configured.

fastrag.live

How to Build a "Chat with Website" App using Next.js, LangChain, and Cheerio

Atul Tripathi — Mon, 15 Dec 2025 09:42:10 +0000

Atul Tripathi

Dec 15 '25

How to Build a "Chat with Website" App using Next.js, LangChain, and Cheerio 🦜🔗

#nextjs #tutorial #ai #javascript

2 min read

How to Build a "Chat with Website" App using Next.js, LangChain, and Cheerio 🦜🔗

Atul Tripathi — Mon, 15 Dec 2025 09:41:34 +0000

Building RAG (Retrieval Augmented Generation) apps usually starts with PDFs. 📄
But let's be honest: users really want to chat with live URLs—documentation, wikis, and blogs. 🌐

I spent this weekend adding a Web Scraper to my RAG Starter Kit. Here is the technical breakdown of how I built it, so you can do it too. 👇

🛑 The Problem with Scraping for LLMs

You can't just fetch(url) and pass the HTML to GPT-4.

Too much noise: Navbars, footers, and ads waste tokens. 💸
Context Window: Raw HTML is huge and confuses the model.
Headless Browsers: Tools like Puppeteer are heavy and often timeout on serverless functions (like Vercel). ⏳

🛠 The Stack

Framework: Next.js 14
Scraper: Cheerio (via LangChain). It parses HTML like jQuery, making it lightweight and fast. ⚡️
Vector DB: Pinecone (Serverless).

Step 1: The Scraper Logic 🕷️

We use CheerioWebBaseLoader from LangChain. It grabs the raw HTML and lets us select only the body or specific content tags (like <article>), ignoring the junk.

import { CheerioWebBaseLoader } from "langchain/document_loaders/web/cheerio";

export async function scrapeUrl(url) {
  // 1. Load the URL
  const loader = new CheerioWebBaseLoader(url, {
    selector: "p, h1, h2, h3, article", // 🎯 Only grab text content
  });

  const docs = await loader.load();
  return docs;
}

Step 2: The Cleaning (Smart Chunking) 🧹

LLMs need manageable chunks of text. If you cut a sentence in half, you lose context. We use RecursiveCharacterTextSplitter.


import { RecursiveCharacterTextSplitter } from "langchain/text_splitter";

const splitter = new RecursiveCharacterTextSplitter({
  chunkSize: 1000, // 📏 Tokens per chunk
  chunkOverlap: 200, // 🔗 Overlap to preserve context across chunks
});

const splitDocs = await splitter.splitDocuments(docs);

Step 3: The Cost Hack (1024 Dimensions) 💡

This is the most important part! 💰

By default, OpenAI's embedding models output 1536 dimensions. But Pinecone charges based on storage size.

OpenAI's new text-embedding-3-small allows you to "shorten" the dimensions with minimal accuracy loss.

I configured my implementation to force 1024 dimensions:


const embeddings = new OpenAIEmbeddings({
  modelName: "text-embedding-3-small",
  dimensions: 1024, // 📉 Saves ~33% on storage costs
});

✅ The Result

We now have a clean pipeline: URL ➡️ Clean Text ➡️ Chunks ➡️ Vectors ➡️ Chat.

This allows users to point the app at their documentation and ask questions immediately.

🎁 Want the Full Source Code?

I cleaned up this entire logic (plus Multi-File PDF support, Mobile UI, and Streaming response) and packaged it into a production-ready Starter Kit called FastRAG.

It saves you the ~40 hours of setting up the boilerplate so you can focus on building your AI SaaS over the holiday break. 🎅

🏁 I'm running a "Holiday Build" race:

🥇 First 69 devs: Get 69% OFF (~$9). Code: FAST69

🥈 Everyone else: Get 40% OFF. Code: HOLIDAY40

Check out the Live Demo & Repo here: 👉 FastRAG

Happy coding and happy holidays! 🎄🚀

🛑 Stop Re-Writing RAG Pipelines: My Next.js + Pinecone Architecture ⚡️

Atul Tripathi — Fri, 21 Nov 2025 17:23:16 +0000

Let's be real for a second. ☕️

I have built the "Chat with your PDF" feature for clients about five times in the last two months.

The frontend? Fun. streaming UI, Tailwind, those fancy typing effects... I love it. 🎨
The backend? Absolute headache. 🤯

Every single time, I found myself staring at VS Code, copying and pasting the same boring boilerplate to handle:

❌ The PDF Loader: Chunking text without breaking sentences mid-thought.
❌ The Embeddings: Batching data to OpenAI so I don't hit rate limits.
❌ The Vector Store: Upserting into Pinecone/Supabase without errors.
❌ The Context Window: Calculating tokens so the AI doesn't crash.

After the 5th time, I realized I was wasting 40+ hours per project just setting up the "plumbing" before I could actually build the cool stuff.

So, I decided to fix it. Forever. 🛠️

🏗️ The Architecture

Here is the stack I finally settled on for a production-ready RAG (Retrieval Augmented Generation) app. It's typed, it scales, and it just works.

▲ Framework: Next.js (App Router)
🦜 Orchestration: LangChain.js
🌲 Vector DB: Pinecone (My go-to for speed)
⚡️ Database/Auth: Supabase
💅 Styling: Tailwind CSS

🧠 The Hard Part: Handling Vectors

The biggest pain point isn't the chat; it's the Ingestion Pipeline. You can't just dump a PDF into ChatGPT. You have to slice and dice it first. 🔪

Here is the logic I standardized:

User uploads file 📂
Server reads buffer 👓
RecursiveCharacterTextSplitter breaks it into chunks 🧩
Upsert to Pinecone with metadata 💾

It looks something like this (simplified for sanity):

import { OpenAIEmbeddings } from "langchain/embeddings/openai";
import { PineconeStore } from "langchain/vectorstores/pinecone";
import { RecursiveCharacterTextSplitter } from "langchain/text_splitter";

// 🪄 The logic that usually takes 3 hours to debug
export async function addDocumentsToVectorStore(text, fileId) {

  // 1. Split the text intelligently
  const splitter = new RecursiveCharacterTextSplitter({
    chunkSize: 1000,
    chunkOverlap: 200,
  });

  const docs = await splitter.createDocuments([text]);

  // 2. Embed and Upsert to the Cloud ☁️
  const embeddings = new OpenAIEmbeddings();

  await PineconeStore.fromDocuments(docs, embeddings, {
    pineconeIndex: index,
    namespace: `file_${fileId}`, // 🔒 Isolate vectors per file
  });

  console.log("Vectors Upserted. We are ready to chat. ⚡️");
}

📦 So, I Productized It.

I got tired of setting this up from scratch.

I took my personal repo, cleaned it up, added a polished UI, and turned it into a reusable Starter Kit.

What's inside the box?

✅ Pre-configured LangChain Setup

✅ Built-in Vector Ingestion (PDF/TXT/MD)

✅ Streaming Chat Components (ChatGPT style)

✅ Rate Limiting (Save your API credits!)

🧪 The Experiment (Smoke Test)

I'm running a little experiment this weekend.

Instead of charging the full launch price ($149), I set up a $9 Early Bird Deposit.

Why $9? It acts as a "Skin in the Game" filter. If the pain of building RAG pipelines isn't worth the price of a coffee ☕️, then I know this isn't worth building further.

But if you want to save 40 hours of work?

👉 Grab the RAG Starter Kit (Early Access)

(Even if you don't buy it, feel free to roast my landing page in the comments! I'm building this in public and feedback is gold. 🥇)

Happy Coding! 🚀

Yo!

Atul Tripathi — Mon, 03 Nov 2025 06:32:40 +0000

Data Structure and Algorithms roadmap (with resources)

Atul Tripathi — Mon, 03 Nov 2025 06:19:30 +0000

Atul Tripathi

Nov 1 '25

🚀 LeetCode in 2025

#leetcode #dsa #algorithms #coding

2 min read