Soumyajit Mukherjee

Posted on Sep 19

Let’s Break Down a Full-Stack RAG Pipeline With React, Node.js & MongoDB

#ai #rag #react #node

If you've built a normal full-stack application, you probably know this architecture:

React → Express → MongoDB

Now let's add an AI-powered RAG pipeline.

Our architecture becomes:

React
  ↓
Express API
  ↓
RAG Service
  ↓
Embedding Model
  ↓
MongoDB Vector Search
  ↓
Relevant Context
  ↓
LLM
  ↓
Response

Let's break it down.

What Are We Building?

Imagine a developer documentation assistant.

Users upload technical documentation, and later ask:

How do I refresh an expired JWT?

Our application searches the uploaded documentation and gives the relevant information to an LLM before generating the response.

This is Retrieval-Augmented Generation (RAG).

1. Document Ingestion

First, documents need to enter our system.

PDF / Markdown / HTML
        ↓
Text Extraction
        ↓
Cleaning
        ↓
Chunking
        ↓
Embeddings
        ↓
MongoDB

Why chunk the documents?

Because retrieving a small relevant section is usually more useful than sending an entire document to the LLM.

Example:

authentication.md

├── Chunk 1
├── Chunk 2
├── Chunk 3
└── Chunk 4

2. Generate Embeddings

Each chunk is converted into a vector.

const embedding = await embeddingModel.embed(chunk);

Conceptually:

"Refresh tokens are used..."
             ↓
[0.12, -0.43, 0.77, ...]

The vector represents the semantic meaning of the text.

3. Store the Data

A MongoDB document might look like:

{
  documentId: "auth-guide",
  content: "Refresh tokens are used...",
  embedding: [0.12, -0.43, 0.77],
  metadata: {
    page: 10,
    source: "auth-guide.pdf"
  }
}

MongoDB Atlas Vector Search can then be used to search these embeddings.

4. User Sends a Question

React sends:

POST /api/chat

{
  "question": "How do I refresh an expired JWT?"
}

Express receives the request.

app.post("/api/chat", async (req, res) => {
  const { question } = req.body;

  const answer = await ragService.ask(question);

  res.json({ answer });
});

5. Embed the Query

The question is converted into an embedding.

User Question
     ↓
Embedding Model
     ↓
Query Vector

Now the query vector can be compared with the document vectors.

6. Retrieve Relevant Chunks

Our vector search might return:

Refresh Token Documentation    0.94
JWT Authentication             0.89
Session Management             0.81
Database Configuration         0.31

We take the most relevant chunks.

This is the retrieval stage.

7. Build the Context

Now we combine the retrieved chunks:

const context = results
  .map(result => result.content)
  .join("\n\n");

Our application now has:

Question
+
Relevant Documentation

8. Build the Prompt

For example:

You are a developer documentation assistant.

Use the context below to answer the question.

Context:
[retrieved documents]

Question:
How do I refresh an expired JWT?

If the context doesn't contain the answer,
say that the information is unavailable.

9. Call the LLM

The backend sends the prompt to the LLM.

const answer = await llm.generate(prompt);

The model generates the response.

Then:

LLM
 ↓
Express
 ↓
React

React displays the answer.

Complete RAG Flow

                 USER
                   ↓
              React UI
                   ↓
             Express API
                   ↓
             RAG Service
                   ↓
          Query Embedding
                   ↓
          Vector Retrieval
                   ↓
           Relevant Chunks
                   ↓
          Context Construction
                   ↓
          Prompt Construction
                   ↓
                  LLM
                   ↓
             Final Answer
                   ↓
                React

The Ingestion Side

Don't forget that there are actually two important pipelines.

Ingestion pipeline

Document
 ↓
Extract
 ↓
Clean
 ↓
Chunk
 ↓
Embed
 ↓
Store

Query pipeline

Question
 ↓
Embed
 ↓
Search
 ↓
Retrieve
 ↓
Build Context
 ↓
LLM
 ↓
Answer

This distinction makes RAG much easier to understand.

Why Chunking Is Important

Imagine a 200-page API reference.

The user asks:

How does refresh-token rotation work?

Sending the entire document to the LLM is inefficient.

Instead, retrieval might identify:

Chunk 47
Chunk 51
Chunk 52

as the relevant sections.

That's what makes the "retrieval" part valuable.

Production Improvements

A basic RAG demo isn't enough for a production application.

We could add:

Authentication
Rate limiting
Caching
Metadata filtering
Hybrid search
Reranking
Query rewriting
Citations
Observability
Token/cost tracking
Prompt-injection defenses

For example:

Query
 ↓
Validation
 ↓
Query Rewriting
 ↓
Hybrid Search
 ↓
Metadata Filtering
 ↓
Reranking
 ↓
Context
 ↓
LLM
 ↓
Citations

Example MERN Structure

server/

├── controllers/
│
├── routes/
│
├── models/
│
├── middleware/
│
└── services/
    ├── embeddingService.js
    ├── retrievalService.js
    ├── ragService.js
    └── llmService.js

Keeping these services separate makes the architecture easier to maintain.

RAG Isn't Just "An LLM + Vector DB"

That's probably the most important lesson.

A useful RAG system depends on:

Document quality
       +
Chunking
       +
Embeddings
       +
Retrieval
       +
Context selection
       +
Prompt design
       +
LLM

If retrieval returns irrelevant information, even a powerful LLM can produce a poor response.

Final Architecture

A simple version:

React
 ↓
Node.js
 ↓
MongoDB Vector Search
 ↓
Relevant Context
 ↓
Gemini / OpenAI-style LLM
 ↓
React

A more advanced version:

React
 ↓
API Gateway
 ↓
Authentication
 ↓
Query Processing
 ↓
Hybrid Retrieval
 ↓
Reranking
 ↓
Context Compression
 ↓
LLM
 ↓
Citation Layer
 ↓
Response

And that's where a simple AI demo starts becoming a real full-stack engineering project.

Final Thought

The LLM is only one part of a RAG application.

The real engineering work happens around it:

ingestion → retrieval → context → generation → security → observability → optimization.

That's what makes RAG such an interesting architecture for full-stack developers.

DEV Community