DEV Community: Muhammad Zulqarnain

The Node.js Patterns I Wish I Knew 3 Years Ago

Muhammad Zulqarnain — Fri, 08 May 2026 06:00:00 +0000

Node.js is amazing for shipping fast. It's also amazing at letting you ship broken things fast.

I've built a lot of broken things. Here are the patterns that make Node.js systems not break.

Pattern 1: EventEmitter for Internal Pub/Sub

import { EventEmitter } from 'events';
const orderEvents = new EventEmitter();

async function createOrder(userId, items) {
  const order = await db.orders.create({ userId, items });
  orderEvents.emit('order:created', order);
  return order;
}

orderEvents.on('order:created', async (order) => {
  await sendConfirmationEmail(order).catch(err => logger.error('Email failed', err));
});

orderEvents.on('order:created', async (order) => {
  await logAnalytics('order_created', order).catch(err => logger.error('Analytics failed', err));
});

Result: Order creation returns in 50ms. Side effects async. If email fails, order still succeeded.

Pattern 2: Worker Threads for CPU-Bound Tasks

import { Worker } from 'worker_threads';
const workers = Array(os.cpus().length).fill(null).map(() => new Worker('./worker.js'));
let currentWorker = 0;

function processImage(imageBuffer) {
  return new Promise((resolve, reject) => {
    const worker = workers[currentWorker];
    currentWorker = (currentWorker + 1) % workers.length;
    const timer = setTimeout(() => reject(new Error('Worker timeout')), 30000);
    worker.once('message', (result) => { clearTimeout(timer); resolve(result); });
    worker.once('error', reject);
    worker.postMessage({ imageBuffer });
  });
}

Result: Heavy computation doesn't block the main thread.

Pattern 3: Domain-Specific Error Classes

class AppError extends Error {
  constructor(message, statusCode, code) {
    super(message);
    this.statusCode = statusCode;
    this.code = code;
  }
}

class NotFoundError extends AppError {
  constructor(message) { super(message, 404, 'NOT_FOUND'); }
}

class ValidationError extends AppError {
  constructor(message) { super(message, 400, 'VALIDATION_ERROR'); }
}

app.get('/users/:id', async (req, res, next) => {
  try {
    const user = await getUser(req.params.id);
    res.json(user);
  } catch (err) {
    if (err instanceof AppError) {
      res.status(err.statusCode).json({ error: err.message });
    } else {
      res.status(500).json({ error: 'Internal server error' });
    }
  }
});

Pattern 4: Connection Pooling

const pool = new pg.Pool({
  max: 20,
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 2000,
});

async function getUser(id) {
  const result = await pool.query('SELECT * FROM users WHERE id = $1', [id]);
  return result.rows[0];
}

Pattern 5: Circuit Breaker

class CircuitBreaker {
  constructor(fn, options = {}) {
    this.fn = fn;
    this.failureThreshold = options.failureThreshold || 5;
    this.resetTimeout = options.resetTimeout || 60000;
    this.state = 'CLOSED';
    this.failureCount = 0;
    this.lastFailureTime = null;
  }

  async call(...args) {
    if (this.state === 'OPEN') {
      if (Date.now() - this.lastFailureTime > this.resetTimeout) {
        this.state = 'HALF_OPEN';
      } else {
        throw new Error('Circuit breaker is OPEN');
      }
    }
    try {
      const result = await this.fn(...args);
      this.failureCount = 0;
      this.state = 'CLOSED';
      return result;
    } catch (err) {
      this.failureCount++;
      this.lastFailureTime = Date.now();
      if (this.failureCount >= this.failureThreshold) this.state = 'OPEN';
      throw err;
    }
  }
}

Pattern 6: Graceful Shutdown

async function gracefulShutdown() {
  server.close(async () => {
    logger.info('Server closed');
  });
  const forceShutdown = setTimeout(() => process.exit(1), 30000);
  try {
    await db.close();
    await redis.quit();
    clearTimeout(forceShutdown);
    process.exit(0);
  } catch (err) {
    process.exit(1);
  }
}
process.on('SIGTERM', gracefulShutdown);
process.on('SIGINT', gracefulShutdown);

The Meta Pattern: Async Error Handling

function asyncHandler(fn) {
  return (req, res, next) => Promise.resolve(fn(req, res, next)).catch(next);
}

app.get('/users/:id', asyncHandler(async (req, res) => {
  const user = await db.getUser(req.params.id);
  res.json(user);
}));

app.use((err, req, res, next) => {
  logger.error('Unhandled error', err);
  res.status(500).json({ error: 'Internal server error' });
});

These aren't fancy patterns. They're the ones that keep systems running at 3am without pages.

zunain.com

The Node.js Patterns I Wish I Knew 3 Years Ago

Muhammad Zulqarnain — Fri, 08 May 2026 05:06:33 +0000

Event loop mastery, streams, worker threads, graceful shutdown, and the design patterns that separate senior Node.js engineers from the rest.

Building Production-Ready RAG: A Complete Architecture Guide

Muhammad Zulqarnain — Mon, 27 Apr 2026 16:39:13 +0000

Building Production-Ready RAG: A Complete Architecture Guide

Most RAG tutorials show you how to stuff documents into a vector database and query them with an LLM. That gets you a demo. It does not get you a production system.

I've built RAG pipelines that serve real users. The gap between "it works in a notebook" and "it works at 2 AM when the on-call gets paged" is massive. This guide covers what actually matters when you ship RAG to production.

Why Most RAG Demos Fail

The standard RAG tutorial looks like this: load PDFs, chunk them, embed them, store in Pinecone, query with OpenAI. Five lines of LangChain. Done.

Then you deploy it and discover:

The chunking strategy matters more than the model. Bad chunks produce bad retrieval. Bad retrieval produces hallucinated answers. Users lose trust fast.

Latency kills user experience. A 6-second response time is fine in a demo. Real users expect sub-2 seconds. You need caching, streaming, and careful orchestration.

Cost scales faster than you expect. Every query hits an embedding model and an LLM. At 10K queries per day, your monthly bill will surprise you.

Evaluation is almost impossible without infrastructure. "Does this answer look right?" is not a test strategy.

Let's fix each of these.

The Ingestion Pipeline

Ingestion is where most RAG systems quietly break. Bad data in, bad answers out.

Document Processing

Before you chunk anything, clean your documents. Strip headers, footers, navigation elements, and boilerplate. Extract tables separately because they chunk terribly as plain text.

interface ProcessedDocument {
  id: string;
  content: string;
  metadata: {
    source: string;
    title: string;
    section: string;
    lastUpdated: Date;
    documentType: 'article' | 'api-doc' | 'tutorial' | 'faq';
  };
}

async function processDocument(raw: RawDocument): Promise<ProcessedDocument[]> {
  // Split by semantic sections, not arbitrary character counts
  const sections = extractSections(raw.html);

  return sections.map((section, index) => ({
    id: `${raw.id}-section-${index}`,
    content: cleanMarkdown(section.content),
    metadata: {
      source: raw.url,
      title: raw.title,
      section: section.heading || `Section ${index + 1}`,
      lastUpdated: raw.updatedAt,
      documentType: classifyDocument(raw),
    },
  }));
}

Chunking Strategy

Forget fixed-size chunking. It splits sentences mid-thought and produces chunks that lack context.

Use semantic chunking: split on paragraph boundaries, heading boundaries, and logical breaks. Each chunk should be a self-contained thought that makes sense in isolation.

function semanticChunk(
  document: ProcessedDocument,
  options: { maxTokens: number; overlap: number }
): Chunk[] {
  const paragraphs = document.content.split(/\n\n+/);
  const chunks: Chunk[] = [];
  let currentChunk: string[] = [];
  let currentTokens = 0;

  for (const paragraph of paragraphs) {
    const paragraphTokens = estimateTokens(paragraph);

    if (currentTokens + paragraphTokens > options.maxTokens && currentChunk.length > 0) {
      chunks.push({
        content: currentChunk.join('\n\n'),
        tokenCount: currentTokens,
        metadata: document.metadata,
      });

      // Keep last paragraph for overlap/context continuity
      const overlapParagraphs = currentChunk.slice(-1);
      currentChunk = [...overlapParagraphs, paragraph];
      currentTokens = estimateTokens(overlapParagraphs.join('\n\n')) + paragraphTokens;
    } else {
      currentChunk.push(paragraph);
      currentTokens += paragraphTokens;
    }
  }

  if (currentChunk.length > 0) {
    chunks.push({
      content: currentChunk.join('\n\n'),
      tokenCount: currentTokens,
      metadata: document.metadata,
    });
  }

  return chunks;
}

Target chunk size: 200-500 tokens. Smaller chunks give more precise retrieval. Larger chunks give more context. I've found 300-400 tokens to be the sweet spot for most documentation use cases.

Embedding Models

For production, I use OpenAI's text-embedding-3-small for most cases. It's cheap ($0.02 per 1M tokens), fast, and the quality is good enough for 90% of use cases.

If you need better retrieval quality and can afford the latency, text-embedding-3-large with dimension reduction to 1024 gives excellent results at a reasonable cost.

async function embedChunks(chunks: Chunk[]): Promise<EmbeddedChunk[]> {
  // Batch embeddings for efficiency (max 2048 per request)
  const batchSize = 2048;
  const results: EmbeddedChunk[] = [];

  for (let i = 0; i < chunks.length; i += batchSize) {
    const batch = chunks.slice(i, i + batchSize);
    const response = await openai.embeddings.create({
      model: 'text-embedding-3-small',
      input: batch.map(c => c.content),
    });

    for (let j = 0; j < batch.length; j++) {
      results.push({
        ...batch[j],
        embedding: response.data[j].embedding,
      });
    }
  }

  return results;
}

The Retrieval Layer

Vector similarity search alone is not enough. You need hybrid search and re-ranking.

Hybrid Search with pgvector

If you're already running PostgreSQL, use pgvector. One less service to manage. Combine vector similarity with full-text search for hybrid retrieval.

async function hybridSearch(
  query: string,
  queryEmbedding: number[],
  options: { limit: number; minScore: number }
): Promise<SearchResult[]> {
  const results = await db.query(`
    WITH vector_results AS (
      SELECT id, content, metadata,
             1 - (embedding <=> $1::vector) AS vector_score
      FROM chunks
      WHERE 1 - (embedding <=> $1::vector) > $3
      ORDER BY embedding <=> $1::vector
      LIMIT $2 * 2
    ),
    text_results AS (
      SELECT id, content, metadata,
             ts_rank(search_vector, plainto_tsquery('english', $4)) AS text_score
      FROM chunks
      WHERE search_vector @@ plainto_tsquery('english', $4)
      ORDER BY text_score DESC
      LIMIT $2 * 2
    )
    SELECT COALESCE(v.id, t.id) AS id,
           COALESCE(v.content, t.content) AS content,
           COALESCE(v.metadata, t.metadata) AS metadata,
           COALESCE(v.vector_score, 0) * 0.7 + COALESCE(t.text_score, 0) * 0.3 AS combined_score
    FROM vector_results v
    FULL OUTER JOIN text_results t ON v.id = t.id
    ORDER BY combined_score DESC
    LIMIT $2
  `, [queryEmbedding, options.limit, options.minScore, query]);

  return results.rows;
}

The 0.7/0.3 weighting between vector and text scores works well as a starting point. Tune it based on your evaluation results.

Re-ranking

After retrieval, re-rank the results. A cross-encoder model gives much better relevance scores than cosine similarity alone. Cohere's re-rank API is the easiest option.

async function rerankResults(
  query: string,
  results: SearchResult[],
  topK: number = 5
): Promise<SearchResult[]> {
  const response = await cohere.rerank({
    model: 'rerank-english-v3.0',
    query,
    documents: results.map(r => r.content),
    topN: topK,
  });

  return response.results.map(r => ({
    ...results[r.index],
    relevanceScore: r.relevanceScore,
  }));
}

This step alone improved our answer quality by about 15% in our evaluations.

The Generation Layer

Prompt Design

Your system prompt should be specific about the task, the constraints, and the expected format. Vague prompts produce vague answers.

function buildPrompt(query: string, context: SearchResult[]): string {
  const contextBlock = context
    .map((c, i) => `[Source ${i + 1}: ${c.metadata.title}]\n${c.content}`)
    .join('\n\n---\n\n');

  return `You are a technical documentation assistant. Answer the user's question using ONLY the provided context. If the context doesn't contain enough information to answer fully, say so clearly.

Rules:
- Cite sources using [Source N] format
- If you're unsure, say "I'm not confident about this" rather than guessing
- Keep answers concise and technical
- Include code examples when relevant

Context:
${contextBlock}

Question: ${query}`;
}

Streaming Responses

Users should see the answer forming in real time. Stream tokens as they arrive.

async function* generateAnswer(
  query: string,
  context: SearchResult[]
): AsyncGenerator<string> {
  const prompt = buildPrompt(query, context);

  const stream = await openai.chat.completions.create({
    model: 'gpt-4o-mini',
    messages: [{ role: 'user', content: prompt }],
    stream: true,
    temperature: 0.1, // Low temperature for factual answers
    max_tokens: 1000,
  });

  for await (const chunk of stream) {
    const content = chunk.choices[0]?.delta?.content;
    if (content) yield content;
  }
}

Hallucination Prevention

Three layers of defense:

Confidence scoring: If no retrieved chunk scores above 0.75 relevance, don't generate an answer. Tell the user you couldn't find relevant information.
Source grounding: The prompt explicitly limits answers to the provided context. This doesn't eliminate hallucinations but reduces them significantly.
Citation verification: Post-process the response. If the model cites [Source 3] but Source 3 doesn't contain the claimed information, flag it.

function validateCitations(
  answer: string,
  sources: SearchResult[]
): ValidationResult {
  const citationPattern = /\[Source (\d+)\]/g;
  const citations = [...answer.matchAll(citationPattern)];
  const issues: string[] = [];

  for (const citation of citations) {
    const sourceIndex = parseInt(citation[1]) - 1;
    if (sourceIndex >= sources.length) {
      issues.push(`Citation [Source ${citation[1]}] references non-existent source`);
    }
  }

  // Check if answer contains claims without any citations
  const sentences = answer.split(/[.!?]+/).filter(s => s.trim().length > 20);
  const uncitedClaims = sentences.filter(
    s => !s.includes('[Source') && looksLikeFactualClaim(s)
  );

  if (uncitedClaims.length > sentences.length * 0.5) {
    issues.push('More than half of factual claims lack citations');
  }

  return {
    valid: issues.length === 0,
    issues,
    citationCount: citations.length,
  };
}

Evaluation

You cannot improve what you cannot measure. Build an evaluation pipeline from day one.

Test Set Construction

Create a test set of 50-100 question/answer pairs. Include edge cases: questions with no answer in the docs, ambiguous questions, questions requiring information from multiple sources.

interface EvalCase {
  query: string;
  expectedAnswer: string;
  relevantDocIds: string[];
  difficulty: 'easy' | 'medium' | 'hard';
  category: 'factual' | 'procedural' | 'conceptual' | 'unanswerable';
}

async function evaluateRAG(testCases: EvalCase[]): Promise<EvalReport> {
  const results = await Promise.all(
    testCases.map(async (tc) => {
      const retrieved = await hybridSearch(tc.query, await embed(tc.query), { limit: 5, minScore: 0.3 });
      const answer = await generateFullAnswer(tc.query, retrieved);

      return {
        query: tc.query,
        retrievalRecall: calculateRecall(retrieved, tc.relevantDocIds),
        answerRelevance: await scoreRelevance(answer, tc.expectedAnswer),
        latencyMs: answer.latencyMs,
        tokenCost: answer.totalTokens,
      };
    })
  );

  return {
    avgRetrievalRecall: avg(results.map(r => r.retrievalRecall)),
    avgAnswerRelevance: avg(results.map(r => r.answerRelevance)),
    avgLatencyMs: avg(results.map(r => r.latencyMs)),
    totalCost: sum(results.map(r => r.tokenCost)),
    results,
  };
}

Key Metrics

Track these in production:

Retrieval recall@5: What percentage of relevant documents appear in the top 5 results? Target: >85%.
Answer relevance: LLM-as-judge scoring against expected answers. Target: >4.0/5.0.
Latency P95: Time from query to first streamed token. Target: <2 seconds.
User feedback rate: Thumbs up/down ratio. Target: >80% positive.
Hallucination rate: Flagged by citation validation. Target: <5%.

Cost Optimization

At scale, RAG costs add up fast. Three strategies that made the biggest difference for us:

Semantic Caching

Cache answers for semantically similar queries. If someone asks "how do I deploy to production?" and another person asks "what's the deployment process?", they should get the same cached answer.

async function getCachedOrGenerate(query: string): Promise<RAGResponse> {
  const queryEmbedding = await embed(query);

  // Check cache for semantically similar queries
  const cached = await db.query(`
    SELECT response, query
    FROM response_cache
    WHERE 1 - (query_embedding <=> $1::vector) > 0.95
    AND created_at > NOW() - INTERVAL '24 hours'
    ORDER BY query_embedding <=> $1::vector
    LIMIT 1
  `, [queryEmbedding]);

  if (cached.rows.length > 0) {
    return { ...cached.rows[0].response, fromCache: true };
  }

  // Generate fresh response
  const response = await generateRAGResponse(query, queryEmbedding);

  // Cache it
  await db.query(
    `INSERT INTO response_cache (query, query_embedding, response) VALUES ($1, $2, $3)`,
    [query, queryEmbedding, response]
  );

  return response;
}

This alone cut our LLM costs by about 40%.

Model Selection

Use gpt-4o-mini for most queries. It's 15x cheaper than gpt-4o and handles straightforward documentation questions just fine. Route complex queries (multi-hop reasoning, comparison questions) to gpt-4o.

Embedding Cost

Pre-compute and store embeddings. Never re-embed a document that hasn't changed. Use a hash of the content to detect changes during re-indexing.

Real-World Performance Numbers

From our production system serving ~5K queries per day:

Average retrieval latency: 45ms (pgvector with HNSW index)
Average generation latency: 1.2s (gpt-4o-mini, streaming)
Time to first token: 380ms
Retrieval recall@5: 88%
User satisfaction (thumbs up): 84%
Monthly cost: ~$280 (embeddings + LLM + infrastructure)
Cache hit rate: 38%

These numbers are realistic for a mid-scale documentation search system. Your numbers will vary based on document corpus size, query complexity, and model choice.

Wrapping Up

Production RAG is not about picking the right model. It's about building a system with good data pipelines, smart retrieval, proper evaluation, and cost controls.

Start with the simplest version that works. Measure everything. Improve the pieces that matter most based on your metrics.

The code examples in this article are simplified but functional. Adapt them to your stack and your data.

If you're building RAG right now, I'd love to hear what challenges you're hitting. Drop a comment or reach out.

Stop Building AI Wrappers. Start Building AI Products.

Muhammad Zulqarnain — Fri, 24 Apr 2026 06:00:00 +0000

Everyone and their brother is building an AI wrapper right now.

You know the type: "I built a ChatGPT UI with a prompt." "I wrapped Claude and added a database." "I made an AI that does X by just calling the API."

These are not products. They're proofs of concept that will be dead in 6 months.

Here's the difference between an AI wrapper and an AI product, and why it matters.

What's an AI Wrapper?

Wrapper = LLM API + UI/UX

"Prompt builder for GPT" — still just calling GPT
"AI email writer" — just Claude, but for emails
"Chat interface that remembers context" — ChatGPT but persistent

These have zero defensibility. When OpenAI releases ChatGPT Plus with the same features, your wrapper dies.

What's an AI Product?

AI Product = (Proprietary Data + Specialized Model + Workflow Integration + User Loop)

Cursor: Code editor that understands your specific codebase. Remove AI, product breaks.
Perplexity: Web search + AI reasoning over sources + citations. The synthesis is the product.
Replit Agent: AI that executes code, sees errors, iterates. The feedback loop is the product.

The 5 Differences

1. Proprietary Data

Wrapper: Uses public information
Product: Has a data moat

2. Specialized vs. General

Wrapper: Uses a general LLM
Product: Fine-tunes for specific task

3. Workflow Integration

Wrapper: Standalone tool
Product: Integrated into how users work

4. Feedback Loop

Wrapper: Fire and forget
Product: Learns from user behavior

5. Defensibility

Wrapper: Dead when the LLM vendor ships the same feature
Product: Moat that gets wider with users

How to Build an AI Product

Start with a specific, narrow problem
Identify your data advantage — if the answer is "none," you're building a wrapper
Build the feedback loop from day 1 — capture accept/reject/edit signals
Integrate into user workflow
Fine-tune or specialize your model
Think about the data flywheel

The Investment Thesis

Wrapper: "We built a UI for Claude." — VCs pass
Product: "We trained a model on your domain data and it handles 60% of your support tickets." — VCs listen

Build for defensibility. Not demo impressiveness.

More at zunain.com.

From $200/Month to Free: Running OpenClaw with Local AI Models

Muhammad Zulqarnain — Sun, 19 Apr 2026 18:15:45 +0000

This is a submission for the OpenClaw Writing Challenge

The Problem: AI Assistant Costs Are Skyrocketing

If you're running OpenClaw with cloud-hosted LLMs like Claude or GPT-4, you know the pain. Premium API access can easily cost $200/month or more, and that's assuming moderate usage. For developers, founders, or anyone automating workflows extensively, those costs compound fast.

But here's the thing: OpenClaw doesn't require cloud AI. You can run it entirely locally with open-source models—and in many cases, get comparable results for $0/month in API fees.

This guide walks through three deployment tiers, from completely free to budget-friendly, showing you how to cut your OpenClaw costs to zero while maintaining functionality.

Understanding Your Options

Tier 1: Completely Free (Ollama + Local Models)

Cost: $0/month

Hardware: Any spare laptop/desktop with 8GB+ RAM

Best For: Personal automation, learning, experimentation

How it works:

Ollama lets you run powerful open-source models like Qwen 2.5 (7B/14B), Llama 3, or Mistral locally. These models are surprisingly capable for most automation tasks—code generation, data extraction, text summarization, and workflow orchestration.

OpenClaw connects to Ollama as a model provider, treating your local instance like any cloud API.

Setup Steps:

Install Ollama (Mac/Linux/Windows):

   curl -fsSL https://ollama.com/install.sh | sh

Pull a capable model:

   ollama pull qwen2.5:14b
   # or for lower-end hardware:
   ollama pull qwen2.5:7b

Configure OpenClaw:

In your OpenClaw settings, switch the model provider to ollama and point it to http://localhost:11434.
Test your setup:

Create a simple skill (e.g., "Summarize my emails") and verify it works with your local model.

Tradeoffs:

Your device needs to stay on 24/7 for skills to run
Slightly slower inference than cloud APIs
Smaller context windows (typically 8K-32K tokens vs 128K+ for cloud models)

Real savings: If you were paying $200/month for Claude API access, that's $2,400/year saved.

Tier 2: Budget Cloud ($10-30/month)

Cost: $10-30/month

Hardware: None (cloud-hosted)

Best For: Production workflows, team usage, 24/7 availability

How it works:

If running a local device 24/7 isn't practical, you can deploy Ollama on a cheap VPS (Virtual Private Server) and point OpenClaw to it remotely.

Alternatively, use budget-friendly cloud APIs like:

Minimax API: ~$0.001 per 1K tokens (~$20-30/month for heavy use)
Groq: Fast inference, generous free tier
Together AI: Competitive pricing on open models

VPS Setup Example (DigitalOcean/Hetzner):

Spin up a VPS (~$10-15/month for 8GB RAM):

   # SSH into your VPS
   ssh user@your-vps-ip

Install Ollama:

   curl -fsSL https://ollama.com/install.sh | sh
   ollama pull qwen2.5:14b

Expose Ollama (use a reverse proxy like ngrok or Tailscale for secure access):

   ollama serve --host 0.0.0.0

Point OpenClaw to http://your-vps-ip:11434

Tradeoffs:

Small monthly cost but still 10x cheaper than Claude Max
Requires basic VPS management skills
Latency depends on VPS location

Real savings: Instead of $200/month on cloud APIs, you're paying $15-30/month—saving $170-185/month or $2,040-2,220/year.

Tier 3: Hybrid Approach (Best of Both Worlds)

Cost: Variable ($0-50/month depending on usage)

Strategy: Use local models for routine tasks, cloud APIs for complex reasoning

How it works:

OpenClaw supports multiple model providers simultaneously. You can configure different skills to use different models:

Routine automation (email filtering, data extraction) → Ollama (free)
Complex reasoning (code review, strategic planning) → Claude/GPT-4 (pay-per-use)

This hybrid approach optimizes for both cost and capability.

Configuration Example:

skills:
  email_summarizer:
    model: ollama/qwen2.5:14b

  code_reviewer:
    model: anthropic/claude-3-opus

Real savings: If 80% of your tasks run locally and 20% use cloud APIs, you're looking at ~$40/month instead of $200—saving $160/month or $1,920/year.

Choosing the Right Model

Not all models are created equal. Here's what works well for OpenClaw:

Model	Size	Best For	Context Window
Qwen 2.5	7B-14B	General automation, coding	32K tokens
Llama 3.1	8B-70B	Reasoning, chat	128K tokens
Mistral	7B-22B	Fast inference, multilingual	32K tokens
DeepSeek Coder	6.7B	Code generation, debugging	16K tokens

For most users, Qwen 2.5 14B offers the best balance of capability and resource requirements.

Real-World Example: My 5-Agent Setup

I run 5 OpenClaw agents entirely on Ollama using a spare MacBook Air (16GB RAM):

Email Assistant: Filters, summarizes, drafts replies
Code Helper: Generates boilerplate, reviews PRs
Research Agent: Monitors RSS feeds, summarizes articles
Data Extractor: Pulls structured data from websites
Task Scheduler: Manages my Notion workspace

Total monthly cost: $0 (minus electricity, ~$2-3/month)

Previous cloud API cost: ~$180/month

Annual savings: $2,160

The MacBook runs 24/7, but I was going to keep it plugged in anyway. The agents paid for themselves in week one.

Getting Started: Your First Local OpenClaw Agent

Here's a step-by-step walkthrough to create your first cost-free OpenClaw skill:

1. Install Prerequisites

# Install Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Pull a model
ollama pull qwen2.5:14b

# Verify it's running
ollama list

2. Configure OpenClaw

In your OpenClaw instance:

Navigate to Settings → Model Providers
Add a new provider: Ollama
Set endpoint: http://localhost:11434
Test connection

3. Create a Simple Skill

Let's build an Email Summarizer:

# Example skill configuration
name: "Daily Email Summary"
trigger: "cron: 0 8 * * *"  # Run at 8 AM daily
model: "ollama/qwen2.5:14b"

prompt: |
  Summarize these emails into a concise bullet-point list.
  Focus on action items and key information.

  {email_content}

output_format: "markdown"
notification: "slack"

4. Test & Iterate

Run the skill manually first:

openclaw run email-summarizer --test

Once it works, let it run on schedule. Monitor performance and adjust the prompt as needed.

Tips for Optimizing Local Model Performance

Use quantized models: GGUF 4-bit quantization runs 2-3x faster with minimal quality loss
Batch requests: Process multiple items together to maximize throughput
Cache responses: For repetitive tasks, cache and reuse model outputs
Monitor resources: Use htop or Activity Monitor to track CPU/GPU usage
Upgrade RAM if needed: 16GB is the sweet spot for running 14B models comfortably

When Cloud APIs Still Make Sense

Local models aren't always the answer. Stick with cloud APIs when:

You need cutting-edge reasoning (GPT-4o, Claude Opus for complex tasks)
Context windows matter (analyzing 100K+ token documents)
Latency is critical (sub-second response times)
You don't have suitable hardware (less than 8GB RAM)

The hybrid approach (local for most tasks, cloud for special cases) often delivers the best ROI.

Conclusion: Take Control of Your AI Costs

OpenClaw's flexibility means you're not locked into expensive cloud APIs. Whether you go fully local with Ollama, deploy a budget VPS, or use a hybrid strategy, you can dramatically reduce costs without sacrificing functionality.

Key takeaways:

✅ Local models (Ollama + Qwen/Llama) work for 80%+ of automation tasks
✅ VPS deployment costs $10-30/month vs $200+ for cloud APIs
✅ Hybrid approach balances cost and capability
✅ Annual savings of $1,920-2,400 are realistic

If you're spending over $100/month on AI API access, it's time to evaluate local options. OpenClaw makes it easy.

Resources

OpenClaw Docs: docs.openclaw.ai
Ollama: ollama.com
Qwen 2.5: huggingface.co/Qwen
Budget VPS Providers: DigitalOcean, Hetzner, Vultr

Have you switched to local models for OpenClaw? What's your setup? Drop a comment below!

EcoMind: AI Carbon Footprint Analyzer for Earth Day 2026

Muhammad Zulqarnain — Sun, 19 Apr 2026 16:05:04 +0000

What I Built

EcoMind is an AI-powered carbon footprint analyzer that helps individuals understand their environmental impact and receive personalized, actionable recommendations to reduce their carbon emissions.

Live Demo: https://ecomind-coral.vercel.app
GitHub: https://github.com/mzunain/ecomind

Demo

EcoMind provides:

🌍 Instant carbon footprint analysis based on your lifestyle
📊 Sustainability score (1-10) with detailed breakdown
💡 Top 5 personalized reduction actions ranked by impact
🌱 Region-specific advice (optimized for Nordic countries)
⚡ Fast, beautiful dark theme UI

Journey

Why Google Gemini?

I chose Google Gemini for its structured JSON output capability, which is perfect for generating consistent, type-safe environmental data. The model excels at understanding complex lifestyle patterns and providing nuanced, regional advice.

Technical Implementation

Using Next.js 15 with the App Router and Google's @google/generative-ai SDK, I implemented:

Structured Schema: Defined a TypeScript schema for carbon analysis
Regional Context: Added location-aware recommendations
Difficulty Scoring: Categorized actions by implementation difficulty
Premium UI: Modern glassmorphism design with Tailwind CSS

Challenges Faced

Model naming: Gemini API model versions required experimentation
Structured output validation: Ensuring consistent JSON responses
Regional accuracy: Balancing global averages with local context (e.g., Finland's clean energy grid)

Category Submission

Best Use of Google Gemini - EcoMind showcases Gemini's strength in structured data generation and contextual understanding for environmental impact analysis.

Additional Prize Categories

N/A

EcoMind: AI-Powered Carbon Footprint Analyzer Using Google Gemini

Muhammad Zulqarnain — Sun, 19 Apr 2026 15:31:31 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

EcoMind is a Next.js web application powered by the Google Gemini API that helps users understand and reduce their personal carbon footprint. You describe your daily habits — commute, diet, home energy use, shopping patterns — and Gemini analyzes your lifestyle, estimates your CO₂ impact, and returns a personalized action plan with concrete steps ranked by impact.

The goal was to make environmental awareness feel personal and actionable rather than abstract. Most carbon calculators spit out a number and leave you wondering "so what?" EcoMind closes that gap by combining Gemini's reasoning capabilities with structured output parsing to give context-aware recommendations tailored to your actual situation.

Key features:

Conversational input: Describe your habits in plain language — no rigid forms
Gemini-powered analysis: Uses gemini-1.5-flash to parse lifestyle data, estimate emissions, and generate recommendations
Structured JSON output: Forced JSON schema response from Gemini for reliable rendering
Actionable breakdown: Each recommendation shows estimated CO₂ savings per year
Finland-aware context: Recommendations factor in northern European energy mix and public transit infrastructure

Demo

🔗 Live demo: https://ecomind-coral.vercel.app

You can also run it locally — instructions in the README.

Code

mzunain / ecomind

AI-powered carbon footprint analyzer using Google Gemini - DEV Weekend Challenge Earth Day Edition

EcoMind 🌍

AI-powered carbon footprint analyzer using Google Gemini

Built for the DEV Weekend Challenge: Earth Day Edition

Live Demo

🔗 https://ecomind-gamma.vercel.app

What It Does

EcoMind lets you describe your daily lifestyle in plain language and returns a personalised carbon footprint analysis powered by the Google Gemini API. No rigid forms — just describe your commute, diet, home heating, and travel habits, and get back:

Estimated annual CO₂ in kg
Sustainability score (1–10)
Top 5 reduction actions ranked by impact with CO₂ savings per year
Regional context — advice tailored to your location (Finland-aware by default)

Tech Stack

Next.js 14 (App Router) + TypeScript
Google Gemini API (gemini-1.5-flash) via @google/generative-ai
Structured JSON output using Gemini's responseSchema feature
Tailwind CSS for styling
Vercel for deployment

Getting Started

# Clone the repo
git clone https://github.com/mzunain/ecomind.git
cd ecomind
# Install dependencies
npm install

# Add your Gemini API key
echo '

…

View on GitHub

How I Built It

Tech Stack:

Next.js 14 (App Router) + TypeScript
Google Gemini API (gemini-1.5-flash) via @google/generative-ai SDK
Tailwind CSS for styling
Vercel for deployment

How Gemini is integrated:

The core of EcoMind is a single API route (/api/analyze) that takes a user's lifestyle description and feeds it to Gemini with a carefully engineered system prompt:

const model = genAI.getGenerativeModel({
  model: "gemini-1.5-flash",
  generationConfig: {
    responseMimeType: "application/json",
    responseSchema: ecoAnalysisSchema,
  },
});

const prompt = `
You are an environmental impact expert. Analyze the following lifestyle description
and return a structured carbon footprint assessment.
Lifestyle: ${userInput}
Provide: estimated annual CO2 in kg, top 5 reduction actions with CO2 savings,
and an overall sustainability score (1-10).
`;

const result = await model.generateContent(prompt);

I used Gemini's structured output / JSON schema enforcement feature to guarantee parseable responses — this was the most interesting technical decision. Instead of prompt-engineering my way to consistent JSON, I defined a Zod-like schema and passed it as responseSchema. This made the frontend rendering completely reliable.

Structured output schema:

const ecoAnalysisSchema = {
  type: "object",
  properties: {
    annualCO2Kg: { type: "number" },
    sustainabilityScore: { type: "number" },
    topActions: {
      type: "array",
      items: {
        type: "object",
        properties: {
          action: { type: "string" },
          annualSavingKg: { type: "number" },
          difficulty: { type: "string", enum: ["easy", "medium", "hard"] },
          category: { type: "string" },
        },
      },
    },
    summary: { type: "string" },
  },
};

Why this matters for Earth Day:
Carbon literacy is one of the biggest blockers to individual climate action. People don't act because the data feels distant. By making it conversational and immediate — type a few sentences about your week and get back a personalized plan — EcoMind lowers that barrier significantly.

I also added a Finland-specific context layer because I'm based in Turku and the sustainability advice for someone in the Nordics (excellent public transit, clean energy grid, cold climate heating costs) is genuinely different from generic global advice.

Prize Categories

Best Use of Google Gemini — Gemini is the core engine of EcoMind. The project uses:

gemini-1.5-flash for fast, cost-effective inference
Structured JSON output with response schema for reliable parsing
A multi-part system prompt that grounds Gemini in environmental science context
Dynamic prompt construction based on user input

5 Next.js Performance Patterns That Cut Our Load Time by 60%

Muhammad Zulqarnain — Mon, 13 Apr 2026 06:00:00 +0000

Performance is a feature.

At Quran.com, we serve 50 million users across 200+ countries on varying networks. A 1-second delay for users on slow connections meant people gave up. Every millisecond mattered.

Here are 5 patterns we implemented that cut load time by 60%. With code.

Pattern 1: Font Subsetting

The Problem: We served the full Amiri Arabic font (600KB) on every page. Users on 3G in Southeast Asia waited 4 seconds for the first render.

The Pattern: Subset fonts to only the Unicode ranges actually used on each page.

@font-face {
  font-family: 'Amiri';
  src: url('/fonts/amiri-subset.woff2') format('woff2');
  font-display: swap;
  unicode-range: U+0600-06FF, U+200C, U+200D;
}

The Result: Font size: 600KB → 48KB. Load time improvement: 40% on mobile.

pyftsubset Amiri-Regular.ttf --unicodes=0600-06FF,200C,200D --output-file=amiri-subset.woff2

Pattern 2: Incremental Static Regeneration (ISR)

The Problem: 114 surahs with 200+ translations. Full site generation: 45 minutes. Deploys blocked.

export async function getStaticProps(context) {
  const data = await fetchSurahData(context.params.surah);
  return {
    props: { data },
    revalidate: 3600,
  };
}

export async function getStaticPaths() {
  const paths = Array.from({ length: 114 }, (_, i) => ({
    params: { surah: String(i + 1) },
  }));
  return { paths, fallback: 'blocking' };
}

On-demand revalidation:

export default async function handler(req, res) {
  if (req.query.secret !== process.env.REVALIDATE_SECRET) {
    return res.status(401).json({ message: 'Invalid token' });
  }
  await res.revalidate(`/surah/${req.query.surah}`);
  return res.json({ revalidated: true });
}

The Result: Pages cached on CDN, served in <100ms globally.

Pattern 3: Dynamic Imports for Heavy Components

The Problem: Quran player: 350KB bundled. Every user downloads it even if they never use audio.

import dynamic from 'next/dynamic';

const QuranPlayer = dynamic(() => import('@/components/QuranPlayer'), {
  loading: () => <div>Loading player...</div>,
  ssr: false,
});

export default function SurahPage({ data }) {
  const [showPlayer, setShowPlayer] = useState(false);
  return (
    <div>
      <SurahText data={data} />
      {showPlayer && <QuranPlayer surah={data.surah} />}
      <button onClick={() => setShowPlayer(true)}>Play Audio</button>
    </div>
  );
}

Result: 68% of users never click play. They saved the download entirely.

Pattern 4: Image Optimization Pipeline

The Problem: Users upload 3-5MB JPEGs displayed at 120x120px.

import sharp from 'sharp';

export default async function handler(req, res) {
  const buffer = Buffer.from(req.body);
  const webpBuffer = await sharp(buffer).resize(400, 400, { fit: 'cover' }).webp({ quality: 80 }).toBuffer();
  const pngBuffer = await sharp(buffer).resize(400, 400, { fit: 'cover' }).png({ quality: 80 }).toBuffer();
  const webpUrl = await uploadToS3(webpBuffer, 'image.webp');
  const pngUrl = await uploadToS3(pngBuffer, 'image.png');
  res.json({ webpUrl, pngUrl });
}

<picture>
  <source srcSet={image.webpUrl} type="image/webp" />
  <img src={image.pngUrl} alt="User avatar" width={120} height={120} />
</picture>

Result: Images: 3-5MB → 45-80KB.

Pattern 5: Intelligent Prefetching

export function SurahNavigation({ currentSurah }) {
  const router = useRouter();
  const handlePrefetch = () => router.prefetch(`/surah/${currentSurah + 1}`);
  return (
    <Link href={`/surah/${currentSurah + 1}`} onMouseEnter={handlePrefetch} onTouchStart={handlePrefetch}>
      Next Surah
    </Link>
  );
}

Result: Users feel instant navigation. Pages load in <200ms instead of 1-2s.

Before/After

Metric	Before	After	Improvement
First Contentful Paint	3.2s	1.8s	44%
Largest Contentful Paint	4.8s	1.9s	60%
Time to Interactive	6.2s	2.4s	61%
Page Size	2.8MB	1.1MB	61%
Lighthouse Score	42	86	+44 pts

Performance work isn't about micro-optimizations. It's about architectural decisions that compound.

Find me at zunain.com if you're optimizing at scale.

How We Scaled Quran.com to 50M Monthly Users: Architecture Lessons From the Inside

Muhammad Zulqarnain — Sun, 05 Apr 2026 23:21:10 +0000

How We Scaled Quran.com to 50M Monthly Users: Architecture Lessons From the Inside

Scaling a web application to serve 50 million monthly users is not just a technical challenge — it is an architectural one. At Quran.com, one of the world's most visited Islamic resources, I led the frontend engineering effort that took the platform from struggling under load to reliably serving tens of millions of users globally.

Here's what I learned.

Start With the Right Foundation: Next.js and ISR

When I joined the team, Quran.com was running a single-page React app with client-side rendering. Every page load hit the server, every user got the same slow first paint. The fix was a full migration to Next.js with Incremental Static Regeneration (ISR).

ISR lets you pre-render pages at build time and revalidate them in the background on a schedule. For content like Surah pages — which rarely change — we set revalidation to 3600 seconds (1 hour). This meant most users hit pre-rendered HTML instantly instead of waiting for server execution.

Result: Time to first byte dropped by over 70% for users in Asia and the Middle East, where our traffic is heaviest.

Edge Caching: The Second Layer

ISR alone was not enough. We layered Cloudflare in front of Vercel, configured to cache ISR-generated pages at the CDN edge. Users in Riyadh, Karachi, Jakarta — wherever they are — now get pages served from a node close to them.

The configuration that made this work:

// next.config.js
module.exports = {
  async headers() {
    return [
      {
        source: '/surah/:id*',
        headers: [
          {
            key: 'Cache-Control',
            value: 'public, s-maxage=3600, stale-while-revalidate=86400'
          }
        ]
      }
    ]
  }
}

The stale-while-revalidate header is the key. It tells the CDN: serve the cached version immediately, and revalidate in the background. Users never wait.

Result: CDN cache hit rate went from ~40% to 92%.

Code Splitting and Bundle Optimization

A 50M-user app cannot afford bloated JavaScript bundles. We audited every dependency and applied aggressive code splitting:

Dynamic imports for heavy components (audio player, translation viewer)
Route-based splitting via Next.js dynamic routing
Moving user preferences (theme, language settings) to client-side state to avoid cache busting on every personalized request

Result: Initial JS bundle size reduced by ~45%.

What Scaling Actually Teaches You

The biggest lesson from working at this scale: the architecture decisions that seem like premature optimization are often the decisions that matter most.

ISR is not a performance trick — it is a scalability strategy. At 50 million users, every millisecond you shave off the critical path compounds. A 100ms improvement in TTFB means millions of users per day load faster, engage more, and return more often.

If you are building a content-heavy Next.js application, do not wait until you have scale problems to think about ISR and edge caching. Build it right the first time.

The Stack at a Glance

Framework: Next.js 14 (App Router, ISR)
CDN: Cloudflare
Deployment: Vercel
State: React Query + Zustand
Languages: TypeScript throughout

If you have questions about scaling Next.js in production or want to talk architecture, reach out at zunain.com.

Building a Production RAG Pipeline: Lessons from Real-World AI Apps

Muhammad Zulqarnain — Sun, 05 Apr 2026 19:23:37 +0000

Building a Production RAG Pipeline: Lessons from Real-World AI Apps

RAG (Retrieval-Augmented Generation) sounds simple on paper — embed your documents, store them in a vector DB, retrieve the relevant chunks, and pass them to an LLM. In practice, getting a RAG pipeline to production quality is significantly harder.

Here's what I learned building RAG pipelines for real SaaS products.

The Naive Implementation

Most tutorials show you this flow:

Chunk your documents
Embed them with OpenAI
Store in Pinecone
Retrieve top-k chunks
Pass to GPT-4

This works fine in demos. It fails in production for a few key reasons.

Problem 1: Chunking Strategy Kills Retrieval Quality

Naive fixed-size chunking (every 512 tokens) destroys semantic context. A paragraph about "authentication" gets split mid-sentence, and your retrieval picks up half-relevant chunks.

What works: Semantic chunking — split at natural sentence and paragraph boundaries, and use overlapping windows so context carries across chunk boundaries.

def semantic_chunk(text, chunk_size=500, overlap=50):
    sentences = split_into_sentences(text)
    chunks = []
    current_chunk = []
    current_length = 0

    for sentence in sentences:
        if current_length + len(sentence) > chunk_size:
            chunks.append(' '.join(current_chunk))
            # Keep last N tokens as overlap
            current_chunk = current_chunk[-overlap:]
            current_length = sum(len(s) for s in current_chunk)
        current_chunk.append(sentence)
        current_length += len(sentence)

    return chunks

Problem 2: Top-K Retrieval Without Re-ranking

Retrieving the top 5 chunks by cosine similarity often misses the point. The 6th most similar chunk might be the most relevant one in context.

What works: Two-stage retrieval — retrieve top 20 by vector similarity, then re-rank with a cross-encoder model (or GPT-4 itself) to get the final top 5.

Problem 3: No Caching = Expensive at Scale

Every query hitting your vector DB and LLM is a cost. At scale, you'll see the same semantic queries repeatedly.

What works: Semantic caching — hash the embedding of each query and cache results for similar queries (cosine similarity > 0.97).

The Production Stack That Works

Embeddings: OpenAI text-embedding-3-large (best quality/cost)
Vector DB: Pinecone (managed, scales easily) or Weaviate (self-hosted, more control)
Re-ranking: Cohere Rerank API or a local cross-encoder
Caching: Redis with embedding-based similarity check
LLM: GPT-4o for quality, GPT-4o-mini for speed/cost tradeoff

Key Takeaway

Production RAG is 20% architecture and 80% data quality + retrieval tuning. The chunking and retrieval strategy matter more than the LLM choice.

What's been your biggest challenge with RAG in production? Drop it in the comments.

How We Scaled Quran.com to 50M+ Monthly Users: Architecture Lessons from the Inside

Muhammad Zulqarnain — Sat, 04 Apr 2026 20:08:55 +0000

Quran.com is one of the most-visited Islamic websites in the world. During my time there as a Full Stack Engineer, the platform crossed 50 million monthly active users — a milestone that forced us to rethink nearly every assumption we'd made about architecture, data, and performance.

This post covers the technical decisions that got us there, the tradeoffs we made, and what I'd do differently.

The Scale Reality

50M MAU sounds like an abstract number. In practice it means spikes of hundreds of thousands of concurrent users during Ramadan, Quran audio files being streamed from every continent simultaneously, prayer time calculations for locations across the entire globe, and serving both high-bandwidth users in the West and users on 2G/3G connections in South Asia and Sub-Saharan Africa.

That last point shaped almost every technical decision. You can't optimize purely for fast connections. You have to think about the user opening the site on a 2G connection in rural Pakistan at 3am for Fajr prayer.

Frontend: Next.js as the Foundation

We built on Next.js. Server-side rendering was critical for two reasons: SEO (the Quran text needs to be indexable) and first-load performance on slow connections. Each Surah page (114 in total) is statically generated at build time — meaning the first HTML response is near-instant, no waiting for JS to hydrate before the user sees text.

We were aggressive about code splitting: audio player logic only loads when the user actually interacts with audio. Next.js Image with AVIF/WebP fallback cut image payloads significantly while staying compatible with older devices.

Offline Audio Streaming

One of the most technically interesting problems: how do you let a user listen to Quran recitations with no internet?

Quran audio is broken into individual ayah (verse) recordings — up to 6,236 of them per reciter. You can't cache all of that upfront. Our solution: when a user starts playing a Surah, we silently prefetch the next 10 ayahs in the background using Service Workers and the Cache API. If connectivity drops, playback continues seamlessly. We also gave users an explicit "Download for offline" option for Surahs they listen to regularly.

Geospatial: Prayer Times at Scale

Prayer times are calculated based on GPS coordinates — simple until you consider DST rules that differ by country, multiple calculation methodologies (Hanafi, Shafi'i, MWL, ISNA), and users who want accurate times regardless of whether they share their location.

We moved prayer time calculation to the client side. The astronomy math runs in under a millisecond on any modern device, requires no server round-trip, and stores no user location data.

For map-based features — nearby mosques, Qibla direction — we used Mapbox GL JS. The vector tile approach is ideal: compact, cacheable, and sharp at any zoom level.

Database and Infrastructure

PostgreSQL was our primary data store. The Quran text is relational in nature — verses have translations, tafsirs, word-by-word breakdowns, audio timestamps, and cross-references. A relational model maps cleanly to this structure.

For our read-heavy endpoints (almost all of them), we leaned on read replicas to distribute query load, Redis for caching frequently-accessed data, and aggressive CDN caching at the edge for static API responses.

Infrastructure ran on AWS: ECS for containerized services, RDS for PostgreSQL, ElastiCache for Redis, CloudFront as CDN.

What I'd Do Differently

Invest in observability earlier. We added distributed tracing later than we should have. When you're debugging a latency spike that only affects users in a specific region, you want granular trace data — not logs.

Be more aggressive with edge caching. Many API responses could have been fully cached at the CDN layer, eliminating server load for the vast majority of requests. We were conservative about this early and paid the price during Ramadan traffic spikes.

Design for low-bandwidth from day one. We retrofitted a lot of optimizations later. Starting with that constraint leads to better decisions upfront — smaller bundles, progressive loading, offline-first thinking baked in from the beginning.

Closing Thoughts

Working on a platform where the content matters deeply to hundreds of millions of people sharpens your instincts. Performance isn't vanity. A 3-second improvement in load time is the difference between someone completing Fajr prayer with the app or giving up.

If you're working on similar challenges — high-scale web apps, geospatial features, or offline-capable PWAs — find me at zunain.com or on GitHub at mzulqarnain118.

Next.js Production Apps: Server Components and API Routes

Muhammad Zulqarnain — Tue, 20 Jan 2026 08:00:00 +0000

Next.js has become my framework of choice for building production-ready full-stack applications. Here's how I leverage its powerful features.

Why Next.js?

Complete Full-Stack Solution

Server and client components
Built-in API routes
Automatic code splitting
Optimized image handling
SEO-friendly by default

Server Components (App Router)

// app/page.tsx
import { getProducts } from '@/lib/data';

export default async function HomePage() {
  const products = await getProducts();

  return (
    <main>
      <h1>Products</h1>
      {products.map(product => (
        <ProductCard key={product.id} product={product} />
      ))}
    </main>
  );
}

API Routes

// app/api/products/route.ts
import { NextResponse } from 'next/server';
import { db } from '@/lib/db';

export async function GET() {
  try {
    const products = await db.product.findMany();
    return NextResponse.json(products);
  } catch (error) {
    return NextResponse.json(
      { error: 'Failed to fetch products' },
      { status: 500 }
    );
  }
}

export async function POST(request: Request) {
  const body = await request.json();
  const product = await db.product.create({ data: body });
  return NextResponse.json(product);
}

Data Fetching Patterns

// Server Component - Direct database access
async function getUser(id: string) {
  const user = await db.user.findUnique({ where: { id } });
  return user;
}

// With caching
import { unstable_cache } from 'next/cache';

const getCachedProducts = unstable_cache(
  async () => db.product.findMany(),
  ['products'],
  { revalidate: 3600 }
);

My Production Setup

✅ Performance

Image optimization with next/image
Font optimization
Bundle analyzer

✅ SEO

Metadata API
Sitemap generation
robots.txt

✅ Developer Experience

TypeScript throughout
ESLint & Prettier
Tailwind CSS

Next.js simplifies full-stack development while maintaining excellent performance and SEO. The App Router and Server Components have transformed how I build web applications.