DEV Community: Vaibhav Singh

Beyond AI Wrappers: Building AI Systems That Learn to Make Better Decisions

Vaibhav Singh — Sat, 05 Sep 2026 08:15:21 +0000

Over the last few months, I’ve been building an AI application with three priorities:

Quality. Robustness. Accessibility.

But there is another constraint that I’ve started thinking about much more seriously:

How do we make AI intelligent without making every request expensive?

It is very easy to build an AI application today.

Take an LLM API.

Add a system prompt.

Add some context.

Connect a few tools.

Build a UI around it.

And you have an AI application.

There is absolutely nothing wrong with this approach. In fact, this is how many useful AI products are built.

But while working on my own system, I started thinking about a different question:

What happens when we stop thinking of the LLM as the entire intelligence of the application and instead make it one component of a larger learning system?

That question led me toward reinforcement learning, decision-making policies, context selection, adaptive routing, and, most importantly, learning how to use an LLM intelligently.

The AI Wrapper Problem

Let's start with something that is often misunderstood.

An AI wrapper is not inherently bad.

A wrapper can provide enormous value by combining an existing model with:

Better prompts
Retrieval
APIs
Tools
Memory
Structured outputs
Application-specific workflows
A good user experience

The problem isn't the wrapper itself.

The problem is assuming that adding more layers around an LLM automatically means that the application itself is learning.

Consider a simple architecture:

User
  ↓
Prompt
  ↓
Context
  ↓
LLM
  ↓
Response

We can make this architecture considerably more sophisticated:

User
  ↓
Prompt
  ↓
RAG
  ↓
Vector Database
  ↓
Tools / APIs
  ↓
LLM
  ↓
Response

Now we have a powerful application.

But ask yourself:

What happens tomorrow if the same situation occurs again?

If the system doesn't remember the outcome or change its decision-making strategy based on feedback, it is fundamentally executing a predefined workflow again.

The system may have memory.

It may have retrieval.

It may have tools.

But that doesn't necessarily mean it has learned.

Prompting ≠ Learning

This distinction is probably the most important one in my thinking.

With prompting, we essentially tell the model what we want it to do.

For example:

If the user asks about X,
retrieve information from Y,
then answer using Z.

We're defining the behaviour.

A learning system is different.

Instead of explicitly defining every decision, we provide a mechanism through which the system can learn which decisions produce better outcomes.

Conceptually:

Observe
   ↓
Choose Action
   ↓
Execute
   ↓
Observe Outcome
   ↓
Receive Feedback
   ↓
Update Policy
   ↓
Choose Better Action Next Time

The difference is subtle but important.

One approach primarily says:

"Follow these instructions."

The other asks:

"Given what happened previously, which action should I prefer now?"

That is a very different engineering problem.

Fine-Tuning ≠ Reinforcement Learning

Another distinction worth making is between fine-tuning and reinforcement learning.

Fine-tuning generally involves adapting a model using additional training data so that its behaviour becomes better aligned with a particular task, domain, or style.

For example:

General LLM
    +
Domain-specific examples
    ↓
Fine-tuned model

Reinforcement learning approaches the problem from another direction.

Instead of simply saying:

"Here are examples of what I want."

we can define an objective and provide feedback about the quality of actions.

Conceptually:

State
  ↓
Policy
  ↓
Action
  ↓
Environment
  ↓
Reward / Feedback
  ↓
Policy improvement

The important word here is policy.

A policy is essentially a strategy for choosing actions given a particular state or situation.

And this is where I find reinforcement learning particularly interesting for LLM-based systems.

Do We Actually Need to Train the LLM?

This is where my thinking changed.

When people hear "reinforcement learning," they often immediately imagine:

"We're going to train the entire LLM."

But that isn't necessarily what we need.

Instead, we can think about the LLM as one component inside a larger decision-making system.

For example:

                 ┌───────────────┐
                 │     User      │
                 └───────┬───────┘
                         ↓
                ┌─────────────────┐
                │ Context / State │
                └────────┬────────┘
                         ↓
                ┌─────────────────┐
                │ Decision Policy │
                └────────┬────────┘
                         ↓
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
      Retrieve        Use Tool       Call LLM
          │              │              │
          └──────────────┼──────────────┘
                         ↓
                      Outcome
                         ↓
                    Feedback
                         ↓
                  Policy Update

The LLM doesn't have to change every time.

The decision-making layer around the LLM can learn.

This is a much more interesting and potentially more practical architecture.

What Could the System Learn?

This is where things get interesting.

Imagine an AI application receiving a request.

It has several possible actions:

Action 1 → Answer directly
Action 2 → Retrieve documents
Action 3 → Call an external tool
Action 4 → Ask for clarification
Action 5 → Use a stronger model
Action 6 → Perform deeper reasoning

A traditional application might contain hard-coded rules:

if question_is_complex:
    use_big_model()

if question_is_about_documents:
    use_rag()

if question_is_calculation:
    use_calculator()

These rules can work.

But they eventually become complicated.

What if the system encounters a situation we didn't anticipate?

Instead, we could potentially allow a policy to learn which actions tend to produce better outcomes.

For example:

Context A
→ Direct answer
→ Good result
→ Positive reward

Context B
→ Direct answer
→ Poor result
→ Negative reward

Context B
→ Retrieval + LLM
→ Good result
→ Positive reward

Over time, the policy can learn that certain states are better handled using retrieval rather than direct generation.

Token Efficiency

This is one of the main reasons I'm interested in this approach.

There is a common assumption in AI development:

More context = better answer.

That isn't always true.

Suppose an application has 100 pieces of potentially relevant information.

Do we really need to send all 100 to the model?

Maybe only 10 matter.

The other 90 increase:

Input tokens
Latency
Cost
Processing requirements
Potential distraction
Context complexity

So instead of:

Retrieve everything
        ↓
Send everything to LLM
        ↓
Hope the model figures it out

I'm interested in:

Retrieve candidates
        ↓
Evaluate relevance
        ↓
Select useful context
        ↓
Send only what matters
        ↓
Generate response

And eventually, the selection mechanism itself could improve from feedback.

More Tokens ≠ More Intelligence

This is probably one of the biggest misconceptions I have encountered while building AI applications.

If we give a model a massive amount of context, we haven't necessarily made the system smarter.

We may simply have made it more expensive.

Consider these two approaches.

Approach A

100 documents
↓
50,000 tokens
↓
LLM
↓
Answer

Approach B

100 documents
↓
Relevance selection
↓
8 useful documents
↓
4,000 tokens
↓
LLM
↓
Answer

If Approach B produces the same or better result, then the additional 46,000 tokens weren't intelligence.

They were overhead.

This is why I believe token efficiency should be treated as an engineering objective, not merely a billing concern.

The LLM as a Tool

This also changes how I think about LLMs.

Instead of:

"The LLM is the application."

I prefer:

"The LLM is one of the tools available to the application."

The system can decide:

Do I need an LLM here?

If yes:

Which model?

How much context?

Should I retrieve something?

Should I call a tool?

Should I reason more deeply?

Should I use a cheaper model?

Should I escalate to a stronger model?

That creates an additional layer of intelligence.

The model generates.

The system decides when and how generation should happen.

A Possible Architecture

A system I'm interested in exploring looks something like this:

                     USER
                       │
                       ▼
              ┌─────────────────┐
              │ State / Context  │
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │ Decision Policy │
              └────────┬────────┘
                       │
        ┌──────────────┼──────────────┐
        │              │              │
        ▼              ▼              ▼
    Retrieval        Tools          Models
        │              │              │
        │         ┌────┴────┐     ┌───┴────┐
        │         │ APIs    │     │ Small  │
        │         │ Search  │     │ Large  │
        │         │ DB      │     │ Expert │
        │         └─────────┘     └────────┘
        │              │              │
        └──────────────┼──────────────┘
                       ▼
                    Outcome
                       │
                       ▼
              ┌─────────────────┐
              │ Feedback / Eval │
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │ Policy Learning │
              └────────┬────────┘
                       │
                       └──────────► Better decisions

The interesting part isn't necessarily the individual components.

We already have LLMs.

We already have vector databases.

We already have APIs.

We already have agents and tool calling.

The interesting part is the feedback loop connecting them.

Where Reinforcement Learning Fits

Reinforcement learning can potentially be applied to the decision layer.

For example, suppose the state is:

User query
+
Previous conversation
+
Available context
+
System state
+
Historical outcomes

The policy chooses:

Action = retrieve_context

The system performs retrieval and generates an answer.

Then we evaluate the outcome.

Perhaps the user accepts the answer.

Perhaps they ask the same question again.

Perhaps they correct the answer.

Perhaps an evaluator scores it highly.

Perhaps the task fails.

These signals can contribute to the reward.

Conceptually:

State
  ↓
Policy
  ↓
Action
  ↓
Result
  ↓
Reward
  ↓
Policy improvement

The goal isn't to predict the future perfectly.

It is to improve the probability of choosing better actions in future situations.

Reinforcement Learning Doesn't "Know the Future"

This distinction is important.

Sometimes discussions around AI learning make reinforcement learning sound almost magical.

It isn't.

An RL system doesn't suddenly understand the future.

It learns from experience.

If an action repeatedly produces good outcomes in particular situations, the system can learn to prefer that action.

If another action consistently performs poorly, the policy can learn to avoid it.

So the objective is closer to:

Past experience
      ↓
Learn patterns
      ↓
Estimate useful actions
      ↓
Make better future decisions

rather than:

Train once
      ↓
Know the future

The quality of the learning system therefore depends heavily on the quality of the feedback and reward design.

The Hardest Part: Reward Design

This is where the idea becomes significantly harder than simply integrating an API.

If I tell a system:

"Maximize reward."

I've still left a huge question unanswered:

What exactly is a good outcome?

Suppose the system generates an answer.

Should we reward:

Accuracy?
User satisfaction?
Speed?
Low token usage?
Low cost?
Completeness?
Safety?
Conciseness?

Usually, the answer is:

Some combination of all of them.

For example, we might conceptually define:

Reward =
    Accuracy
    + User Satisfaction
    + Task Success
    - Token Cost
    - Latency

Obviously, a real system would require much more careful normalization, weighting, and evaluation.

But this illustrates the fundamental challenge.

If you optimize only for token usage, the system may become too aggressive about avoiding computation.

If you optimize only for answer quality, it might use expensive models and enormous contexts for everything.

The real challenge is finding the right balance.

Efficiency Shouldn't Destroy Quality

This is an important constraint in my own thinking.

I don't want a system that is cheap but produces mediocre results.

The goal is not:

"Use fewer tokens at any cost."

The goal is:

"Spend computation where it actually improves the outcome."

For an easy request:

Small model
+
Minimal context
+
Direct answer

For a complex request:

Retrieval
+
More context
+
Tool usage
+
Stronger model
+
Deeper reasoning

The system should ideally learn the difference.

That's much more interesting than forcing every request through the same pipeline.

Adaptive Model Routing

This idea can also extend to model selection.

Imagine having:

Small / inexpensive model
Medium model
Large / expensive model
Specialized model

A traditional implementation might always use the largest model.

That works, but it is expensive.

Another implementation might always use the cheapest model.

That saves money but can hurt quality.

An adaptive system could potentially learn:

Simple task
→ Small model

Moderate task
→ Medium model

Complex task
→ Large model

Specialized task
→ Specialized model

The decision isn't necessarily based on a manually written rule.

The policy can learn from outcomes.

Again, the goal isn't to eliminate expensive models.

It's to use them when they are actually worth the cost.

This Changes the Definition of an "AI Application"

This is probably the biggest conceptual shift for me.

I used to think about AI applications primarily as:

Application
+
LLM
+
Prompt
+
Tools

Now I increasingly think about them as:

Application
+
Models
+
Tools
+
Memory
+
State
+
Decision Policy
+
Feedback
+
Evaluation
+
Learning

The model is still extremely important.

But it becomes one part of the overall intelligence.

The system itself becomes responsible for deciding how that intelligence should be used.

What Makes This Difficult?

There are several problems that make this significantly harder than building a simple LLM application.

1. Reward Design

Bad rewards produce bad behaviour.

If the system is rewarded for minimizing tokens, it might sacrifice quality.

If it is rewarded only for user satisfaction, it may overuse expensive computation.

The objective needs to reflect the actual goal.

2. Feedback Quality

Not every user interaction provides useful feedback.

A user leaving the application doesn't necessarily mean the answer was bad.

A user saying "thanks" doesn't necessarily mean the answer was perfect.

Feedback needs to be interpreted carefully.

3. Exploration vs Exploitation

A learning system needs to balance:

Exploitation: use strategies that already work.

Exploration: try new strategies that might work better.

Too much exploitation can make the system stuck in a mediocre strategy.

Too much exploration can make it unpredictable.

4. Evaluation

You cannot simply say:

"The model seems better."

You need measurable evaluation.

For example:

Task Success Rate
Answer Quality
Token Usage
Latency
Cost per Successful Task
Tool Accuracy
Retrieval Precision
Failure Rate

The system needs to improve according to metrics that actually matter.

5. Safety and Constraints

Learning systems should not be allowed to optimize without boundaries.

There should be constraints around:

Safety
Privacy
Tool access
Cost
Data usage
Allowed actions
Reliability

Learning doesn't eliminate engineering rules.

It changes where some of the decision-making happens.

I Don't Think Bigger Models Are the Only Answer

The AI industry has understandably focused heavily on model scale.

Larger models.

More parameters.

Larger context windows.

More compute.

Better reasoning.

And these improvements are incredibly important.

But there is another dimension to intelligence:

How effectively do we use the intelligence we already have?

Imagine two systems.

System A:

Huge model
+
Huge context
+
Every tool
+
Maximum computation

System B:

Appropriate model
+
Relevant context
+
Relevant tools
+
Adaptive computation
+
Feedback

System B may not have more raw intelligence.

But it may be a better system.

That's the direction I find interesting.

The Future: Bigger Models or Smarter Systems?

I don't think the answer has to be one or the other.

We'll probably continue building increasingly capable foundation models.

But I believe the systems built around those models will become just as important.

The next generation of AI applications may not simply ask:

"Which LLM should I use?"

They may ask:

"What is the best way to solve this particular problem?"

And the answer could involve:

Retrieve?
Reason?
Use a tool?
Ask the user?
Use a small model?
Use a large model?
Use more context?
Use less context?
Try again?
Stop?

That decision itself can become a learning problem.

My Current Perspective

I'm not trying to build another application that simply puts an LLM behind a nice UI.

I'm interested in building a system where the LLM is one component of a larger architecture.

A system that can:

Observe → Decide → Act → Evaluate → Learn → Improve

And importantly, the objective isn't simply to make AI more powerful.

It's to make it:

More adaptive.

More efficient.

More robust.

More accessible.

If an AI system can learn that it doesn't need 20,000 tokens to solve a problem that requires only 2,000, that's not just a cost optimization.

That's better engineering.

If it can learn when a tool is actually useful instead of calling it every time, that's better decision-making.

If it can learn when a stronger model is worth the additional cost, that's adaptive intelligence.

And if it can improve these decisions based on real outcomes rather than requiring us to manually encode every possible scenario, then we're moving beyond simply wrapping an AI model.

We're building a system that learns how to use intelligence.

Final Thought

Maybe the future of AI isn't only about building bigger models.

Maybe it is also about building systems that know when, where, and how to use those models.

The model provides capability.

The architecture provides control.

The feedback provides learning.

And the policy determines how the system evolves.

Not just AI that generates.

AI that learns how to make better decisions.

Real-Time Notifications in a MERN App — explained like texting your nerd bestie

Vaibhav Singh — Fri, 15 Aug 2025 21:07:05 +0000

You want that sweet little bell to light up the moment payments, bookings, or admin broadcasts happen — and you want the list to still be there after refresh. This guide takes you from nothing to a working MERN stack with:

Socket.IO for instant in‑app updates
MongoDB for persistence (history + unread)
REST endpoints to fetch + mark read
React hook + UI to display the dropdown

Let’s ship. 🚀

🧭 What we’re building

Two lanes make notifications feel “right”:

Realtime lane → server emits Socket.IO events to the right users/roles.
Persistence lane → server stores notifications in Mongo so they survive refresh/offline.

The client:

fetches last 50 notifications on mount,
listens for socket events and prepends new ones,
marks an item as read when clicked.

Result: real-time + durable notifications.

📦 Prereqs

Node 18+
npm or pnpm
A MongoDB connection (local or Atlas).

I’ll assume mongodb://localhost:27017/mern_notify locally.

🗂️ Project layout

We’ll create two folders:

mern-realtime-notify/
  server/
  client/

🛠️ Server (Express + Socket.IO + Mongo)

1) Init + install

mkdir -p mern-realtime-notify/server && cd mern-realtime-notify/server
npm init -y
npm i express cors dotenv mongoose socket.io jsonwebtoken bcrypt
npm i -D nodemon

Add scripts to package.json:

{
  "name": "server",
  "type": "module",
  "scripts": {
    "dev": "nodemon server.js"
  }
}

Create .env:

PORT=5000
MONGO_URI=mongodb://localhost:27017/mern_notify
JWT_SECRET=dev_super_secret_change_me
CORS_ORIGINS=http://localhost:5173

2) Basic server with Socket.IO auth

server.js

import express from 'express'
import cors from 'cors'
import dotenv from 'dotenv'
import mongoose from 'mongoose'
import { createServer } from 'http'
import { Server } from 'socket.io'
import jwt from 'jsonwebtoken'

dotenv.config()

const app = express()
const server = createServer(app)

const allowed = (process.env.CORS_ORIGINS || '').split(',').filter(Boolean)
const io = new Server(server, {
  cors: {
    origin: allowed.length ? allowed : '*',
    credentials: true,
  },
  transports: ['websocket', 'polling'],
})

app.use(cors({ origin: allowed.length ? allowed : '*', credentials: true }))
app.use(express.json())

// connect mongo
await mongoose.connect(process.env.MONGO_URI)
console.log('Mongo connected')

// ===== MODELS =====
import Notification from './src/models/Notification.js'
import User from './src/models/User.js'

// ===== ROUTES =====
import authRouter from './src/routes/auth.js'
import notifRouter from './src/routes/notifications.js'

// expose io to routes
app.use((req, _res, next) => { req.io = io; next() })

app.use('/api/auth', authRouter)
app.use('/api/notifications', notifRouter)

app.get('/api/health', (_req, res) => res.json({ ok: true }))

// ===== SOCKET AUTH =====
io.use(async (socket, next) => {
  try {
    const token = socket.handshake.auth?.token
    if (!token) return next(new Error('Missing token'))
    const decoded = jwt.verify(token, process.env.JWT_SECRET)
    const user = await User.findById(decoded.userId).select('-password')
    if (!user) return next(new Error('User not found'))
    socket.user = user
    next()
  } catch (e) {
    next(new Error('Auth failed: ' + e.message))
  }
})

io.on('connection', (socket) => {
  const user = socket.user
  const userRoom = `user_${user._id}`
  const roleRoom = `role_${user.role}`
  socket.join(userRoom)
  socket.join(roleRoom)
  console.log(`Socket connected: ${user.email} -> rooms: ${userRoom}, ${roleRoom}`)

  socket.on('disconnect', (reason) => {
    console.log('Socket disconnected', reason)
  })
})

const PORT = process.env.PORT || 5000
server.listen(PORT, () => console.log(`Server listening on ${PORT}`))

3) Models

src/models/User.js (super minimal; don’t use in prod without tweaks)

import mongoose from 'mongoose'
import bcrypt from 'bcrypt'

const userSchema = new mongoose.Schema({
  email: { type: String, unique: true },
  password: String,
  role: { type: String, default: 'patient' } // 'patient' | 'doctor' | 'admin'
})

userSchema.pre('save', async function(next) {
  if (!this.isModified('password')) return next()
  this.password = await bcrypt.hash(this.password, 10)
  next()
})

userSchema.methods.compare = function(pw) { return bcrypt.compare(pw, this.password) }

export default mongoose.model('User', userSchema)

src/models/Notification.js

import mongoose from 'mongoose'

const notificationSchema = new mongoose.Schema(
  {
    userId: { type: mongoose.Schema.Types.ObjectId, index: true },
    type: { type: String, required: true }, // e.g., 'payment_success'
    title: String,
    message: String,
    meta: Object,
    readAt: Date,
  },
  { timestamps: { createdAt: true, updatedAt: true } }
)

export default mongoose.model('Notification', notificationSchema)

4) Auth routes (login/register + JWT)

src/routes/auth.js

import express from 'express'
import jwt from 'jsonwebtoken'
import User from '../models/User.js'

const router = express.Router()

router.post('/register', async (req, res) => {
  const { email, password, role = 'patient' } = req.body
  const exists = await User.findOne({ email })
  if (exists) return res.status(400).json({ success: false, message: 'Email in use' })
  const user = await User.create({ email, password, role })
  res.json({ success: true, user: { id: user._id, email: user.email, role: user.role } })
})

router.post('/login', async (req, res) => {
  const { email, password } = req.body
  const user = await User.findOne({ email })
  if (!user || !(await user.compare(password))) {
    return res.status(401).json({ success: false, message: 'Invalid credentials' })
  }
  const token = jwt.sign({ userId: user._id }, process.env.JWT_SECRET, { expiresIn: '7d' })
  res.json({ success: true, token, user: { id: user._id, email: user.email, role: user.role } })
})

export default router

5) Notifications routes (fetch + markRead + test)

src/routes/notifications.js

import express from 'express'
import jwt from 'jsonwebtoken'
import Notification from '../models/Notification.js'

const router = express.Router()

// simple auth middleware reading Bearer token
function authenticate(req, res, next) {
  try {
    const h = req.headers.authorization || ''
    const token = h.startsWith('Bearer ') ? h.slice(7) : null
    if (!token) return res.status(401).json({ success: false, message: 'No token' })
    const decoded = jwt.verify(token, process.env.JWT_SECRET)
    req.user = { _id: decoded.userId }
    next()
  } catch (e) {
    res.status(401).json({ success: false, message: 'Invalid token' })
  }
}

// GET: latest 50
router.get('/', authenticate, async (req, res) => {
  const list = await Notification.find({ userId: req.user._id }).sort({ createdAt: -1 }).limit(50).lean()
  res.json({ success: true, notifications: list })
})

// POST: mark read
router.post('/read', authenticate, async (req, res) => {
  const { id } = req.body
  await Notification.updateOne({ _id: id, userId: req.user._id }, { $set: { readAt: new Date() } })
  res.json({ success: true })
})

// POST: test -> store + emit
router.post('/test', authenticate, async (req, res) => {
  const { message = 'This is a test', type = 'info', title = 'Test notification' } = req.body
  const doc = await Notification.create({ userId: req.user._id, type, title, message })
  req.io.to(`user_${req.user._id}`).emit('notification', {
    _id: doc._id, type, title, message, createdAt: doc.createdAt, readAt: null
  })
  res.json({ success: true })
})

export default router

Start the server:

npm run dev

🎨 Client (React + Vite)

1) Init + install

cd ../
npm create vite@latest client -- --template react
cd client
npm i socket.io-client axios react-hot-toast

Add .env (Vite expects VITE_ prefix):

VITE_API_URL=http://localhost:5000/api
VITE_SOCKET_URL=http://localhost:5000

2) Minimal API helper

src/lib/api.js

import axios from 'axios'
const api = axios.create({ baseURL: import.meta.env.VITE_API_URL })
export function setAuth(token) {
  api.defaults.headers.common['Authorization'] = token ? `Bearer ${token}` : undefined
}
export default api

3) Auth context (store token + user)

src/contexts/AuthContext.jsx

import { createContext, useContext, useState } from 'react'
import api, { setAuth } from '../lib/api'

const AuthCtx = createContext(null)
export const useAuth = () => useContext(AuthCtx)

export default function AuthProvider({ children }) {
  const [user, setUser] = useState(null)
  const [token, setToken] = useState(null)

  const login = async (email, password) => {
    const res = await api.post('/auth/login', { email, password })
    if (res.data.success) {
      setToken(res.data.token)
      setAuth(res.data.token)
      setUser(res.data.user)
    }
    return res.data
  }

  const register = async (email, password, role='patient') => {
    const res = await api.post('/auth/register', { email, password, role })
    return res.data
  }

  const logout = () => {
    setToken(null); setUser(null); setAuth(null)
  }

  return (
    <AuthCtx.Provider value={{ user, token, login, register, logout }}>
      {children}
    </AuthCtx.Provider>
  )
}

4) Socket context (auth handshake)

src/contexts/SocketContext.jsx

import { createContext, useContext, useEffect, useRef, useState } from 'react'
import { io } from 'socket.io-client'
import { useAuth } from './AuthContext'

const SocketCtx = createContext(null)
export const useSocket = () => useContext(SocketCtx)

export default function SocketProvider({ children }) {
  const { token } = useAuth()
  const [isConnected, setIsConnected] = useState(false)
  const socketRef = useRef(null)

  useEffect(() => {
    if (!token) return
    const socket = io(import.meta.env.VITE_SOCKET_URL, {
      auth: { token },
      transports: ['websocket', 'polling'],
    })
    socketRef.current = socket
    socket.on('connect', () => setIsConnected(true))
    socket.on('disconnect', () => setIsConnected(false))
    return () => socket.disconnect()
  }, [token])

  return (
    <SocketCtx.Provider value={{ socket: socketRef.current, isConnected }}>
      {children}
    </SocketCtx.Provider>
  )
}

5) Notifications hook (fetch + live + markRead)

src/hooks/useNotifications.js

import { useEffect, useMemo, useState } from 'react'
import api from '../lib/api'
import { useSocket } from '../contexts/SocketContext'

const EVENTS = [
  'notification', // generic catch-all we emit in /notifications/test
  // add more if your server emits: 'payment_success', 'new_appointment', etc.
]

export function useNotifications() {
  const { socket } = useSocket()
  const [items, setItems] = useState([])

  useEffect(() => {
    let dead = false
    ;(async () => {
      try {
        const res = await api.get('/notifications')
        if (!dead && res.data?.success) setItems(res.data.notifications)
      } catch {}
    })()
    return () => { dead = true }
  }, [])

  useEffect(() => {
    if (!socket) return
    const on = (type) => (p) => setItems(prev => [normalize(type, p), ...prev])
    EVENTS.forEach(evt => socket.on(evt, on(evt)))
    return () => { EVENTS.forEach(evt => socket.off(evt)) }
  }, [socket])

  const unreadCount = useMemo(() => items.filter(n => !n.readAt).length, [items])

  const markRead = async (id) => {
    setItems(prev => prev.map(n => (n._id === id ? { ...n, readAt: new Date().toISOString() } : n)))
    try { await api.post('/notifications/read', { id }) } catch {}
  }

  return { items, unreadCount, markRead }
}

function normalize(type, p) {
  return {
    _id: p._id || (Math.random().toString(36).slice(2) + Date.now().toString(36)),
    type,
    title: p.title || 'Notification',
    message: p.message || '',
    createdAt: p.createdAt || p.timestamp || new Date().toISOString(),
    readAt: p.readAt || null,
    ...p,
  }
}

6) Tiny UI (login + bell)

src/App.jsx

import { useState } from 'react'
import AuthProvider, { useAuth } from './contexts/AuthContext'
import SocketProvider from './contexts/SocketContext'
import { useNotifications } from './hooks/useNotifications'

function Login() {
  const { login, register } = useAuth()
  const [email, setEmail] = useState('demo@example.com')
  const [password, setPassword] = useState('secret')

  return (
    <div style={{ display:'flex', gap: 8, marginBottom: 16 }}>
      <input value={email} onChange={e=>setEmail(e.target.value)} placeholder="email" />
      <input value={password} onChange={e=>setPassword(e.target.value)} placeholder="password" type="password" />
      <button onClick={() => register(email, password)}>Register</button>
      <button onClick={() => login(email, password)}>Login</button>
    </div>
  )
}

function Bell() {
  const { items, unreadCount, markRead } = useNotifications()
  return (
    <div>
      <button>🔔 {unreadCount > 0 ? `(${unreadCount})` : ''}</button>
      <div style={{ border:'1px solid #ddd', padding: 8, width: 360, marginTop: 8 }}>
        {items.map(n => (
          <div key={n._id} onClick={()=>markRead(n._id)} style={{ padding: 8, borderBottom:'1px solid #eee', cursor:'pointer' }}>
            <div style={{ fontWeight:'bold' }}>{n.title}</div>
            <div style={{ fontSize: 12, opacity:.7 }}>{new Date(n.createdAt).toLocaleString()}</div>
            {n.message && <div style={{ fontSize: 13, marginTop: 4 }}>{n.message}</div>}
          </div>
        ))}
      </div>
    </div>
  )
}

export default function App() {
  return (
    <AuthProvider>
      <SocketProvider>
        <div style={{ padding: 24, fontFamily: 'sans-serif' }}>
          <h1>MERN Real-time Notifications</h1>
          <Login />
          <Bell />
        </div>
      </SocketProvider>
    </AuthProvider>
  )
}

Run the client:

npm run dev

Open http://localhost:5173/. Register, then login.

🧪 Test it (Does it ding?)

With the client logged in, hit the test endpoint from a terminal:

curl -X POST http://localhost:5000/api/notifications/test \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_JWT_HERE" \
  -d '{"message":"Hello from test!","type":"info"}'

You should see a new row appear under the bell instantly. Click it → it’s marked read. Refresh → it’s still there. ✅

🧯 Common gotchas

CORS: Allow your client origin on both Express and Socket.IO CORS.
Auth handshake: Send auth: { token } when connecting the socket (we did).
Cleanup: Always off() socket listeners on unmount (the hook does).
Reverse proxy: Enable WebSocket upgrades on Nginx/Cloudflare/etc.
Security: On mark-read, always filter by { _id, userId } (we do).

🧰 Extras (when you want more)

Role broadcasts: Server joins users to role_admin, role_doctor, role_patient. Emit to a role room.
Scheduled reminders: Add Redis + BullMQ → schedule “appointment in 1h” jobs, emit at the right time.
Web Push/FCM: For OS-level notifications when the tab is closed.
Hosted websockets: Pusher/Ably/PubNub if you don’t want to run Socket.IO infra.
Emails/SMS: SendGrid/SES and Twilio for critical backups.

🏁 Recap

Mongo stores notifications.
Socket.IO delivers them in real-time.
React hook keeps UI in sync and handles “mark read”.

This pattern is tiny, fast, and rock-solid. You can paste it into any MERN app and be “the person who made the bell work” by lunch. 🔔✨

Build an AI-Powered Dashboard Generator Using Gemini Pro Vision and Python

Vaibhav Singh — Mon, 16 Jun 2025 16:30:28 +0000

What if you could automatically generate dashboards from your database using AI—with zero manual SQL or chart-building? In this post, I’ll walk you through building an AI-powered dashboard generator using Python, Plotly Dash, and Google’s Gemini Pro Vision model.

🧠 What We're Building
An interactive web app that connects to your database, analyzes your schema and data, and generates smart, AI-driven visualizations with explanations — no manual configuration needed.

🔍 Features
🔎 Automatic Schema & Data Analysis
Gemini detects column types, relationships, and sample data.

📊 Smart Visualization Suggestions
The AI recommends charts like bar, line, scatter, pie, and histogram based on data patterns.

🧠 Aggregations Made Easy
Auto-handling of sum, avg, count, min, max, grouped intelligently.

💅 Modern UI with Plotly Dash
Responsive layout, interactive graphs, real-time updates, and a smooth user experience.

📦 Technologies Used
Python 3.8+

Dash by Plotly

Google Generative AI SDK

SQLAlchemy (for database connections)

Gemini Pro Vision (gemini-1.5-flash or gemini-1.5-pro)

🔧 Setup Instructions

Clone the Repo & Install Requirements

git clone https://github.com/yourname/ai-dashboard-generator cd ai-dashboard-generator pip install -r requirements.txt

Create a .env File Add your database credentials and Gemini API key:

For SQLite

DB_TYPE=sqlite DB_NAME=your_database.db GOOGLE_API_KEY=your_gemini_api_key

PostgreSQL/MySQL config:

DB_TYPE=postgresql DB_HOST=localhost DB_PORT=5432 DB_NAME=your_database DB_USER=your_username DB_PASSWORD=your_password GOOGLE_API_KEY=your_gemini_api_key

Run the App

python main.py

Then open your browser:
👉 http://localhost:8050

🔑 Getting a Gemini API Key (FREE)
Go to Google AI Studio

Click "Create API Key"

Copy and paste it into your .env

✅ Free Tier:
60 requests/minute, 1M characters/month, no credit card required.

📊 How It Works
Step 1: Schema Analysis
The app introspects your database using SQLAlchemy, identifying:

All tables

Column names & data types

Potential categorical/numeric/date fields

self.metadata.reflect(bind=self.engine)
self.inspector.get_columns(table_name)

Step 2: Prompt Gemini for Chart Suggestions
Gemini receives a structured prompt like:

Analyze this database table and suggest the best visualizations:
Table: users
Columns: ['id', 'age', 'signup_date']
...
It replies with JSON-like objects:

{ "type": "bar", "x": "signup_date", "y": "count", "title": "User Signups Over Time", "explanation": "Bar chart to show user signups grouped by date." }
Step 3: Visualization with Plotly
The app uses plotly.express to build each visualization dynamically:

fig = px.bar(df_grouped, x='signup_date', y='count', title='User Signups Over Time')

You get interactive zooming, panning, tooltips, and more.

🖼️ Supported Visualizations
📊 Bar Charts

📈 Line Charts

🔵 Scatter Plots

🥧 Pie Charts

📉 Histograms

Each chart includes an explanation of why it was suggested — all powered by Gemini.

🧪 Demo Use Case

Imagine a sales table like this:

date    region  revenue
2024-01-01  East    1000
2024-01-02  West    850

The AI might generate:

A line chart: revenue over time

A bar chart: total revenue by region

A pie chart: revenue share by region

All of that, with zero manual chart coding.

🧠 Why Use Gemini?
Traditional BI tools require manual chart design. Gemini understands natural data patterns and recommends visualizations that:

Highlight trends

Aggregate meaningfully

Require no human SQL

It acts like a data analyst who just knows what to show.

🔓 License
MIT – free to use, modify, and build on.

📈 Future Ideas
Export charts to PNG/PDF

Embed dashboards in other apps

Natural language question support ("Show me revenue by month")

Row-level filtering

🌐 Conclusion
With just a Gemini API key and a database, you can now build AI-powered dashboards in minutes. Whether you're building for internal analytics, client reporting, or automating BI, this setup gives you insight on autopilot.

Ready to turn your data into decisions?
Clone the repo and let Gemini do the heavy lifting.
GitHub Link - https://github.com/v0nser/ai-dashboard-generator

Introducing Route Guard: A Flexible API Validation Module for Node.js 🚀

Vaibhav Singh — Sun, 01 Dec 2024 15:25:50 +0000

In today's world of web development, APIs are the backbone of communication between services. Ensuring the validity and security of incoming requests is crucial to maintain robust and secure applications. That’s where Route Guard, a lightweight and powerful Node.js module, steps in to simplify API validation.

🌟 What is Route Guard?
Route Guard is a Node.js library designed to validate API requests effortlessly. It helps developers enforce strict validation rules for headers, body fields, data types, and required parameters. Whether you're working on a small project or scaling up, Route Guard ensures your APIs are secure and well-structured.

🔑 Key Features
Flexible Validation Rules: Easily define validation rules for headers and body fields.
Required Fields & Type Checking: Enforce the presence of required fields and validate data types.
Enumerated Values: Limit values to predefined options (e.g., roles like 'admin', 'user').
Detailed Error Reporting: Get precise error messages when validation fails, helping with debugging and user feedback.

🚀 Installation
Getting started with Route Guard is simple:

npm install routeguard

📚 How to Use Route Guard

Define Your Validation Rules Create a validationRules.js file and specify the rules for each API route:

module.exports = { '/api/users': { headers: { 'api-key': { required: true, type: 'string' }, // API key validation }, body: { username: { required: true, type: 'string' }, // Ensure username is a string email: { required: true, type: 'string' }, // Email validation role: { required: true, type: 'string', enum: ['user', 'admin'] }, // Role validation }, }, };

Integrate Route Guard in Your Application Use the RouteValidator class to validate incoming requests:

`const RouteValidator = require('routeguard');
const rules = require('./validationRules');

const validator = new RouteValidator(rules);

// Sample Express route
app.post('/api/users', (req, res) => {
const result = validator.validate('/api/users', req);

if (result.isValid) {
res.status(200).send({ message: 'User created successfully!' });
} else {
res.status(400).send({ errors: result.errors });
}
});`

🌐 Example API Requests

✅ Valid Request:
curl -X POST http://localhost:3000/api/users \ -H "Content-Type: application/json" \ -H "api-key: valid-api-key" \ -d '{"username": "john_doe", "email": "john@example.com", "role": "admin"}'

❌ Invalid Request (Missing API Key):
curl -X POST http://localhost:3000/api/users \ -H "Content-Type: application/json" \ -d '{"username": "john_doe", "email": "john@example.com", "role": "admin"}'

📋 Error Response:
{ "errors": [ { "field": "headers.api-key", "message": "api-key is required in headers." } ] }

🔬 Testing with Jest
Route Guard supports easy testing using Jest. Run the test suite with:

npm test

Sample Output:

PASS tests/routeguard.test.js ✓ should reject missing required header (20 ms) ✓ should reject invalid role values (15 ms) ✓ should accept valid request (10 ms)

🤝 Contribute to Open Source
We welcome contributions! If you’d like to improve Route Guard or suggest new features, feel free to:

Star the repo:
GitHub: https://github.com/v0nser/routeguard
Submit an issue or pull request: Contributions are welcome!

📜 Conclusion
Route Guard is a simple yet powerful tool that adds an extra layer of security to your APIs. By validating headers and body fields with customizable rules, you can ensure that your API endpoints are robust, secure, and reliable.

Start building more secure APIs today with Route Guard!

Links:

NPM: https://www.npmjs.com/package/routeguard
GitHub: https://github.com/v0nser/routeguard

What are your thoughts? Let us know how Route Guard has helped you build better APIs in the comments below!

Peer-to-peer (P2P) protocol

Vaibhav Singh — Mon, 22 Jul 2024 08:53:08 +0000

All of you might have heard of BitTorrent. I think this is the best example to explain the peer-to-peer network protocol.

BitTorrent is a Peer-to-Peer (P2P) protocol designed for distributing large amounts of data over the internet. Traditional downloads often rely on a single server, which can fail or corrupt files. BitTorrent, however, simplifies this issue through its decentralized approach, enhancing both speed and reliability.

In a BitTorrent network, users (peers) share pieces of files, known as packets, with each other instead of depending on a central server. This decentralization allows for different parts of a file to be downloaded from multiple sources simultaneously, making the process faster and more efficient.

To download a file using BitTorrent, a user first obtains a small file called a torrent file. This torrent file contains information about the desired file and the trackers that coordinate the file distribution. Once the torrent file is opened in a BitTorrent client, the user connects to the network to begin downloading and uploading file pieces.

The more users participating, the faster the download becomes, as each user contributes to the file's distribution. This collaborative sharing of resources is a key feature of P2P protocols like BitTorrent, making them efficient for distributing large files to a wide audience.

Dividing equal columns in the webpage.

Vaibhav Singh — Mon, 22 Jan 2024 13:31:51 +0000

Designing a webpage or document with a clean and organized layout is essential for a positive user experience. One effective way to achieve this is by utilizing three columns to structure your content. In this article, we will explore how to create three columns and center the contents within them, providing a visually appealing and balanced presentation.

HTML Structure

To begin, let's set up the basic HTML structure for our three columns. We'll use the HTML5 semantic tags for better clarity and structure. Here's a simple example:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Three Columns Layout</title>
    <link rel="stylesheet" href="styles.css"> <!-- Link to your external stylesheet -->
</head>
<body>
    <div class="container">
        <div class="column"> 
            Col1
        </div>
        <div class="column">
            Col2
        </div>
        <div class="column">
            Col3
        </div>
    </div>
</body>
</html>

Now, let's style our columns and center the contents within them using CSS. Create an external stylesheet (styles.css) and link it in the HTML file:

css

body {
    margin: 0;
    font-family: 'Arial', sans-serif;
}

.container {
    display: flex;
    justify-content: space-between;
    padding: 20px;
}

.column {
    flex: 1;
    text-align: center;
}

Explanation:

-> The display: flex; property on the container turns it into a flex container.
-> justify-content: space-between; ensures that the columns are evenly distributed with space between them.
-> The flex: 1; property on each column allows them to take equal space within the container.
-> text-align: center; centers the content inside each column.

Conclusion:
Creating a three-column layout and centering the contents is a fundamental skill in web design. By following this simple guide, you can achieve a clean and balanced design for your web pages or documents, enhancing the overall user experience. Remember to customize the styling to match your specific design preferences and project requirements.

Here the sample for it
https://codepen.io/vonser/pen/PoLjgXe