DEV Community: qudrat ullah

Beyond console.log: A Guide to Production-Ready Logging in Node.js

qudrat ullah — Fri, 17 Apr 2026 16:00:27 +0000

As developers, we all have a favorite debugging tool: console.log. It is simple, it is fast, and it gets the job done when we are trying to figure out why a variable is undefined on our local machine. But the habits we build in development can become liabilities in production. Relying on console.log for a live application is like trying to find a specific grain of sand on a beach. It is inefficient, unstructured, and makes debugging real-world issues a nightmare.

I have seen teams spend hours, sometimes days, sifting through messy, unsearchable log files, all because their logging strategy never matured beyond what they used for local development. Effective logging is not a feature you add at the end. It is a core part of a robust, maintainable, and observable system. Let’s explore how to level up from basic console statements to a professional logging setup that will save you time and headaches.

Why `console.log` Is Not Enough for Production

When your application is running on a server, handling requests from thousands of users, console.log('User created') just does not cut it. Here is why it falls short:

1. No Structure

A console.log statement outputs a simple string. While easy for a human to read one line at a time, it is very difficult for a machine to parse. Imagine you want to find all log entries for a specific user, or only show errors that happened after a certain time. With plain text logs, you are stuck using complex regular expressions. This is slow and error-prone.

Production logs should be structured, typically as JSON. This allows you to easily filter, search, and aggregate logs in a dedicated logging tool.

Before (console.log): User 123 failed to update profile.
After (Structured Log): {"level":"error","time":1678886400000,"pid":456,"hostname":"server-1","userId":123,"msg":"Failed to update profile"}

2. No Log Levels

Not all log messages are equal. A message indicating the server has started is informational. A failed database connection is a critical error. console.log has no concept of severity. While console.warn and console.error exist, they do not offer the granularity needed for a production system.

Standard log levels include:

fatal: The application is about to crash. A critical, service-ending event.
error: A serious error occurred, but the application can continue running (e.g., a failed API call to a third party).
warn: Something unexpected happened that is not an error but should be monitored (e.g., deprecated API usage).
info: Routine information about the application's operation (e.g., server started, user signed in).
debug: Detailed information useful only for debugging, typically turned off in production.
trace: Even more granular information, like detailed function call traces.

Using levels allows you to configure your logger to only output messages of a certain severity. In production, you might set the level to info, while in development, you might set it to debug.

3. Inflexible Output

console.log always writes to the standard output (stdout). In a production environment, you need more control. You might want to write logs to a file, send them to a third-party logging service like Datadog or Logstash, or even suppress them entirely during tests.
A proper logging library allows you to configure different destinations, called "transports" or "streams".

The Pillars of Good Logging

To build a production-ready logging system, we need to focus on a few key principles.

Structured Data: Always log in a machine-readable format like JSON.
Log Levels: Use severity levels to categorize your logs.
Context is King: Every log entry should contain context to help you trace its origin. The most important piece of context is a unique request identifier.
Configurable Destinations: Your application should not care where the logs go. The logging setup should handle routing them to the correct place based on the environment.

Choosing a Library: Pino for Performance

While there are several great logging libraries for Node.js, such as Winston and Bunyan, my go-to choice for new projects is Pino. It is incredibly fast and has very low overhead, which is important in a high-throughput Node.js application. It focuses on doing one thing well: emitting structured JSON logs.

Let’s get started with a basic Pino setup.

First, install it:

npm install pino

Now, let's create a simple logger instance:

// logger.js
const pino = require('pino');

const logger = pino({
  level: process.env.LOG_LEVEL || 'info', // Default to 'info'
  formatters: {
    level: (label) => {
      return { level: label.toUpperCase() };
    },
  },
  timestamp: pino.stdTimeFunctions.isoTime,
});

module.exports = logger;

In this setup, we configure a few things:

The log level is set from an environment variable, falling back to info. This is crucial for controlling log verbosity across different environments.
We use a formatter to make the level label uppercase for consistency.
We set a standard ISO timestamp.

Now you can use this logger anywhere in your app:

const logger = require('./logger');

logger.info('Server is starting...');
logger.warn({ component: 'database' }, 'Connection is a bit slow.');
logger.error(new Error('Failed to connect to Redis'), 'Redis connection error.');

Notice how we can pass an object as the first argument. Pino merges this object into the final JSON log line, which is the perfect way to add context.

A Practical Example: Logging in an Express.js App

Let's integrate our logger into a simple Express server. The goal is to automatically log every incoming request and ensure all logs generated while handling that request are tied together with a unique ID.

We will use pino-http, a companion library for Pino.

npm install express pino-http uuid

Now, let's set up our server:

// server.js
const express = require('express');
const pinoHttp = require('pino-http');
const { v4: uuidv4 } = require('uuid');
const logger = require('./logger');

const app = express();

// Add the pino-http middleware
app.use(pinoHttp({
  logger,
  // Define a custom request ID generator
  genReqId: function (req, res) {
    const existingId = req.id ?? req.headers['x-request-id'];
    if (existingId) return existingId;
    const id = uuidv4();
    res.setHeader('X-Request-Id', id); // Set it on the response header
    return id;
  },
}));

app.get('/', (req, res) => {
  // pino-http adds the logger to the request object
  req.log.info({ user: 'guest' }, 'User accessed the home page');
  res.status(200).send('Hello, world!');
});

app.get('/error', (req, res) => {
  const err = new Error('This is a simulated error!');
  req.log.error({ err }, 'An error occurred on the /error route');
  res.status(500).send('Something went wrong.');
});

app.listen(3000, () => {
  logger.info('Server running on http://localhost:3000');
});

When you run this server and hit the / endpoint, you will see two log lines:

An info log from our route handler.
Another info log that pino-http automatically generates when the response is sent, including the status code and response time.

Both log lines will share the same req.id, which is our unique request identifier. This is incredibly powerful. If a user reports an error, you can ask them for the X-Request-Id from the response header and instantly find every single log associated with their request, even across multiple microservices if you pass the ID along.

Managing Logs in a Production Environment

Generating logs is only half the battle. You also need a strategy for collecting, storing, and analyzing them.

This diagram shows a typical production logging pipeline:

Application (Node.js App): Your application writes JSON logs to stdout.
Log Agent (Log Agent on Server): A lightweight agent (like Fluentd or Vector) running on the same server collects these logs from stdout.
Central Logging Service: The agent forwards the logs to a centralized system like Elasticsearch, Datadog, or Logz.io.
Storage and Analysis: The service stores, indexes, and provides a user interface (like Kibana) for searching, visualizing, and creating alerts from the log data.

This approach decouples your application from the logging backend. Your Node.js app's only job is to write structured logs to standard output. The rest is handled by the infrastructure, which is a key principle of the Twelve-Factor App methodology.

graph TD
    A[Node.js App] -- JSON logs to stdout --> B(Log Agent on Server);
    B -- Ships logs --> C{Central Logging Service};
    C -- Stores & Indexes --> D[(Log Database)];
    E[Developer] -- Queries & Visualizes --> C;
    D -- Provides data --> C;

Best Practices and Common Pitfalls

Finally, here are some hard-won lessons from years of managing production systems.

DO log in JSON. I cannot stress this enough. It is the foundation of modern observability.
DO include a request ID in every log entry related to a request.

DON'T log sensitive information. Never log passwords, API keys, or personally identifiable information (PII). Use Pino's redaction features to automatically strip sensitive fields from your log objects.

const logger = pino({ 
  redact: ['password', 'user.email'] 
});
logger.info({ user: { name: 'Qudrat', email: 'secret@example.com' }, password: '123' });
// The email and password will be replaced with '[REDACTED]'

DO log errors with their stack traces. The error message alone is often not enough. logger.error({ err: myError }, 'A message') will automatically include the stack trace when you pass the error object.
DON'T be too noisy. Logging has a cost, both in performance and in storage. Use the info level for significant events, not for every single function call. Save verbose logging for the debug level, which you can enable on demand.

Moving beyond console.log is a sign of a maturing developer. It shows you are thinking not just about making the code work, but about how it will be operated, monitored, and debugged in the real world. By embracing structured logging, you are building more resilient and maintainable applications, and your future self (and your team) will thank you for it.

About the Author

Hi, I'm Qudrat Ullah, an Engineering Lead with 10+ years building scalable systems across fintech, media, and enterprise. I write about Node.js, cloud infrastructure, AI, and engineering leadership.

Find me online: LinkedIn · qudratullah.net

If you found this useful, share it with a fellow engineer or drop your thoughts in the comments.

Originally published at qudratullah.net.

From Vague to Valuable: A Practical Guide to Prompting LLMs - Generative AI

qudrat ullah — Fri, 17 Apr 2026 15:39:20 +0000

Your First Superpower in Tech

Have you ever tried to get help from an AI chatbot, like ChatGPT, and received a completely useless answer? It feels frustrating. You know it's powerful, but it doesn't seem to understand you.

Think of a Large Language Model (LLM) as a brilliant intern. They have read almost every book and website in existence. They are incredibly fast and knowledgeable. But they are also very literal. They have no real-world experience and will do exactly what you ask, even if it's not what you meant.

Your instruction to this intern is called a "prompt". Learning to write good prompts is like learning a new language for communicating with computers. It is one of the most valuable skills you can build today, whether you are a developer, a student, or just curious about technology. It's a true superpower.

The Core of a Good Prompt

Getting a great result from an LLM isn't about secret tricks or magic words. It's about being clear and providing the right information. Let's break down the four key ingredients of a perfect prompt.

1. Be Specific and Clear

Imagine walking into a coffee shop and saying, "Give me coffee." You might get a black filter coffee, an espresso, or a latte. It's a gamble. Instead, you say, "I'd like a large iced Americano with no sugar." Now you get exactly what you want.

Prompts work the same way. Vague prompts lead to vague answers.

A Bad Prompt:

"Write code for a button."

This is like asking for "coffee". What language? What does it look like? What does it do?

A Good Prompt:

"Write the HTML and CSS code for a clickable button. The button's text should be 'Download Report'. It should have a blue background (#3498db), white text, rounded corners (5px), and a light gray border. When a user hovers over it, the background should change to a darker blue (#2980b9)."

See the difference? We specified the language (HTML/CSS), the text, the colors, the shape, and the behavior. There is no room for guessing.

2. Provide Context

The LLM does not know what you are working on or what you were thinking about five minutes ago. You have to provide all the necessary background information in your prompt.

Think of it like asking a friend for directions. You wouldn't just ask, "How do I get to the library?" You'd say, "I'm currently at the corner of Main Street and Park Avenue. What's the quickest way to walk to the central library from here?"

A Bad Prompt:

"How can I make this function faster?"

The LLM has no idea what "this function" is.

A Good Prompt:

"I'm working on a Python project. I have the following function that searches for a user in a list of a million user objects. It's very slow. How can I make it faster? Here is the code:
def find_user_by_email(users_list, email):
  for user in users_list:
    if user.email == email:
      return user
  return None
"

By providing the code and explaining the problem (it's slow with a large list), you give the LLM the context it needs to provide a helpful answer, like suggesting a dictionary for faster lookups.

3. Define the Persona and Format

One of the most powerful features of LLMs is that you can tell them who to be and how to answer.

Persona: Ask the LLM to adopt a role. This helps shape the tone and style of the response.

"Act as a senior software engineer conducting a code review."
"You are a friendly tutor explaining a complex topic to a beginner."
"Pretend you are a skeptical project manager and point out potential flaws in my plan."

Format: Tell the LLM exactly how you want the output structured.

"Provide the answer as a JSON object."
"Explain the steps in a numbered list."
"Create a markdown table comparing these two databases."

A Good Prompt Combining Both:

"Explain the concept of 'git merge' versus 'git rebase'. Act as a patient mentor talking to a junior developer. Use a simple analogy to explain each one. Finally, summarize the pros and cons of each in a markdown table."

This prompt tells the LLM its role (mentor), the target audience (junior developer), the content required (explanation, analogy), and the final output format (a markdown table). This level of detail almost guarantees a high-quality answer.

4. Iterate and Refine

Your first prompt is often just the beginning of a conversation. Don't be discouraged if the first answer isn't perfect. Use it as a starting point and refine your request.

Think of it like sculpting. You start with a block of clay and slowly shape it.

A typical conversation might look like this:

You: "Give me some ideas for a new mobile app."
LLM: (Gives a generic list: a to-do list app, a fitness tracker, etc.)
You: "Those are okay, but I want something more unique. Focus on apps for people who enjoy gardening."
LLM: (Gives better ideas: a plant identification app, a watering schedule tracker, a community for local gardeners.)
You: "I like the plant identification idea. Can you list the key features for an app like that? Present it as a bulleted list."

Each follow-up prompt gets you closer to the perfect result.

A Couple of Simple "Pro" Tricks

Once you master the basics, you can try these slightly more advanced techniques.

Few-Shot Prompting: Show, Don't Just Tell

Sometimes, the best way to get the format you want is to show the LLM a few examples. This is called "few-shot prompting".

Example:

"I need to extract the main subject from these sentences. Follow the pattern below.

Sentence: The quick brown fox jumps over the lazy dog.
Subject: fox

Sentence: My team is shipping a new feature tomorrow.
Subject: team

Sentence: Artificial intelligence is transforming the world.
Subject:"

By providing examples, you train the model on the exact output you expect. It will almost certainly answer "Artificial intelligence".

Chain-of-Thought: Ask it to Think Step-by-Step

For problems that require logic or calculation, you can ask the LLM to explain its reasoning process. This often leads to more accurate results because it forces the model to break the problem down. Simply add "Let's think step-by-step" to your prompt.

Example:

"I have 50 apples. I give 10 to my friend, then I buy 25 more. I then split the new total evenly among myself and 4 friends. How many apples does each person get? Let's think step-by-step."

The LLM will first calculate the intermediate steps before giving you the final answer, reducing the chance of a simple math error.

Key Takeaways

Writing a good prompt is a skill, and like any skill, it gets better with practice. Don't worry about getting it perfect on the first try.

Remember these key principles:

Be Specific: Avoid vague requests. Detail exactly what you need.
Give Context: Provide all the necessary background information. The LLM knows nothing but what you tell it.
Assign a Persona and Format: Tell the AI who to be and how to structure its answer.
Iterate: Treat it as a conversation. Refine your prompts based on the answers you get.
Show, Don't Tell: Use examples (few-shot) to guide the AI's output for complex formatting.
Think Step-by-Step: For logic problems, ask the AI to show its work.

Mastering this skill will not only help you get better answers from AI but also make you a clearer communicator and a more effective problem-solver. Now go ahead and give that brilliant intern some clear instructions!

About the Author

Find me online: LinkedIn · qudratullah.net

If you found this useful, share it with a fellow engineer or drop your thoughts in the comments.

Originally published at qudratullah.net.

Vector Databases Made Simple: Your First Step Into Modern Data Storage

qudrat ullah — Fri, 17 Apr 2026 13:24:31 +0000

What Are Vector Databases?

Imagine you're organizing your music collection. Instead of just sorting by artist name or genre, you could organize songs by how they "feel" - grouping similar vibes together. Vector databases work similarly, but with data.

A vector database stores information as mathematical representations called vectors. Think of vectors as coordinates that describe the "essence" or "meaning" of your data. Just like GPS coordinates tell you where something is on Earth, vectors tell you where your data sits in a multi-dimensional space of meaning.

Why Should You Care About Vector Databases?

Traditional databases are great for exact matches. If you search for "John Smith," you get exactly "John Smith." But what if you want to find "similar" things? What if you want to search for "happy songs" or "articles about cooking pasta"?

This is where vector databases shine. They excel at:

Similarity search: Finding items that are alike
Semantic search: Understanding meaning, not just keywords
AI applications: Powering chatbots, recommendation systems, and more

How Do Vector Databases Work?

Let me explain with a simple analogy. Imagine you're describing people using only three numbers:

Height (in inches)
Age (in years)
Income (in thousands)

So John might be [70, 25, 45] and Sarah might be [68, 27, 50]. These numbers are vectors. To find people similar to John, you'd look for vectors with numbers close to his.

In real vector databases, instead of 3 numbers, you might have 384 or 1,536 numbers describing the "meaning" of text, images, or other data.

Your First Vector Database Example

Let's build a simple example using Python and a popular vector database called Chroma. Don't worry if you're new to Python - I'll explain each step.

First, install the required packages:

pip install chromadb sentence-transformers

Now, let's create a basic vector database:

import chromadb
from sentence_transformers import SentenceTransformer

# Create a vector database client
client = chromadb.Client()

# Create a collection (like a table in traditional databases)
collection = client.create_collection(name="my_documents")

# Some sample documents
documents = [
    "I love pizza and pasta",
    "The weather is sunny today",
    "Python is a great programming language",
    "I enjoy Italian food very much",
    "It's raining outside right now"
]

# Add documents to our collection
for i, doc in enumerate(documents):
    collection.add(
        documents=[doc],
        ids=[str(i)]
    )

print("Documents added to vector database!")

Now let's search for similar documents:

# Search for documents similar to a query
results = collection.query(
    query_texts=["I like Italian cuisine"],
    n_results=2  # Get top 2 similar results
)

print("Similar documents:")
for doc in results['documents'][0]:
    print(f"- {doc}")

When you run this code, it will find documents about Italian food, even though your search didn't use the exact words "pizza" or "pasta."

Popular Vector Database Options

As a beginner, here are the most beginner-friendly options:

Chroma (Best for Learning)

Easy to set up
Works locally on your computer
Great documentation
Free to use

Pinecone (Best for Production)

Cloud-based (no setup required)
Very fast
Has a free tier
Great for real applications

Weaviate (Best for Advanced Features)

Open source
Lots of built-in features
Can run locally or in the cloud

Common Use Cases You'll See

1. Chatbots and Q&A Systems

When you ask ChatGPT a question, it uses vector databases to find relevant information from its training data.

2. Recommendation Systems

Netflix uses similar technology to recommend movies you might like based on what you've watched.

3. Image Search

Google Photos can find "pictures of dogs" even if you never tagged them as dogs.

4. Document Search

Companies use vector databases to help employees find relevant documents, even with vague queries like "contract about software licensing."

Tips for Getting Started

Start Small

Begin with a few dozen documents. Don't try to build the next Google on day one.

Use Pre-trained Models

Don't create your own vectors from scratch. Use models like sentence-transformers that are already trained.

Test Your Searches

Try different queries and see what results you get. This helps you understand how your vector database "thinks."

Monitor Performance

As your database grows, searches might get slower. Most vector databases have settings to help with this.

Common Beginner Mistakes to Avoid

Mistake 1: Using too many dimensions
More dimensions aren't always better. Start with 384 or 768 dimensions.

Mistake 2: Not preprocessing your data
Clean your text data first - remove extra spaces, fix typos, etc.

Mistake 3: Expecting perfect results immediately
Vector search is about similarity, not exact matches. Results improve as you fine-tune.

What's Next?

Once you're comfortable with basic vector databases, you can explore:

Hybrid search: Combining vector search with traditional keyword search
Fine-tuning: Customizing models for your specific data
Production deployment: Moving from local testing to real applications

Key Takeaways

Vector databases store data as mathematical representations that capture meaning
They excel at finding similar items, not just exact matches
Start with simple tools like Chroma for learning
Use pre-trained models instead of building from scratch
Common applications include chatbots, recommendations, and semantic search
Begin with small datasets and gradually scale up
Vector databases are becoming essential for modern AI applications

Vector databases might seem complex at first, but they're just tools for finding similar things. Start with the simple example above, experiment with different queries, and you'll quickly see their power. The future of search and AI heavily relies on this technology, so learning it now puts you ahead of the curve.

If you want me to go ahead with this topic, feel free to tell me. I'll go deeper with real-world working application demos and how to do that step by step.

Thank you.

About the Author

Find me online: LinkedIn · qudratullah.net

If you found this useful, share it with a fellow engineer or drop your thoughts in the comments.

Originally published at qudratullah.net.

Build Your First AI Search in 30 Minutes: A Complete RAG Tutorial

qudrat ullah — Thu, 16 Apr 2026 20:15:29 +0000

What is RAG and Why Should You Care?

RAG stands for Retrieval-Augmented Generation. Think of it like having a super-smart assistant who can quickly search through your documents and then give you intelligent answers based on what they found.

Imagine you have thousands of company documents, and instead of spending hours searching through them manually, you could just ask questions like "What's our vacation policy?" and get instant, accurate answers. That's exactly what RAG does.

The "Retrieval" part finds relevant information, and the "Generation" part creates human-like responses using that information. It's like combining Google search with ChatGPT, but for your own data.

How RAG Works: The Simple Explanation

RAG works in three simple steps:

Store: Break your documents into small chunks and convert them into numbers (called embeddings) that computers understand
Search: When you ask a question, find the most relevant chunks from your stored data
Generate: Feed those relevant chunks to an AI model (like GPT) to create a natural answer

Think of it like organizing a massive library. Instead of browsing every book, you have a librarian who knows exactly where to find information and can summarize it for you.

Building Your First RAG System

Let's build a simple RAG system that can answer questions about your documents. We'll use Python and some helpful libraries.

Step 1: Install Required Libraries

pip install langchain openai chromadb sentence-transformers

Step 2: Prepare Your Documents

# documents.py
documents = [
    "Our company offers 20 days of paid vacation per year. Employees can carry over up to 5 unused days to the next year.",
    "The office hours are 9 AM to 6 PM, Monday through Friday. Remote work is allowed up to 3 days per week.",
    "Health insurance covers 100% of employee premiums and 80% of family member premiums.",
    "The annual performance review happens in December. Salary increases are effective from January."
]

Step 3: Create the RAG System

# rag_system.py
from langchain.text_splitter import CharacterTextSplitter
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import Chroma
from langchain.llms import OpenAI
from langchain.chains import RetrievalQA
import os

# Set your OpenAI API key
os.environ["OPENAI_API_KEY"] = "your-api-key-here"

class SimpleRAG:
    def __init__(self, documents):
        # Split documents into smaller chunks
        text_splitter = CharacterTextSplitter(chunk_size=500, chunk_overlap=50)
        texts = text_splitter.create_documents(documents)

        # Create embeddings (convert text to numbers)
        embeddings = HuggingFaceEmbeddings()

        # Store in vector database
        self.vectorstore = Chroma.from_documents(texts, embeddings)

        # Set up the question-answering chain
        llm = OpenAI(temperature=0)
        self.qa_chain = RetrievalQA.from_chain_type(
            llm=llm,
            chain_type="stuff",
            retriever=self.vectorstore.as_retriever()
        )

    def ask_question(self, question):
        return self.qa_chain.run(question)

# Usage
from documents import documents

rag = SimpleRAG(documents)
answer = rag.ask_question("How many vacation days do I get?")
print(answer)

Step 4: Test Your RAG System

# test_rag.py
questions = [
    "How many vacation days do I get?",
    "Can I work from home?",
    "When do performance reviews happen?",
    "What does health insurance cover?"
]

for question in questions:
    print(f"Q: {question}")
    print(f"A: {rag.ask_question(question)}")
    print("-" * 50)

Making It Better: Pro Tips

1. Chunk Your Data Smartly

Don't just split text randomly. Split by paragraphs, sentences, or logical sections:

# Better text splitting
from langchain.text_splitter import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200,
    separators=["\n\n", "\n", " ", ""]
)

2. Use Better Embeddings

For better search results, use more powerful embedding models:

from langchain.embeddings import OpenAIEmbeddings

# More accurate but costs money
embeddings = OpenAIEmbeddings()

# Free alternative that works well
from sentence_transformers import SentenceTransformer
embeddings = HuggingFaceEmbeddings(
    model_name="sentence-transformers/all-MiniLM-L6-v2"
)

3. Add Memory for Conversations

from langchain.memory import ConversationBufferMemory

memory = ConversationBufferMemory(memory_key="chat_history")
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=vectorstore.as_retriever(),
    memory=memory
)

Common Mistakes to Avoid

Mistake 1: Using chunks that are too big or too small

Too big: AI gets confused with too much information
Too small: Important context gets lost
Sweet spot: 500-1500 characters per chunk

Mistake 2: Not handling edge cases

def safe_ask_question(self, question):
    if not question.strip():
        return "Please ask a valid question."

    try:
        return self.qa_chain.run(question)
    except Exception as e:
        return f"Sorry, I couldn't process your question: {str(e)}"

Mistake 3: Ignoring document quality

Clean your documents first
Remove unnecessary formatting
Fix typos and inconsistencies

Scaling Up: Next Steps

Once you have a basic RAG system working, you can:

Add more document types: PDFs, Word docs, web pages
Improve the UI: Build a web interface with Streamlit or Flask
Use better databases: PostgreSQL with pgvector for production
Add authentication: Secure your system for multiple users
Monitor performance: Track which questions work well and which don't

Key Takeaways

RAG combines search and AI generation to answer questions about your documents
You need three main components: document storage, similarity search, and text generation
Start simple with basic libraries, then improve gradually
Good document chunking is crucial for accurate results
Test with real questions your users would ask
Always handle errors gracefully in production systems

RAG isn't magic, but it's incredibly powerful when done right. Start with this simple example, experiment with your own documents, and gradually add more features. Before you know it, you'll have built an AI assistant that actually knows about your specific domain.

The best part? This is just the beginning. RAG technology is evolving rapidly, and mastering the basics now will set you up for even more exciting developments ahead.

About the Author

Find me online: LinkedIn · qudratullah.net

If you found this useful, share it with a fellow engineer or drop your thoughts in the comments.

Originally published at qudratullah.net.

Generative AI vs Agentic AI

qudrat ullah — Sun, 25 Jan 2026 15:32:52 +0000

Generative AI vs Agentic AI

Artificial Intelligence is moving fast, and two terms are showing up everywhere:

Generative AI
Agentic AI

They sound similar, but they serve very different purposes.

This article explains the difference in a simple, practical way
no buzzwords, no heavy theory.

🤖 What Is Generative AI?

Generative AI creates content.

You give it a prompt, and it generates an output such as text, images, or code.

Think of Generative AI as a very smart content creator.

It responds to your request, and then it stops.

Common examples

ChatGPT writing text
DALL·E generating images
GitHub Copilot suggesting code
AI summarising documents
AI translating languages

Simple example

You ask:

Write a job description for a frontend developer.

Generative AI:

Generates the text
Returns the response
Ends the interaction

✅ Task completed

❌ No follow-up

❌ No action taken

⚙️ What Is Agentic AI?

Agentic AI doesn’t just generate responses, it takes action.

Instead of only answering, it can:

Understand a goal
Break it into steps
Use tools
Make decisions
Execute tasks
Repeat until the goal is achieved

Think of Agentic AI as a digital worker.

Simple example

You say:

Find family-friendly events in London this weekend and email me the best five.

An Agentic AI might:

Search multiple event websites
Open and analyse pages
Extract dates, prices, and locations
Filter family-friendly events
Rank the best options
Send you an email
Store results for future use

This is not just AI responding — this is AI working toward a goal.

🔑 The Key Difference

Generative AI answers questions.
Agentic AI completes goals.

🧩 Side-by-Side Comparison

Feature	Generative AI	Agentic AI
Generates text or images	✅ Yes	✅ Yes
Makes decisions	❌ No	✅ Yes
Uses tools or APIs	❌ No	✅ Yes
Executes actions	❌ No	✅ Yes
Works autonomously	❌ No	✅ Yes
Has goals	❌ No	✅ Yes

🧠 Everyday Analogy

Generative AI is like a skilled writer.

You ask a question, they write an answer, and the task ends.

Agentic AI is like a personal assistant.

You give a goal, they figure out how to achieve it, and they get it done.

👨‍💻 Why This Matters for Developers

If you’re building:

Chatbots or writing tools → Generative AI
Content generation platforms → Generative AI
Automation systems → Agentic AI
AI assistants or workers → Agentic AI
End-to-end workflows → Agentic AI

Most real-world business value is shifting toward agentic systems.

🚀 Final Takeaway

Generative AI creates content
Agentic AI achieves goals
One responds
The other acts

If Generative AI is the brain,
Agentic AI is the brain plus hands.

🧠 One Last Question for You

We’ve moved very quickly from:

AI that generates answers
to
AI that takes action
The real question now is:

Where should AI stop acting on our behalf?

Should AI agents be fully autonomous?
Or should humans always stay in the loop?
Where do you draw the line between assistant and decision-maker?

👇

I’d love to hear your thoughts in the comments.

How to Fix Chromium on Vercel: A Complete Guide to Solving the “libnspr4.so” Error

qudrat ullah — Fri, 23 Jan 2026 14:26:47 +0000

If you're deploying a Next.js app with Playwright and Chromium to Vercel, you've probably hit this error:

/tmp/chromium: error while loading shared libraries: libnspr4.so: cannot open shared object file: No such file or directory

It works perfectly on your local machine but fails on Vercel. This is one of the most frustrating deployment issues developers face when working with headless browsers in serverless environments.

After analyzing 50+ GitHub issues and testing multiple solutions, I discovered the root cause and the complete fix. Here's everything you need to know.

Why It Works Locally But Fails on Vercel

The fundamental difference between your local environment and Vercel's serverless environment causes this issue.

On your local machine:

System libraries like libnspr4.so and libnss3.so are pre-installed
You have full file system access
Complete Node.js environment with all dependencies

On Vercel serverless:

Minimal Linux container with no system libraries
Read-only file system except for the /tmp directory
Environment variables must exist before modules load

The critical issue: The sparticuz/chromium package checks for AWS_LAMBDA_JS_RUNTIME when the module imports, but if you set it in your code, it happens after the module is already loaded. This timing mismatch breaks everything.

The Five Problems and Their Solutions

Problem 1: Wrong Package Choice

Many developers try to use the full Playwright package, which doesn't work on Vercel.

Don't use:

"playwright": "^1.39.0"

This package exceeds Vercel's 50MB limit and tries to download the browser at runtime, which fails in serverless environments.

Use instead:

{
  "dependencies": {
    "playwright-core": "1.39.0",
    "@sparticuz/chromium": "^131.0.0"
  }
}

Why this works: playwright-core is only about 5MB, and the sparticuz chromium package is about 40MB. Together they stay under Vercel's 50MB limit, and the chromium package provides a pre-bundled Chromium optimized for serverless environments.

Problem 2: Environment Variable Timing

This is where most developers get stuck. The timing of when environment variables are set matters.

The problem:

When you import the package, it immediately checks for AWS_LAMBDA_JS_RUNTIME. But if you set it in your code like this:

import chromiumPack from "@sparticuz/chromium";
process.env.AWS_LAMBDA_JS_RUNTIME = "nodejs22.x";

The module has already loaded and checked for the variable. It's too late.

The solution:

Set the environment variable in the Vercel Dashboard, not just in your code.

Here's how:

Go to Vercel Dashboard
Select your project
Go to Settings → Environment Variables
Add a new variable: AWS_LAMBDA_JS_RUNTIME with value nodejs22.x
Apply to Production, Preview, and Development environments
Redeploy your application

Why the Dashboard matters: Environment variables set in the Vercel Dashboard are available before any modules load, which is exactly when the chromium package needs them.

Problem 3: Libraries Extracted But Not Found (The Critical Fix)

This was the breakthrough that solved the issue. Even when libraries are extracted correctly, Chromium can't find them.

The problem:

Libraries are extracted to /tmp/libnspr4.so and /tmp/libnss3.so
Chromium executable is in /tmp/chromium
But Chromium can't find the libraries because the system doesn't know where to look

The solution:

Set LD_LIBRARY_PATH to the executable directory before launching the browser.

Here's the code:

const executablePath = await chromiumPack.executablePath();
const execDir = path.dirname(executablePath);

// CRITICAL: Set LD_LIBRARY_PATH so Chromium can find libraries
process.env.LD_LIBRARY_PATH = execDir;

Why this works: LD_LIBRARY_PATH tells the Linux system loader where to find shared libraries. By setting it to the same directory where the Chromium executable and libraries are located, Chromium can successfully load the required libraries.

This was the missing piece that most solutions don't mention. Without this, even with the correct environment variable, Chromium will fail to find the libraries.

Problem 4: Old Package Version

Using an outdated version of the chromium package can cause compatibility issues with Node.js 22.x.

Don't use:

"@sparticuz/chromium": "119.0.2"

Use:

"@sparticuz/chromium": "^131.0.0"

Version 131.0.0 has better support for Node.js 22.x and includes fixes for common serverless deployment issues.

Problem 5: Browser Freezing

Some developers report that the browser freezes after creating a new page, even when everything else is configured correctly.

The problem: Browser freezes after "Creating new page" message appears.

The solution:

Disable graphics mode before launching the browser:

if (typeof chromiumPack.setGraphicsMode === 'function') {
  chromiumPack.setGraphicsMode(false);
}

Why: Serverless environments don't have GPU support. Disabling graphics mode prevents the browser from trying to use GPU features that aren't available, which causes freezing.

Complete Working Solution

Here's the complete implementation that works on Vercel:

1. Package.json Configuration

{
  "dependencies": {
    "@sparticuz/chromium": "^131.0.0",
    "playwright-core": "1.39.0"
  },
  "engines": {
    "node": "22.x"
  }
}

2. Next.js Configuration

In your next.config.ts file:

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  serverExternalPackages: [
    'playwright-core',
    '@sparticuz/chromium',
  ],
};

export default nextConfig;

This prevents Next.js from bundling these packages, which is essential for them to work correctly in the serverless environment.

3. Browser Launch Code

Create a file lib/browser.ts with this code:

import { chromium, Browser } from "playwright-core";
import chromiumPack from "@sparticuz/chromium";
import * as path from "path";

let browserInstance: Browser | null = null;

export async function getBrowser(): Promise<Browser> {
  if (browserInstance) return browserInstance;

  const isVercel = !!(process.env.VERCEL || process.env.VERCEL_ENV);

  if (isVercel) {
    // Set runtime (fallback if not in Dashboard)
    if (!process.env.AWS_LAMBDA_JS_RUNTIME) {
      process.env.AWS_LAMBDA_JS_RUNTIME = "nodejs22.x";
    }

    // Set graphics mode to prevent freezing
    if (typeof chromiumPack.setGraphicsMode === 'function') {
      chromiumPack.setGraphicsMode(false);
    }

    // Get executable and set library path
    const executablePath = await chromiumPack.executablePath();
    const execDir = path.dirname(executablePath);

    // CRITICAL: Set LD_LIBRARY_PATH
    process.env.LD_LIBRARY_PATH = execDir;

    browserInstance = await chromium.launch({
      args: chromiumPack.args,
      executablePath,
      headless: true,
    });
  } else {
    // Local development
    browserInstance = await chromium.launch({
      args: ["--no-sandbox"],
      headless: true,
    });
  }

  return browserInstance;
}

4. API Route Configuration

In your API route file (e.g., app/api/screenshot/route.ts):

import { NextRequest, NextResponse } from "next/server";
import { getBrowser } from "@/lib/browser";

export const runtime = "nodejs";
export const maxDuration = 300;
export const dynamic = "force-dynamic";

export async function POST(request: NextRequest) {
  const browser = await getBrowser();
  // Your screenshot code here
}

The runtime = "nodejs" ensures the function runs in the Node.js runtime, and maxDuration = 300 gives you 5 minutes for screenshot operations (requires Vercel Pro plan).

5. Vercel Dashboard Settings

Before deploying, configure these settings in your Vercel Dashboard:

Required settings:

Environment Variable: Add AWS_LAMBDA_JS_RUNTIME with value nodejs22.x
Disable Fluid Compute: Go to Settings → Functions → Fluid Compute → Turn OFF
Pro Plan: Required for 300-second timeouts (Hobby plan only allows 10 seconds)

The Three Critical Fixes

You need all three of these fixes for Chromium to work on Vercel:

Correct packages: Use playwright-core and sparticuz chromium version 131.0.0 or higher
Environment variable: Set AWS_LAMBDA_JS_RUNTIME=nodejs22.x in Vercel Dashboard
Library path: Set LD_LIBRARY_PATH to the executable directory in your code

Missing any one of these will cause the deployment to fail. They work together:

The environment variable tells the package which runtime to use
The library path tells Chromium where to find the extracted libraries
The correct packages ensure everything fits within Vercel's limits

Quick Troubleshooting Checklist

If you're still experiencing issues, check each of these:

[ ] AWS_LAMBDA_JS_RUNTIME=nodejs22.x is set in Vercel Dashboard (not just in code)
[ ] LD_LIBRARY_PATH is set in code before browser launch
[ ] Using playwright-core (not the full playwright package)
[ ] Using sparticuz chromium version 131.0.0 or higher
[ ] setGraphicsMode(false) is called before launching the browser
[ ] Fluid Compute is disabled in Vercel settings
[ ] You're on Vercel Pro plan for extended timeouts
[ ] serverExternalPackages is configured in next.config.ts

Why This Solution Works

This solution addresses all the fundamental differences between local and serverless environments:

Package choice: playwright-core and the chromium package are designed for serverless and stay within size limits
Environment variable: Setting it in the Dashboard ensures it's available when modules load
Library path: LD_LIBRARY_PATH tells the system where to find shared libraries in the minimal serverless environment

The critical insight: Both the environment variable (for runtime detection) and the library path (for finding libraries) are required. Most solutions only mention one or the other, but you need both.

Conclusion

Deploying Chromium on Vercel requires three essential components:

The right packages (playwright-core and the chromium package)
Environment variable configured in Vercel Dashboard
Library path set in your code

Once you have all three configured correctly, your screenshot application will work reliably on Vercel's serverless infrastructure. The key is understanding that serverless environments are fundamentally different from local development, and each difference requires a specific solution.

This solution was discovered after analyzing 50+ GitHub issues and testing multiple approaches. The breakthrough was realizing that LD_LIBRARY_PATH must be set to the executable directory, which most documentation doesn't mention.

Resources

If you found this helpful, feel free to share your experience or ask questions in the comments below!

DEV Community: qudrat ullah

Beyond console.log: A Guide to Production-Ready Logging in Node.js

Why console.log Is Not Enough for Production

1. No Structure

2. No Log Levels

3. Inflexible Output

The Pillars of Good Logging

Choosing a Library: Pino for Performance

A Practical Example: Logging in an Express.js App

Managing Logs in a Production Environment

Best Practices and Common Pitfalls

From Vague to Valuable: A Practical Guide to Prompting LLMs - Generative AI

Your First Superpower in Tech

The Core of a Good Prompt

1. Be Specific and Clear

2. Provide Context

3. Define the Persona and Format

4. Iterate and Refine

A Couple of Simple "Pro" Tricks

Few-Shot Prompting: Show, Don't Just Tell

Chain-of-Thought: Ask it to Think Step-by-Step

Key Takeaways

Vector Databases Made Simple: Your First Step Into Modern Data Storage

What Are Vector Databases?

Why Should You Care About Vector Databases?

How Do Vector Databases Work?

Your First Vector Database Example

Popular Vector Database Options

Chroma (Best for Learning)

Pinecone (Best for Production)

Weaviate (Best for Advanced Features)

Common Use Cases You'll See

1. Chatbots and Q&A Systems

2. Recommendation Systems

3. Image Search

4. Document Search

Tips for Getting Started

Start Small

Use Pre-trained Models

Test Your Searches

Monitor Performance

Common Beginner Mistakes to Avoid

What's Next?

Key Takeaways

Build Your First AI Search in 30 Minutes: A Complete RAG Tutorial

What is RAG and Why Should You Care?

How RAG Works: The Simple Explanation

Building Your First RAG System

Step 1: Install Required Libraries

Step 2: Prepare Your Documents

Step 3: Create the RAG System

Step 4: Test Your RAG System

Making It Better: Pro Tips

1. Chunk Your Data Smartly

2. Use Better Embeddings

3. Add Memory for Conversations

Common Mistakes to Avoid

Scaling Up: Next Steps

Key Takeaways

Generative AI vs Agentic AI

Generative AI vs Agentic AI

🤖 What Is Generative AI?

Common examples

Simple example

⚙️ What Is Agentic AI?

Simple example

🔑 The Key Difference

🧩 Side-by-Side Comparison

🧠 Everyday Analogy

👨‍💻 Why This Matters for Developers

🚀 Final Takeaway

🧠 One Last Question for You

How to Fix Chromium on Vercel: A Complete Guide to Solving the “libnspr4.so” Error

Why It Works Locally But Fails on Vercel

The Five Problems and Their Solutions

Problem 1: Wrong Package Choice

Problem 2: Environment Variable Timing

Problem 3: Libraries Extracted But Not Found (The Critical Fix)

Problem 4: Old Package Version

Problem 5: Browser Freezing

Why `console.log` Is Not Enough for Production