DEV Community: Manas Shinde

Building a real-time chat application is a deceptively challenging engineering task. It combines the complexities of persistent socket networking, heavy client-side cryptography, concurrent asset downloads, and frequent UI re-renders. Without careful engineering, your chat app will quickly become sluggish, drain users’ battery, and overwhelm your database — and once performance debt piles up, it’s incredibly expensive to refactor.

In this post, we’ll walk through four critical optimization techniques we implemented in our production codebase to solve exactly these issues. For each technique, we’ll break down:

The Problem we faced (the real pain, not the sanitised version).
Our Solution (with actual architecture patterns and code snippets).
The Ideal Industry Approach — and where we deliberately chose a simpler path.
An Honest Rating & Assessment — where it shines, where it creaks.

We’ve also highlighted exactly where and what kinds of illustrations or screenshots you should insert to make this post highly visual and engaging.

🚀 Optimization 1: Client-Side LRU Memory Cache for E2EE Media

1. The Problem

In an End-to-End Encrypted (E2EE) chat app, files are stored on the server as opaque encrypted blobs. Every time a user scrolls through their chat, opens the file attachment modal, or switches conversations, the client must download those encrypted bytes and then run CPU-heavy cryptographic decryption in JavaScript (often via WebAssembly or the browser’s SubtleCrypto API).

Doing this repeatedly causes severe UI stuttering during scroll, high CPU temperatures on mobile, and massive wasted network data. Users see spinners for assets they literally just decrypted a few seconds earlier.

2. Our Solution

We built a centralized, in-memory Least Recently Used (LRU) Cache Manager in JavaScript.

The Cache Mechanism: We created a class (mediaCache.js) that maps a compound cache key (file ID + hash) to decrypted data: { fileData, objectUrl, size, timestamp }. The decrypted ArrayBuffer is stored alongside a blob URL created via URL.createObjectURL() so the UI can render instantly. The URL is revoked when the entry is evicted, preventing memory leaks.
LRU Eviction: To stop the tab from crashing under memory pressure, we enforce two limits: a maximum of 100 entries and a total byte size cap of 250 MB. When either limit is exceeded, the least recently accessed entry is evicted. This double limit prevents a single large video from displacing dozens of useful small images.
Global Access: Every file component (FileList, AllFilesModal, etc.) checks this cache before making any API call. On a cache hit, the asset loads in under 1 millisecond — zero network, zero decryption, zero CPU spikes.

3. The Ideal Way

In non-encrypted apps, you’d simply set Cache-Control: immutable on the server and let the browser’s HTTP cache do the work. With E2EE, that doesn’t work because the bytes fetched from the server are useless until decrypted.

The true industry standard is to persist decrypted files inside IndexedDB, combined with a Service Worker that intercepts fetch requests and serves the cached content transparently. This survives page refreshes and allows offline access. However, it also means decrypted material stays on disk longer, raising security concerns that demand careful key rotation and automatic expiration logic.

4. Honest Rating: ⭐️ 8/10 (Highly Professional)

What’s great: In-memory LRU is extremely fast, simple to debug, and automatically purges when the tab closes — drastically limiting the window in which decrypted data could be scraped from memory. The dual eviction strategy (count + total size) prevents both memory fragmentation and out-of-memory crashes, something many teams overlook.

The uncomfortable truth: Our eviction logic scans the entire cache to find the oldest entry ([...cache.entries()].sort(...)), which is O(n) but perfectly fine for 100 items. A proper doubly-linked list + hashmap LRU would be O(1), but that’s overkill for this scale. More importantly, we didn’t build the IndexedDB + Service Worker layer. The real reason? Time constraints. That’s honest technical debt that we’ve chosen to carry because in-memory caching alone solved 90% of the jank.

🔄 Optimization 2: Active Request and Event Deduplication

1. The Problem

Chat interfaces often render the same file in multiple places at once — for example, in the main message list and a sidebar “recent files” widget. Both React components mount simultaneously, see the same file ID, and fire independent HTTP requests for the same encrypted blob.

This creates a request storm: multiple identical downloads and decryptions competing for network and CPU. On the socket side, reconnection storms are another beast. After a brief disconnect, the server might re-emit previously delivered messages because the client didn’t acknowledge them in time. Without deduplication, the UI flashes duplicate messages and triggers useless Redux store updates.

2. Our Solution

We solved both problems with an in-flight request registry and a bounded processed-ID Set.

Network Request Deduplication (FileList.js)
We maintain a global Map of active download promises. Any component that needs a file first checks this map. If another component has already kicked off the download, we return the same promise. Only one network request and one decryption run ever happens concurrently.

const activeRequests = new Map();

async function fetchAndDecryptFile(cacheKey) {
  if (activeRequests.has(cacheKey)) {
    return activeRequests.get(cacheKey);
  }

  const promise = (async () => {
    try {
      const encryptedBlob = await api.downloadFile(cacheKey);
      const decrypted = await cryptoWorker.decrypt(encryptedBlob);
      mediaCache.set(cacheKey, decrypted);
      return decrypted;
    } finally {
      // Clean up so future retries aren't blocked
      activeRequests.delete(cacheKey);
    }
  })();

  activeRequests.set(cacheKey, promise);
  return promise;
}

The finally block is critical: if the download fails, the map entry is removed so a subsequent retry can fire a fresh request.

Socket Message Deduplication (onetooneSocket.js)
We keep a Set of recently processed message IDs. Any incoming packet with an ID already in the Set is silently discarded before it ever touches Redux or React.

const processedIds = new Set();
const MAX_PROCESSED_IDS = 1000;

socket.on('message', (msg) => {
  if (processedIds.has(msg.id)) return;

  processedIds.add(msg.id);

  // Prune the set to keep memory flat
  if (processedIds.size > MAX_PROCESSED_IDS) {
    const it = processedIds.values();
    for (let i = 0; i < Math.floor(MAX_PROCESSED_IDS / 2); i++) {
      processedIds.delete(it.next().value);
    }
  }

  // Dispatch to store, update UI...
});

Capping at 1,000 IDs and occasionally pruning half the Set keeps the memory footprint negligible even during multi-hour sessions.

3. The Ideal Way

Request deduplication is exactly what libraries like React Query (TanStack Query) and SWR provide out of the box — with automatic garbage collection, stale-while-revalidate, and retry logic. We didn’t use them because we needed full control over the decryption pipeline at the time, but they’re the standard today.

For socket deduplication, the robust approach is to store every message in a local database (IndexedDB) with a UNIQUE constraint on message_id. The database becomes the ultimate deduplication authority, and you don’t need an in-memory set at all. Combined with server-side sequence numbers, this is bulletproof.

4. Honest Rating: ⭐️ 9/10 (Excellent)

What’s great: The promise-sharing pattern is a sophisticated, low-overhead JavaScript idiom that eliminates duplicate network traffic without any external dependency. The bounded Set with batch pruning is clever and prevents the “death by a thousand small allocations” problem that plagues long-lived SPAs.

The uncomfortable truth: The socket deduplication relies entirely on msg.id being globally unique. If two truly different messages somehow collided in ID (extremely unlikely with UUIDv4, but possible), one would be silently dropped. Also, the hand-rolled promise registry lacks the sophisticated cache invalidation and revalidation strategies that React Query gives you for free — so our offline behaviour is still rudimentary.

🎨 Optimization 3: Lazy Component Rendering & Strict Memoization

1. The Problem

React chat lists can become brutal rendering bottlenecks. Every keystroke in the message input updates parent state, which by default triggers a re-render of the entire message list, file panels, and sidebars.

With hundreds of messages containing images, PDFs, and interactive elements, this results in noticeable typing lag, dropped frames when new messages arrive, and serious battery drain on mobile devices. Worse, many components render in a “minimized” state (a collapsed sidebar, for instance) yet still fully initialize heavy sub-components like PDF.js workers — work the user can’t even see.

2. Our Solution

We applied a multi-layered strategy: strict prop-level memoization, deferred heavy rendering, and computational memoization.

Custom Memoization (FileList.js)
We wrapped the file component in React.memo with a custom equality comparator that checks only the props that actually affect its output:

const areEqual = (prevProps, nextProps) => {
  return (
    prevProps.fileName === nextProps.fileName &&
    prevProps.fileSize === nextProps.fileSize &&
    prevProps.isMinimized === nextProps.isMinimized &&
    prevProps.thumbnailSignature === nextProps.thumbnailSignature
  );
};

export default React.memo(FileList, areEqual);

This prevents React from even entering the component’s render function during typing or unrelated state changes.

Deferred Heavy Rendering (isMinimized)
Inside FileList, we check if the component is minimized. If so, we skip the entire download/decryption/preview pipeline and render only a lightweight SVG extension icon. The heavy lifting is deferred until the user actually expands the view — and by then, the cache from Optimization 1 usually has the data ready.

Computational Memoization
In list modals, expensive search and sort operations are wrapped in useMemo, with their dependencies set to only the search query and sort order. This ensures we don’t re-sort hundreds of files because a completely unrelated keystroke triggered a re-render.

3. The Ideal Way

For moderate list sizes, memoization works well. But for truly massive chat histories (thousands of messages), the real gold standard is list virtualization using libraries like react-virtuoso or react-window. Virtualization only renders the 10–20 items currently visible in the viewport, recycling DOM nodes as the user scrolls. This keeps the React tree tiny regardless of list length.

4. Honest Rating: ⭐️ 7/10 (Solid but Brittle)

What’s great: The isMinimized pattern is a huge win — it’s a classic “don’t do work you don’t need” optimization that pays immediate dividends. The custom areEqual comparator is surgical and demonstrably reduces render counts.

The uncomfortable truth: Custom areEqual functions are a maintenance trap. If a new developer adds a prop that affects rendering but forgets to update the comparator, you get subtle staleness bugs that are hard to debug. A safer pattern is to pass only primitive props (so shallow comparison works) and push expensive derivations into selectors. We also still haven’t virtualized the main chat list. For sessions with 2,000+ messages, our DOM node count is objectively too high, and we’re leaning on browser layout optimizations to bail us out. That’s not ideal.

⚡ Optimization 4: Throttled Socket Synchronization & Multi-Device Broadcasting

1. The Problem

When a user reconnects after a dropout (elevator, tunnel, switching networks), the client needs to catch up on missed messages. The naive approach requests all messages since the last known one, and the server pumps them down the socket as fast as possible.

This is a disaster: the Node.js event loop gets blocked serializing and sending hundreds of messages in a tight loop, the TCP socket buffer floods, the database gets slammed with large catch-up queries, and other users on the same server instance experience latency spikes. If the user has multiple tabs or devices open, each one might create its own socket and sync independently, multiplying the chaos.

2. Our Solution

We built a throttled, multi-socket-aware sync architecture.

Multi-Socket Mapping (onetoone.js)
On the server, each user is mapped to a Set of socket IDs, not a single one. When a message needs to be delivered, we emit to all sockets for that user, skipping the originating socket to prevent echo. This gives us seamless multi-tab support without multiple independent sessions.

Timestamp-Based Catchup
The client stores the server-generated timestamp of the last successfully processed message. On reconnection, it sends this timestamp in the handshake. The server then queries only for messages with created_at > lastSyncTimestamp, not the entire history.

Non-Blocking Throttled Sync (group_chat.js)
The real key: we spin off the catch-up in an async IIFE that processes messages in batches, explicitly yielding the event loop every 10 messages:

const syncMissedMessages = async (socket, messages) => {
  for (let i = 0; i < messages.length; i++) {
    socket.emit('message', messages[i]);

    if ((i + 1) % 10 === 0) {
      await new Promise(resolve => setTimeout(resolve, 5));
    }
  }
};

That 5ms pause is tiny, but it’s enough for Node.js to handle other incoming events — other users’ chat messages, typing indicators, presence updates. This simple cooperative multitasking keeps the entire server responsive.

3. The Ideal Way

Our approach is remarkably close to production best practices. Two refinements big-tech stacks often add:

Sequence-based syncing: Instead of timestamps (which can suffer from clock skew), each chat channel maintains a monotonically increasing sequence number. The client remembers the last sequence it processed, making catch-up deterministic.
Redis pub/sub adapter: In a multi-server deployment, a Redis backplane ensures messages emitted on one Node instance reach sockets on another, with cross-instance deduplication. We run a single server instance, so this hasn’t been necessary yet.

4. Honest Rating: ⭐️ 8.5/10 (Very Solid Production Engineering)

What’s great: The setTimeout(resolve, 5) trick is a pragmatic, battle-tested way to prevent event-loop starvation without complex worker-thread architectures. The multi-socket mapping elegantly solves the multi-tab problem, and timestamp-based syncing is simple and effective when server clocks are kept in sync (e.g., via NTP).

The uncomfortable truth: Yielding every 10 messages with a fixed 5ms delay is a heuristic. Under heavy load, those pauses add up (1,000 missed messages = ~500ms of total delay). A more adaptive approach would be to use setImmediate() or process.nextTick() between each message, yielding as soon as the microtask queue is empty. Also, the batch size (10) and pause duration (5ms) were chosen by feel, not rigorous load testing. In a true enterprise environment, these numbers would be backed by profiling. The lack of sequence-based IDs means we’re one server-clock jump away from missing or duplicating messages during catchup — a risk we’ve mitigated with NTP but haven’t eliminated.

📝 Key Takeaways for Your Development Cycle

To summarize, here are the core rules you can apply to your own development cycle:

Optimization Area	The Core Rule	Dev Cycle Benefit
Media Assets	Never download or decrypt twice. Build local caching with size + count limits.	Reduces API costs and client CPU load dramatically.
Network Requests	Deduplicate in-flight requests at the promise level.	Eliminates redundant database/network traffic and stops request storms.
React UI Rendering	Memoize aggressively and skip rendering for minimized/offscreen elements.	Keeps input responsive and frame rate stable.
WebSockets	Always sync from an offset and yield the event loop during bulk sends.	Prevents server stalls and UI lock-ups during reconnection.

The uncomfortable meta-lesson: Most of these optimizations aren’t clever algorithms — they’re just disciplined resource management. We didn’t invent new computer science; we simply refused to waste CPU, network, or memory. The real challenge is cultural: prioritizing this work before it becomes a user complaint. By designing these layers early, you prevent performance debt that becomes brutally expensive to refactor later.

Chat-app with video-call tutorial [MERN]

Manas Shinde — Sun, 16 Feb 2025 04:41:58 +0000

Live project link: Chat-app

Building a Real-Time Chat App with the MERN Stack

Creating a real-time chat application is a great way to enhance your full-stack development skills. This guide provides a quick overview of setting up a MERN-based chat app with Socket.IO for real-time messaging, Cloudinary for profile images, and JWT authentication for user security.

This is not a full tutorial—instead, it summarizes key steps. For detailed implementation, refer to the linked YouTube tutorial below.

Features

User Authentication – Secure login and registration with JWT.

Real-Time Messaging – Instant chat functionality with Socket.IO.
Responsive UI – Mobile-friendly design with Tailwind CSS.

Image Uploads – Profile images stored using Cloudinary.

Video Calling – WebRTC integration for one-on-one calls.

Tech Stack

Frontend: React.js, Tailwind CSS
Backend: Node.js, Express.js, MongoDB
Database: MongoDB with Mongoose
Real-Time Communication: Socket.IO, WebRTC (for calls)
Authentication: JSON Web Tokens (JWT) with bcrypt
Image Storage: Cloudinary

1. Setting Up the Backend

Install Dependencies

Create a new project and install required packages:

mkdir mern-chat-app && cd mern-chat-app
npm init -y
npm install express mongoose cors bcryptjs jsonwebtoken socket.io dotenv cloudinary multer

Configure Environment Variables

Create a .env file to store sensitive data:

PORT=5000
MONGO_URI=your_mongodb_connection_string
JWT_SECRET=your_jwt_secret
CLOUDINARY_CLOUD_NAME=your_cloud_name
CLOUDINARY_API_KEY=your_api_key
CLOUDINARY_API_SECRET=your_api_secret

Express Server Setup

const express = require('express');
const mongoose = require('mongoose');
const cors = require('cors');
const dotenv = require('dotenv');
const authRoutes = require('./routes/authRoutes'); // Example route file
const chatRoutes = require('./routes/chatRoutes');
const socketIo = require('socket.io');
const http = require('http');

dotenv.config();
const app = express();
const server = http.createServer(app);
const io = socketIo(server, { cors: { origin: '*' } });

app.use(cors());
app.use(express.json());
app.use('/api/auth', authRoutes);
app.use('/api/chat', chatRoutes);

mongoose.connect(process.env.MONGO_URI, {
  useNewUrlParser: true,
  useUnifiedTopology: true,
}).then(() => console.log('MongoDB connected'));

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

2. Authentication (JWT & Mongoose Setup)

User Model (Mongoose Schema)

const mongoose = require('mongoose');
const bcrypt = require('bcryptjs');

const UserSchema = new mongoose.Schema({
  username: { type: String, required: true, unique: true },
  email: { type: String, required: true, unique: true },
  password: { type: String, required: true },
});

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

module.exports = mongoose.model('User', UserSchema);

Auth Routes

const express = require('express');
const User = require('../models/User');
const jwt = require('jsonwebtoken');
const bcrypt = require('bcryptjs');
const router = express.Router();

router.post('/register', async (req, res) => {
  const { username, email, password } = req.body;
  try {
    const user = new User({ username, email, password });
    await user.save();
    res.status(201).json({ message: 'User created successfully' });
  } catch (err) {
    res.status(400).json({ error: err.message });
  }
});

router.post('/login', async (req, res) => {
  const { email, password } = req.body;
  const user = await User.findOne({ email });
  if (!user || !(await bcrypt.compare(password, user.password))) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }
  const token = jwt.sign({ userId: user._id }, process.env.JWT_SECRET, { expiresIn: '1h' });
  res.json({ token });
});

module.exports = router;

3. Setting Up the Frontend

Install React & Dependencies

npx create-react-app client
cd client
npm install axios socket.io-client react-router-dom tailwindcss

Configure Tailwind CSS

npx tailwindcss init

Edit tailwind.config.js:

module.exports = {
  content: ['./src/**/*.{js,jsx,ts,tsx}'],
  theme: { extend: {} },
  plugins: [],
};

Import Tailwind into index.css:

@tailwind base;
@tailwind components;
@tailwind utilities;

4. Real-Time Chat with Socket.IO

Backend Socket.IO Setup

io.on('connection', (socket) => {
  console.log('New client connected');

  socket.on('sendMessage', (message) => {
    io.emit('message', message);
  });

  socket.on('disconnect', () => {
    console.log('Client disconnected');
  });
});

Frontend Socket.IO Integration

import io from 'socket.io-client';
const socket = io('http://localhost:5000');

socket.on('message', (message) => {
  console.log(message);
});

const sendMessage = (message) => {
  socket.emit('sendMessage', message);
};

5. Deployment

Once the app is ready, deploy it using:

Backend: Render, Heroku
Frontend: Vercel, Netlify

Example Heroku Deployment:

git init
git add .
git commit -m "Deploy"
heroku create your-app-name
git push heroku main

Conclusion

Building a chat app with MERN & Socket.IO is a great way to practice real-time web development. This guide summarizes the key steps, but for a detailed implementation, check out the YouTube tutorial below:

For Video calling implementation 👇

Video Call Feature

For the video call feature, I took a modular approach to keep the code organized and easy to debug—especially important for tackling WebRTC for the first time.

Process Overview

State Management with Zustand:

I created a dedicated Zustand store called useVideoStore to manage all video call-related functionalities. This store encapsulates the video call logic into simple, reusable functions. It handles tasks such as:

initializeMedia: Requests access to the user's camera and microphone using the navigator.mediaDevices.getUserMedia API.
makeCall: Initiates a video call by sending a call request through Socket.IO.
answerCall: Handles answering incoming call requests.
handleIncomingCall: Listens for and processes incoming call signals.
handleIceCandidates: Manages the exchange of ICE candidates—a critical part of establishing a peer-to-peer WebRTC connection.
endCall: Terminates the call and cleans up media streams.

Challenges & Resolutions

ICE Candidate Handling:

I initially got stuck ensuring that ICE candidates were correctly exchanged between peers. Detailed logging and verifying events in the Socket.IO signaling server revealed timing issues. Adjusting the order of operations—ensuring media streams were fully initialized before sending ICE candidates—resolved this problem.
Media Stream Initialization:

Requesting camera and microphone permissions can be tricky. I encountered browser permission issues and compatibility errors. Proper error handling with navigator.mediaDevices.getUserMedia and cross-browser testing helped overcome these challenges.
State Synchronization:

Integrating real-time events with state updates required careful management. Breaking the logic into small, dedicated functions within the Zustand store allowed me to isolate problems and ensure the app’s state accurately reflected the call status.

Example: Zustand Store for Video Calls

Below is a simplified pseudocode version of the Zustand store (useVideoStore) that encapsulates the video call functionalities:

// useVideoStore.js
import create from 'zustand';

const useVideoStore = create((set) => ({
  localStream: null,
  remoteStream: null,
  callInProgress: false,

  // Initialize media: request access to camera and microphone
  initializeMedia: async () => {
    try {
      const stream = await navigator.mediaDevices.getUserMedia({ 
        video: true, 
        audio: true 
      });
      set({ localStream: stream });
    } catch (error) {
      console.error('Error accessing media devices:', error);
    }
  },

  // Initiate a call by signaling the target user
  makeCall: (targetId) => {
    // Code to emit a call event via Socket.IO
  },

  // Answer an incoming call
  answerCall: () => {
    // Code to handle answering the call
  },

  // Manage incoming call signals
  handleIncomingCall: (callerInfo) => {
    // Code to update state with incoming call details
  },

  // Handle ICE candidate exchange for establishing a peer-to-peer connection
  handleIceCandidates: (candidate) => {
    // Code to process and send ICE candidates via Socket.IO
  },

  // End the ongoing call and clean up resources
  endCall: () => {
    // Stop local media tracks and reset state
    set({ 
      localStream: null, 
      remoteStream: null, 
      callInProgress: false 
    });
  },
}));

export default useVideoStore;

Integration in the App

In App.jsx, I imported useVideoStore and set up Socket.IO event listeners. This allowed me to tie the video call logic directly to UI components. By leveraging Zustand's simplicity, I could focus on debugging specific functions (like handleIceCandidates) without getting overwhelmed by overall state management.

Advanced Details: ICE, STUN & TURN Servers

ICE Candidate Exchange with Socket.IO:

WebRTC uses ICE (Interactive Connectivity Establishment) to discover and exchange network information (IP addresses and ports) between peers. Socket.IO serves as the signaling channel, transmitting ICE candidates between peers as they’re gathered. This exchange is essential for establishing a direct connection.

STUN Servers:

A STUN (Session Traversal Utilities for NAT) server helps a client determine its public IP address and port, which is vital when the client is behind a NAT or firewall. In my setup, I used a free public STUN server:

stun:stun.l.google.com:19302
there are more servers you can search which work fine for same N/W

This server is included in the WebRTC configuration to help peers gather their connection candidates.

TURN Servers:

TURN (Traversal Using Relays around NAT) servers relay media streams when a direct peer-to-peer connection cannot be established. This is especially necessary when both peers are behind strict NATs or firewalls.

Challenges with TURN:
- Reliability: Without a TURN server, calls might fail if a direct connection isn’t possible.
- Setup Complexity: Configuring a TURN server requires a dedicated VPS and software like Coturn (*requires VPS running).
- Costs: Running your own TURN server may incur costs, although paid services like Twilio or Xirsys are alternatives.

Due to time constraints, I didn’t set up my own TURN server. However, if you require robust connectivity, you can set up a TURN server on your own VPS. Follow this guide for instructions on installing and configuring Coturn.

Final Thoughts

Integrating ICE candidate exchange, STUN, and TURN servers is key to reliable video calling. Free STUN servers are usually sufficient, but TURN servers become critical under challenging network conditions. This modular approach using a Zustand store not only made the process more manageable but also prepared the app to handle real-world network scenarios.

Even though setting up WebRTC for video calls can be challenging, persistence and careful debugging eventually led to a seamless integration that complements the chat functionality and enhances the overall user experience.

Feel free to reach out if you have any questions or need further clarification on any of these steps!

Resources

My Socials

Thanks for reading till here please support this blog by liking🙏