DEV Community: Shubham Raj

How to Integrate Real-Time Chat in a React and Django Application (WebSockets & Channels)

Shubham Raj — Wed, 04 Nov 2026 15:45:26 +0000

How to Integrate Real-Time Chat in a React and Django Application: A Production Case Study (UrbanShift)

When building an interactive web platform, real-time messaging is no longer a luxury—it’s an expectation. In this article, I'll walk you through how I architected and implemented a high-performance, real-time chat system for UrbanShift (a relocation and property rental platform) using React on the frontend and Django on the backend.

📌 The Problem: Why Real-Time Communication Was Critical

In UrbanShift, tenants looking for rental homes and customers booking packers & movers need immediate answers. Initially, relying on standard HTTP polling or email/SMS alerts caused noticeable lag and poor user experience:

High Latency: Buyers and property owners couldn't negotiate in real-time.
Server Overload: Continuous HTTP polling repeatedly hit the database with unnecessary queries.
Disconnected UX: Users had to manually refresh the page to see if the landlord had responded.

The Feature Goal: Enable instant, bi-directional, peer-to-peer style messaging between two users with persistent chat history, typing feedback, and auto-reconnection.

While developers often search for Socket.io when coming from Node.js, the Django ecosystem provides an idiomatic and scalable counterpart: WebSockets powered by Django Channels & ASGI. Here is how the end-to-end integration works in production.

💻 Clean Code Snippets from UrbanShift

1. Backend: Async WebSocket Consumer (`consumers.py`)

Django Channels uses an AsyncWebsocketConsumer to handle WebSocket handshakes, room routing, and async broadcast across channel layers without blocking threads.

# backend/chat/consumers.py
import json
from channels.generic.websocket import AsyncWebsocketConsumer
from channels.db import database_sync_to_async
from django.contrib.auth import get_user_model
from .models import Message, ChatRoom

User = get_user_model()

class ChatConsumer(AsyncWebsocketConsumer):
    async def connect(self):
        # 1. Extract dynamic room name from URL scope
        self.room_name = self.scope['url_route']['kwargs']['room_name']
        self.room_group_name = f'chat_{self.room_name}'

        # 2. Join the room channel group
        await self.channel_layer.group_add(self.room_group_name, self.channel_name)
        await self.accept()

    async def disconnect(self, close_code):
        # Leave channel group on tab close/disconnect
        await self.channel_layer.group_discard(self.room_group_name, self.channel_name)

    async def receive(self, text_data):
        data = json.loads(text_data)
        message = data['message']
        username = data['username']

        # 3. Save message asynchronously to DB
        await self.save_message(username, self.room_name, message)

        # 4. Broadcast to everyone subscribed to this room group
        await self.channel_layer.group_send(
            self.room_group_name,
            {
                'type': 'chat_message',
                'message': message,
                'username': username
            }
        )

    async def chat_message(self, event):
        # Push message payload to client WebSocket
        await self.send(text_data=json.dumps({
            'message': event['message'],
            'username': event['username']
        }))

    @database_sync_to_async
    def save_message(self, username, room_name, content):
        user = User.objects.get(username=username)
        room, _ = ChatRoom.objects.get_or_create(name=room_name)
        return Message.objects.create(sender=user, room=room, content=content)

2. Frontend: Deterministic Room Generation & WebSocket Hook (`Chat.js`)

To ensure both User A and User B land in the exact same chat room without hardcoding IDs, we dynamically sort user IDs (e.g., 1_5).

// frontend/src/components/Chat.js
import React, { useState, useEffect, useRef } from 'react';
import useWebSocket from 'react-use-websocket';
import axios from 'axios';

const Chat = ({ currentUserId, targetUserId }) => {
    const [messageHistory, setMessageHistory] = useState([]);
    const [message, setMessage] = useState('');

    // 1. Deterministic 1-on-1 Room Name (e.g., "1_5" regardless of who initiates)
    const roomName = currentUserId < targetUserId 
        ? `${currentUserId}_${targetUserId}` 
        : `${targetUserId}_${currentUserId}`;

    const WS_URL = process.env.NODE_ENV === 'production' 
        ? `wss://urbanshift-project.onrender.com/ws/chat/${roomName}/`
        : `ws://127.0.0.1:8000/ws/chat/${roomName}/`;

    // 2. Persistent, auto-reconnecting WebSocket connection
    const { sendJsonMessage, lastJsonMessage } = useWebSocket(
        roomName ? WS_URL : null,
        { shouldReconnect: () => true }
    );

    // 3. Append incoming socket messages in real-time
    useEffect(() => {
        if (lastJsonMessage !== null) {
            setMessageHistory((prev) => [
                ...prev,
                {
                    sender_name: lastJsonMessage.username,
                    content: lastJsonMessage.message,
                    timestamp: new Date().toISOString()
                }
            ]);
        }
    }, [lastJsonMessage]);

    const handleSend = () => {
        if (!message.trim()) return;
        sendJsonMessage({ message, username: currentUser.username });
        setMessage('');
    };

    return (
        /* Chat UI Rendering */
    );
};

3. Smooth Auto-Scroll & UX Refinements

const messagesEndRef = useRef(null);

// Automatically scroll to the latest message whenever messageHistory changes
useEffect(() => {
    messagesEndRef.current?.scrollIntoView({ behavior: 'smooth' });
}, [messageHistory]);

🛠️ The Solution: Solving Key Production Challenges

Integrating real-time communications in a full-stack production setup always brings architectural hurdles. Here is how I solved them:

1. Database Thread Blocking vs Async ASGI

The Problem: Django ORM operations are inherently synchronous. Executing Message.objects.create() directly inside an asynchronous WebSocket consumer (async def receive) raises synchronous-only errors or blocks the event loop.
The Fix: Used Channels' @database_sync_to_async decorator to wrap database writes. This cleanly offloads the query to a worker thread while keeping the ASGI event loop ultra-responsive.

2. Dual Architecture (REST API for History + WebSockets for Live Events)

Fetching entire message history over WebSockets creates unnecessary parsing overhead on initial render.
The Solution: Combined a standard REST endpoint (/api/chat/history/<room>/) via axios on initial mount with instant WSS updates for newly arrived payloads.

3. Cross-Origin (CORS) & WSS Protocol Upgrades in Production

In development, ws:// works seamlessly on localhost. However, in production with Vercel (https://) and Render backend (https://), browsers strictly block unencrypted ws:// connections due to mixed-content security policies.
The Solution: Implemented environment-aware protocol switching (ws:// vs wss://) and configured CORS/CSRF trusted origins in Django settings.py for both Vercel frontend domains.

🔗 Project Links & Live Demo

Feel free to explore the project, inspect the source code, or test out the chat live!

🌐 Live Demo: UrbanShift Platform
💻 Source Code: GitHub - UrbanShift Project
👨‍💻 Author: Shubham Raj

If you found this breakdown helpful, drop a like ❤️ and bookmark 🔖 it for your next Django + React real-time project!

Building a Smart Music Search with iTunes API, Next.js, and a Flask Proxy

Shubham Raj — Wed, 04 Nov 2026 15:26:31 +0000

When building MelodyOne, a full-stack, glassmorphic music streaming web application, one of the biggest challenges wasn't styling or responsive design—it was building a fast, reliable, and decoupled audio search experience.

In this article, I'll walk you through how I architected a smart music discovery feature using the iTunes Search API, wrapped in a rate-limited Python Flask proxy, and seamlessly consumed by a Next.js 16 App Router frontend with global player state.

1. The Problem

Connecting a modern frontend directly to public media APIs (like iTunes, Spotify, or YouTube) from the browser leads straight to three major architectural roadblocks:

CORS (Cross-Origin Resource Sharing) Hell: Direct browser-to-API calls frequently trigger CORS errors or get blocked by ad blockers and strict tracking prevention.
Rate Limiting & IP Bans: If 500 active users search simultaneously from the browser, client-side IP abuse or throttling can break the user experience with zero graceful fallbacks.
Payload Bloat & Low-Res Artwork: Raw search responses return excessive metadata and tiny 100x100 thumbnails that look pixelated on modern Retina screens.

The Solution? A decoupled proxy architecture.

The frontend talks solely to our own lightweight Python Flask microservice, which handles upstream caching, data normalization (e.g., automatically bumping thumbnails from 100x100 to crisp 600x600 HD), rate limiting, and error handling.

2. The Architecture at a Glance

[ User in Browser ]
       │
       ├── Types query ("Starboy") + Hits Enter
       ▼
[ Next.js 16 (App Router on Vercel) ]
       │
       ├── GET /api/search?song=Starboy (CORS-safe)
       ▼
[ Flask Microservice (Render) + Flask-Limiter ]
       │
       ├── Fetches from iTunes API (10s Timeout)
       ├── Normalizes Artwork (100x100 ➔ 600x600)
       ├── Extracts Direct Preview Stream (.m4a)
       ▼
[ Global Player Context (HTML5 Audio) ] ──▶ Seamless Auto-Play!

3. Code Snippets: How It Works

Snippet 1: The Resilient Flask Search Proxy (`backend/run.py`)

Here is our production Flask endpoint. It enforces an IP-based rate limit of 30 requests per minute, queries the iTunes Search API with a 10-second timeout, and returns only the clean fields our UI needs:

import requests
from flask import Flask, request, jsonify
from flask_cors import CORS
from flask_limiter import Limiter
from flask_limiter.util import get_remote_address

app = Flask(__name__)
CORS(app, resources={r"/api/*": {"origins": "*"}})
limiter = Limiter(get_remote_address, app=app, default_limits=["200 per day", "50 per hour"])

@app.route('/api/search', methods=['GET'])
@limiter.limit("30 per minute")
def search_song():
    query = request.args.get('song')
    if not query:
        return jsonify({"error": "Search query is required"}), 400

    try:
        url = f"https://itunes.apple.com/search?term={requests.utils.quote(query)}&limit=1&entity=song"
        response = requests.get(url, timeout=10)
        data = response.json()

        if data.get('resultCount', 0) == 0:
            return jsonify({"error": "Track not found"}), 404

        track = data['results'][0]

        # Normalize metadata & transform thumbnail to HD 600x600
        result = {
            "videoId": str(track['trackId']),
            "title": track['trackName'],
            "artist": track['artistName'],
            "thumbnail": track.get('artworkUrl100', '').replace('100x100', '600x600'),
            "stream_url": track.get('previewUrl', '')
        }
        return jsonify(result), 200

    except requests.exceptions.Timeout:
        return jsonify({"error": "Search service timed out. Please try again."}), 504
    except Exception as e:
        return jsonify({"error": "Backend failed to fetch audio stream"}), 500

Snippet 2: Next.js Frontend Search Handler (`frontend/src/pages/Home.tsx`)

On the client side, the search bar triggers cleanly when the user hits Enter, with instant loading states and clear error feedback:

const [query, setQuery] = useState('');
const [loading, setLoading] = useState(false);
const [searchError, setSearchError] = useState<string | null>(null);
const [searchedSong, setSearchedSong] = useState<Song | null>(null);

const { playSong } = usePlayer();

const handleSearch = async (e: React.KeyboardEvent<HTMLInputElement>) => {
  if (e.key === 'Enter' && query.trim() !== '') {
    setLoading(true);
    setSearchError(null);
    setSearchedSong(null);

    try {
      const response = await fetch(
        `${process.env.NEXT_PUBLIC_API_URL}/api/search?song=${encodeURIComponent(query)}`
      );
      const data = await response.json();

      if (data.error) {
        setSearchError(data.error);
      } else {
        setSearchedSong(data);
      }
    } catch (err) {
      setSearchError("Failed to connect to streaming backend. Please check your network.");
    } finally {
      setLoading(false);
    }
  }
};

Snippet 3: Seamless Audio Queue & Playback (`PlayerContext.tsx`)

Once a track is fetched, playing it is just a single call to our global PlayerContext. It manages HTML5 Audio, tracks the queue, and automatically prevents duplicate tracks:

const playSong = useCallback((songData: Song) => {
  if (!audioRef.current) return;

  setQueue((prevQueue) => {
    const existingIndex = prevQueue.findIndex(s => s.stream_url === songData.stream_url);
    if (existingIndex !== -1) {
      setCurrentIndex(existingIndex);
      return prevQueue;
    }
    const newQueue = [...prevQueue, songData];
    setCurrentIndex(newQueue.length - 1);
    return newQueue;
  });
}, []);

4. The Challenges & How We Solved Them

1. The Blurry Album Art Dilemma

iTunes returns low-res 100x100 thumbnails by default (artworkUrl100). Instead of letting blurred artwork ruin our glassmorphic UI, our proxy does a string transformation:

thumbnail = track.get('artworkUrl100', '').replace('100x100', '600x600')

Apple's CDN dynamically delivers the high-resolution 600x600 artwork without any extra latency!

2. Preventing Render Free-Tier Cold Starts

Because the backend is hosted on Render's free tier, it sleeps after 15 minutes of inactivity. We set up an automated cron via cronjob.org that pings our /health endpoint every 10 minutes:

@app.route('/health', methods=['GET'])
def health():
    return jsonify({"status": "ok", "service": "melodyone-backend"})

This keeps the Gunicorn worker pool warm 24/7 with zero cold starts for our users.

3. State Synchronization with Clerk Auth & MongoDB

When an authenticated user clicks the "Like" button (♥) on any search result, the track is synced instantly to MongoDB Atlas without interrupting active playback.

5. Key Takeaways

Never call third-party media APIs directly from browser client components if you care about security, rate-limiting, and payload optimization.
Micro-proxies keep frontends fast: A lightweight Flask or FastAPI proxy gives you full control over caching, headers, and data sanitation.
Decoupled state wins: Keeping the search UI separate from the audio playback engine ensures users can browse, search, and navigate while music plays uninterrupted.

🔗 Links & Resources

🌐 Live Demo: MelodyOne on Vercel
💻 Source Code: GitHub Repository
👨‍💻 Developer Portfolio: Shubham Raj Portfolio

Found this helpful? Drop a reaction or let me know your thoughts in the comments below!