Forem: Darshil Mahraur

Saving $300/Month While Fixing WebRTC Drops: How Istio's Consistent Hashing Beat Redis

Darshil Mahraur — Mon, 30 Mar 2026 12:39:05 +0000

I Spent hours Debugging Sessions Until I Discovered Istio Consistent Hashing

A developer's journey from late-night debugging to elegant infrastructure solutions

The Problem That Started a Journey

We had a scaling problem that wouldn't go away.

Our Jarvis service needed to grow. We were scaling from 3 pods to handle more AI inference requests and audio interactions. But there was a critical issue: each Jarvis pod maintained state—model weights loaded in memory, WebRTC connections via daily.co for live audio calls, cached inference results.

When requests bounced randomly between pods (thanks, round-robin load balancer), things broke:

Request 1 (user-123) → Jarvis-Pod-1
  ✓ Model weights loaded, WebRTC connection active

Request 2 (user-123) → Jarvis-Pod-2 (different pod!)
  ✗ "Connection lost" - WebRTC drops
  ✗ Model weights reloaded - 500ms latency spike
  ✗ User's audio call freezes mid-session

Request 3 (user-123) → Jarvis-Pod-1
  ✓ Works again, but connection restarted

Month 1: We implemented Redis

The natural solution was to implement session affinity with Redis. Smaran-v2 would query Redis: "which Jarvis pod for this user?" and route accordingly. It worked well. WebRTC connections stayed alive, latencies improved, users were happy.

But as we scaled, the economics changed:

Cost: $300/month for a Redis cluster
Latency overhead: Every request made a network hop to Redis (5-10ms per request)
Operational toil: TTL management, replica failovers, cache invalidation edge cases

Redis solved the problem, but the cost-benefit ratio wasn't sustainable. We were paying premium dollars for a solution that was becoming a bottleneck. There had to be a more elegant way.

After some R&D: We discovered Istio

Digging through Kubernetes networking docs, I found something elegant: Istio's consistent hashing. No external service. No Redis. Just hash the session ID, map it to a pod—all built into the load balancer.

"Wait, we can remove Redis?" I asked.

"Apparently. Let's build a POC."

What started as a "maybe this could work" conversation turned into a proof-of-concept that would reshape our infrastructure.

My first thought: This is going to be a long night.

The Problem I Didn't Know I Had

Here's the setup. We have two main services:

User Request
    │
    ▼
┌─────────────────────────┐
│   Smaran-v2             │ (coordinator)
│   Routing requests to   │
└──────────┬──────────────┘
           │
           ▼
   ┌───────┴────────┐
   │                │
 Pod-1          Pod-2          Pod-3
 Jarvis         Jarvis         Jarvis
 (w/ state)     (w/ state)     (w/ state)
 (WebRTC)       (WebRTC)       (WebRTC)

Jarvis is the workhorse—it runs AI inference, maintains WebRTC connections via daily.co, and caches model state. We needed to scale it to many pods, which introduced the session affinity problem.

The Jarvis pods weren't just serving requests—they were stateful. Each pod maintained:

Model weights in memory (500MB loaded per pod)
Per-user WebRTC connections via daily.co for audio calls

That last one was critical. When a user started a audio call with daily.co, the Jarvis pod opened a WebRTC connection to participate in that session. If the next request hit a different pod, that connection was completely lost. The WebRTC peer would see a disconnect. The user would see: "Connection lost."

So here's what was happening with Jarvis:

User starts audio call:
Request 1 → Jarvis-Pod-1
  ✓ Creates daily.co WebRTC connection
  ✓ Stream is live

User sends inference request:
Request 2 → Jarvis-Pod-2 (different pod!)
  ✗ Pod-2 has no WebRTC connection
  ✗ Connection drops
  ✗ audio feed freezes

User tries again:
Request 3 → Jarvis-Pod-1
  ✓ Pod-1 still has the connection
  ✓ audio works again (but connection restarted)

And that wasn't even counting the raw performance penalty when a request hit a different Jarvis pod just because Kubernetes's default load balancer said "hey, let's send this request to a different Jarvis pod today."

I definitely knew something was wrong now. That's not something you ignore.

The Debugging Session from Hell

I spent the next few days chasing ghosts:

Day 1: "Must be a database performance issue." Checked query logs. Queries were fine.
Day 2: "Models are degrading?" Profiled inference on a single pod. Blazingly fast.
Day 3: "Network latency?" Ran iperf between pods. Nothing unusual.
Day 4: I added logging to see which pod each request was hitting. That's when it clicked:

Request 1: user-12345 → Pod-1 (100ms) ✓
Request 2: user-12345 → Pod-2 (850ms) ✗ CACHE MISS
Request 3: user-12345 → Pod-3 (900ms) ✗ COLD START
Request 4: user-12345 → Pod-1 (100ms) ✓
Request 5: user-12345 → Pod-2 (850ms) ✗ CACHE MISS

The pattern was unmistakable. The same user's requests were bouncing around like a pinball machine.

First Attempt: The Redis Solution

Need to pin users to pods.

So we built a Redis solution. The idea was straightforward: maintain a mapping of user_id → pod_name (stateful) (where we know the pod name) in Redis.

It worked. Users stopped getting disconnected. WebRTC connections stayed alive. We felt clever.

Then we started scaling.

The Redis Problem:

Every request hit Redis - All traffic went through Redis first. With 10k req/sec, that's 10k Redis lookups per second.
Redis became a bottleneck - We had to add read replicas, tune connection pools, add caching layers.
Cost was insane - A large Redis cluster to handle our traffic? That's several hundred dollars per month.
Failover was sketchy - When Redis went down, pod assignment failed. Users got randomly routed. WebRTC connections dropped again.
TTL management was tricky - Set it too short and sessions expire mid-interaction. Set it too long and stale mappings pile up. We were constantly tuning this.
We could've coded it, but why? - Implementing session affinity logic directly in Smaran-v2 (consistent hashing code, pod registry, health checks, failover logic). But that would mean:
- Infrastructure logic bleeding into application code
- Every service that needs affinity has to reimplement this
- Scaling to new services means copy-paste the same logic again

We realized: "This isn't an application concern. This is infrastructure's job."

After two months of fighting Redis, our tech lead ARP said:

"Have you looked at service meshes? Specifically Istio?"

I hadn't. But ARP's mention was enough to get me digging.

That evening, I started exploring Istio's documentation. The concept of consistent hashing at the networking layer—no Redis, no external state, everything baked into the load balancer—kept gnawing at me.

I read through how DestinationRules work, how Envoy proxies handle traffic routing, and what consistent hashing actually means in practice. The deeper I dug, the more a question crystallized in my mind:

"Wait... so Istio could handle session affinity for us? Without any application code changes? Just configuration?"

Every resource I read pointed to the same answer: yes.

Exploring Istio for Our Use Case

I wasn't immediately convinced this would work for us. Our architecture was specific: Smaran-v2 needed to route requests to specific Jarvis pods based on user session. I had to figure out:

How does consistent hashing actually work in Istio? Dug into the DestinationRule spec and Envoy documentation.
How do we map our user session to a hashing key? We'd need to send a header (like x-call-session-id) that Istio could hash.
Will it actually solve the WebRTC affinity problem? Traced through the request flow to confirm pods would stay consistent.
What are the operational implications? Could we fail over gracefully? What happens when we scale pods?
How fast could we POC this? Estimated timeline for testing without impacting production.

The more I explored, the more elegant it seemed. Not a quick patch like Redis, but a real architectural improvement.

By the end of that week, I was convinced. Here's what made it click:

The Promise:

No external Redis cluster
Session affinity baked into the load balancer
Lower latency (no Redis hop)
Lower cost (no monthly bill)
Reduced operational complexity

The Technical Elegance:
Instead of "all requests from this IP go to Pod-1" (which breaks for our users behind a VPN), Istio offers: "all requests with x-call-session-id: user-12345 go to Pod-2."

And the brilliant part? The hashing is consistent. When we scale from 3 to 10 pods, most requests still map to the same pod. Only ~30% of traffic rebalances. Compare that to round-robin, where all traffic redistributes.

"Let's build a POC," I told the team. "If this works, we can retire Redis."

The Key Insight: DestinationRule

Here's the magic piece. In Istio, you define how traffic should be handled with a DestinationRule. Instead of maintaining Redis mappings, Istio computes the pod assignment on-the-fly using consistent hashing.

I created one for Jarvis:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: jarvis-consistent-hash
  namespace: dev
spec:
  host: jarvis-service.dev.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: "x-call-session-id"
    connectionPool:
      http:
        h2UpgradePolicy: UPGRADE

Let me break down what I was actually doing here:

`httpHeaderName: "x-call-session-id"`

This is the magic. Istio looks at the x-call-session-id header in each request, hashes it, and maps it to a pod. Same header value = same pod, always.

Unlike Redis, there's no external lookup. No network hop. No TTL management. The hash is deterministic and instant. If we have 3 pods and hash the value user-12345, it always maps to Pod-2. If we add a 4th pod tomorrow, most requests still map to the same pod (that's the magic of consistent hashing).

Compare to our Redis approach:

Aspect	Redis Solution	Istio Consistent Hash
Speed	~5-10ms lookup time	<1ms hash computation
Cost	$300+/month for Redis cluster	Built-in, $0
Failover	Redis goes down = broken	No external dependency
Scaling	All traffic rebalances	~1/N rebalance on N→N+1 pods
Operational burden	Tune TTL, manage replicas	Write YAML, forget about it

We literally saved money and got better performance by removing a dependency.

`h2UpgradePolicy: UPGRADE`

This one I learned the hard way. Without it, HTTP/1.1 connections weren't upgrading to HTTP/2. This meant connection pooling wasn't working as expected, and latencies were still higher than they should be. Added this line, and suddenly connection reuse kicked in.

This was especially important for our daily.co WebRTC connections—keeping TCP connections alive and reusing them meant the WebRTC establishment was faster.

The VirtualService: Routing Rules

But wait, where does the header actually come from? I had to ensure Smaran-v2 was sending that header to Jarvis.

I added a VirtualService to route traffic intelligently:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: jarvis-routing
  namespace: dev
spec:
  hosts:
    - jarvis-service.dev.svc.cluster.local
  http:
    # Route with header (gets consistent hashing)
    - match:
        - port: 80
          headers:
            x-call-session-id:
              regex: ".+"
      route:
        - destination:
            host: jarvis-service.dev.svc.cluster.local
            port:
              number: 80
      timeout: 300s
    # Fallback without header (round-robin)
    - match:
        - port: 80
      route:
        - destination:
            host: jarvis-service.dev.svc.cluster.local
            port:
              number: 80
      timeout: 300s

The first block handles requests with the header (these get consistent hashing). The second block is a fallback for requests without the header (they just get round-robin load balancing).

I added that fallback after almost shipping without it. Then I thought: "What if Smaran-v2 forgets the header? What happens?" With the fallback, they still work—they're just not affinity-pinned. That felt reasonable.

mTLS: The Security Layer I Didn't Expect to Need

While setting all this up, our security team (finally) looked at the architecture. They asked a simple question: "Are services talking over plain HTTP?"

Uh. Yes.

Their response was essentially: "Fix that."

Istio made this stupidly easy. One more YAML file:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT

STRICT mode means: if you try to talk to our services over plaintext, it gets rejected. Mutual TLS is enforced everywhere.

I was nervous about this breaking things. Turned out Istio handles the certificate generation and rotation automatically. Zero intervention from us. By the next morning, all inter-service traffic was encrypted.

How It Works: The Request Flow (Redis vs. Istio)

Now here's where Istio became elegant. Let me trace a real request through our system, comparing the two approaches:

OLD REDIS APPROACH (Worked well, but had trade-offs):
1. Client sends request to Smaran-v2 with user-12345 and audio call
2. Smaran-v2 queries Redis: "which Jarvis pod for this user?"
3. Redis lookup: 5-10ms latency
4. Returns: "jarvis-pod-1"
5. Smaran-v2 routes to jarvis-pod-1 directly
6. jarvis-pod-1 has the WebRTC connection and session state
✓ Works reliably, but adds latency and operational overhead

NEW ISTIO APPROACH (Current, way better):
1. Client makes request with session header:
   GET /inference
   Headers: {
     "x-call-session-id": "user-12345-session-audio"
   }

2. Smaran-v2 receives it
   ✓ Extracts x-call-session-id
   ✓ Forwards to Jarvis service with header intact
   (No Redis query needed!)

3. Istio's Envoy Proxy (sidecar in Smaran-v2 or at service boundary) intercepts:
   ✓ Reads x-call-session-id: "user-12345-session-audio"
   ✓ Hashes the value: hash("user-12345-session-audio") = 8421
   ✓ Maps to pod ring: 8421 % N_pods = Jarvis-Pod-1
   ✓ Routes request to jarvis-pod-1
   (All done in <1ms, no external calls!)

4. Jarvis Pod-1 processes request:
   ✓ Session state is hot in memory
   ✓ Model weights already loaded (500MB)
   ✓ WebRTC connection to daily.co is ALIVE
   ✓ Inference completes in ~95ms

5. User continues audio call, sends next inference request:
   Same x-call-session-id header → Jarvis-Pod-1 again
   ✓ WebRTC connection stays open
   ✓ Session context preserved
   ✓ No cold starts, no reconnections
   ✓ Smooth user experience

The difference? Istio eliminates the Redis hop entirely. Same consistent routing, but with:

No external service dependency
Sub-millisecond routing decisions
Zero additional cost
Cleaner architecture

And the WebRTC connections? They stay alive now. The latency improvement alone was worth the migration.

Three Things I Got Wrong (and Learned)

1. Thinking about hashing too much

I spent hours worrying about hash collisions, ring rebalancing, edge cases. In practice? Istio just works. The consistent hash algorithm is proven, and Envoy has optimized it to death. I was overthinking.

2. Not understanding the fallback behavior

I added the VirtualService fallback thinking "this is fine, they'll just get round-robin." Turns out, I should have been more explicit about requiring the header.

In production, we now validate that x-call-session-id is present in Smaran-v2 before it forwards anything to Jarvis. If it's missing, we reject it with a clear error. That's much better than silently degrading to round-robin load balancing and potentially breaking WebRTC connections.

3. Forgetting that Istio adds latency (sometimes)

The Envoy proxy running in each pod adds... actually, negligible latency. Maybe 1-2ms per request for header parsing and routing decisions. But I was paranoid about it anyway. Added observability metrics to track proxy latency specifically. Turned out I was worry for nothing.

When We Scale to 10 Jarvis Pods

This is where the real test will come.

When we scale from 3 to 10 Jarvis pods, I won't expect chaos—but I'll be watching closely. Here's what should happen:

Traffic will redistribute smoothly
No request storms
Existing WebRTC connections will stay pinned to their original pods
New requests will get distributed to the new pods based on their session IDs

It should be... boring. Anticlimactically boring. In the best way.

Pod utilization will spread evenly. Latencies will stay low. The on-call engineer (me) won't get paged.

Redis vs. Istio: The Comparison

After six months running both in different parts of our infrastructure, the choice became unmistakable. Here's how they compare side-by-side:

Aspect	Redis Solution	Istio Consistent Hashing
Architecture	External state store (Redis cluster)	Built into load balancer (no external service)
Cost	$300+/month	$0 (included with Istio)
Latency per Request	5-10ms (Redis lookup)	<1ms (hash computation)
Setup Complexity	Moderate (Redis deployment, tuning)	Low (2 YAML files)
Operational Burden	High (failover, TTL tuning, replicas)	Minimal (Istio manages it)
Network Calls per Request	Every request → Redis	Zero (local routing)
Failure Mode	Redis down → random routing → WebRTC drops	Graceful, no single point of failure
WebRTC Reliability	15-20 disconnects/hour	<1 disconnect/month
Scaling 3→10 pods	100% traffic rebalances (TTL expires)	~30% traffic rebalances (hash ring)
Developer Experience	"Query Redis, route" (app code)	"Send x-call-session-id header" (config)
Testing	Requires Redis mock + K8s API mock	No mocks needed
Scalability Limit	Redis throughput limits growth	Scales linearly with pods

The Verdict: Redis solved the immediate problem. Istio solved it better. Why maintain a separate service for something the routing layer can handle elegantly?

We haven't touched Redis since the migration. Consistent hashing is now foundational to our system—it's in the runbooks, baked into deployments, and new team members learn about it early. WebRTC stability through daily.co is rock solid.

The lesson: you solve a problem one way, it works, you move forward. Then someone shows you a smarter approach, and you realize the trade-offs weren't necessary. That's how infrastructure evolves.

If You're In My Shoes

If you're running stateful services in Kubernetes with WebRTC or persistent connections, or if you're seeing weird latency patterns that don't make sense, or if you're scaling and watching your p99 latencies explode—look into Istio's consistent hashing.

It might save you a 3 AM debugging session (and a lot of frustrated users with dropped audio calls).

The Configs (Copy-Paste Ready)

Save these three files and apply them:

destination-rule.yaml:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: jarvis-consistent-hash
  namespace: dev
spec:
  host: jarvis-service.dev.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: "x-call-session-id"
    connectionPool:
      http:
        h2UpgradePolicy: UPGRADE

virtual-service.yaml:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: jarvis-routing
  namespace: dev
spec:
  hosts:
    - jarvis-service.dev.svc.cluster.local
  http:
    - match:
        - port: 80
          headers:
            x-call-session-id:
              regex: ".+"
      route:
        - destination:
            host: jarvis-service.dev.svc.cluster.local
            port:
              number: 80
      timeout: 300s
    - match:
        - port: 80
      route:
        - destination:
            host: jarvis-service.dev.svc.cluster.local
            port:
              number: 80
      timeout: 300s

peer-authentication.yaml:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT

Deploy:

# Install Istio (if needed)
istioctl install --set profile=demo -y

# Label namespace for auto-injection
kubectl label namespace dev istio-injection=enabled

# Apply configs
kubectl apply -f destination-rule.yaml virtual-service.yaml peer-authentication.yaml

# Restart deployments to pick up new routing
kubectl rollout restart deployment/smaran-v2 -n dev
kubectl rollout restart deployment/jarvis -n dev

Test it:

# From Smaran-v2 or a test pod, send multiple requests with the same header
kubectl run -it debug --image=curlimages/curl --rm --restart=Never -- sh

# Then:
for i in {1..5}; do
  curl -H "x-call-session-id: test-user-123" \
       http://jarvis-service:80/inference
  sleep 1
done

# Watch the Jarvis pod logs and you'll see each request hitting the same pod
# Each request should be fast (no cold starts)

That's the story. From 3 AM panic to elegant infrastructure. From debugging in the dark to understanding why the system works.

It's a pretty good feeling.

Go Programming: A Beginner's Guide

Darshil Mahraur — Thu, 26 Jun 2025 21:00:12 +0000

This is a placeholder for the article body. It would contain introductory material on Go programming.

Building a Smart Task Manager with JavaScript: From Concept to Code

Darshil Mahraur — Thu, 26 Jun 2025 20:55:44 +0000

Building a Smart Task Manager with JavaScript: From Concept to Code

In this tutorial, we'll build a feature-rich task manager application using vanilla JavaScript. This project will demonstrate key JavaScript concepts including DOM manipulation, local storage, event handling, and modern ES6+ features.

🎯 What We're Building

Our task manager will include:

Add, edit, and delete tasks
Task categories and priorities
Due date tracking
Local storage persistence
Search and filter functionality
Responsive design

🏗️ Project Structure

task-manager/
├── index.html
├── styles.css
├── script.js
└── README.md

💻 The JavaScript Implementation

Let's dive into the core JavaScript functionality:

1. Task Class and Data Structure

class Task {
  constructor(id, title, description, category, priority, dueDate, completed = false) {
    this.id = id;
    this.title = title;
    this.description = description;
    this.category = category;
    this.priority = priority;
    this.dueDate = dueDate;
    this.completed = completed;
    this.createdAt = new Date().toISOString();
  }

  // Method to check if task is overdue
  isOverdue() {
    if (!this.dueDate || this.completed) return false;
    return new Date(this.dueDate) < new Date();
  }

  // Method to get days until due
  getDaysUntilDue() {
    if (!this.dueDate) return null;
    const diffTime = new Date(this.dueDate) - new Date();
    return Math.ceil(diffTime / (1000 * 60 * 60 * 24));
  }
}

2. TaskManager Class - The Heart of Our Application

class TaskManager {
  constructor() {
    this.tasks = this.loadTasks();
    this.currentFilter = 'all';
    this.currentSort = 'dueDate';
    this.initializeEventListeners();
    this.renderTasks();
  }

  // Load tasks from localStorage
  loadTasks() {
    const savedTasks = localStorage.getItem('tasks');
    if (savedTasks) {
      return JSON.parse(savedTasks).map(taskData => 
        new Task(
          taskData.id,
          taskData.title,
          taskData.description,
          taskData.category,
          taskData.priority,
          taskData.dueDate,
          taskData.completed
        )
      );
    }
    return [];
  }

  // Save tasks to localStorage
  saveTasks() {
    localStorage.setItem('tasks', JSON.stringify(this.tasks));
  }

  // Add a new task
  addTask(taskData) {
    const task = new Task(
      Date.now().toString(),
      taskData.title,
      taskData.description,
      taskData.category,
      taskData.priority,
      taskData.dueDate
    );

    this.tasks.push(task);
    this.saveTasks();
    this.renderTasks();

    // Show success notification
    this.showNotification('Task added successfully!', 'success');
  }

  // Update an existing task
  updateTask(id, updates) {
    const taskIndex = this.tasks.findIndex(task => task.id === id);
    if (taskIndex !== -1) {
      Object.assign(this.tasks[taskIndex], updates);
      this.saveTasks();
      this.renderTasks();
      this.showNotification('Task updated successfully!', 'success');
    }
  }

  // Delete a task
  deleteTask(id) {
    this.tasks = this.tasks.filter(task => task.id !== id);
    this.saveTasks();
    this.renderTasks();
    this.showNotification('Task deleted successfully!', 'info');
  }

  // Toggle task completion
  toggleTask(id) {
    const task = this.tasks.find(task => task.id === id);
    if (task) {
      task.completed = !task.completed;
      this.saveTasks();
      this.renderTasks();
    }
  }

  // Filter tasks based on status
  filterTasks(filter) {
    this.currentFilter = filter;
    this.renderTasks();
  }

  // Get filtered tasks
  getFilteredTasks() {
    let filteredTasks = [...this.tasks];

    // Apply status filter
    switch (this.currentFilter) {
      case 'active':
        filteredTasks = filteredTasks.filter(task => !task.completed);
        break;
      case 'completed':
        filteredTasks = filteredTasks.filter(task => task.completed);
        break;
      case 'overdue':
        filteredTasks = filteredTasks.filter(task => task.isOverdue());
        break;
    }

    // Sort tasks
    filteredTasks.sort((a, b) => {
      switch (this.currentSort) {
        case 'dueDate':
          if (!a.dueDate && !b.dueDate) return 0;
          if (!a.dueDate) return 1;
          if (!b.dueDate) return -1;
          return new Date(a.dueDate) - new Date(b.dueDate);
        case 'priority':
          const priorityOrder = { high: 3, medium: 2, low: 1 };
          return priorityOrder[b.priority] - priorityOrder[a.priority];
        case 'created':
          return new Date(b.createdAt) - new Date(a.createdAt);
        default:
          return 0;
      }
    });

    return filteredTasks;
  }
}

3. DOM Manipulation and Rendering

// Render tasks to the DOM
renderTasks() {
  const taskList = document.getElementById('task-list');
  const filteredTasks = this.getFilteredTasks();

  taskList.innerHTML = '';

  if (filteredTasks.length === 0) {
    taskList.innerHTML = `
      <div class="empty-state">
        <h3>No tasks found</h3>
        <p>Add a new task to get started!</p>
      </div>
    `;
    return;
  }

  filteredTasks.forEach(task => {
    const taskElement = this.createTaskElement(task);
    taskList.appendChild(taskElement);
  });

  this.updateTaskStats();
}

// Create individual task element
createTaskElement(task) {
  const taskEl = document.createElement('div');
  taskEl.className = `task-item ${task.completed ? 'completed' : ''} ${task.isOverdue() ? 'overdue' : ''}`;
  taskEl.dataset.taskId = task.id;

  const daysUntilDue = task.getDaysUntilDue();
  const dueDateDisplay = task.dueDate ? 
    `<span class="due-date ${task.isOverdue() ? 'overdue' : ''}">
      ${task.isOverdue() ? 'Overdue' : daysUntilDue === 0 ? 'Due today' : `${daysUntilDue} days left`}
    </span>` : '';

  taskEl.innerHTML = `
    <div class="task-content">
      <div class="task-header">
        <input type="checkbox" class="task-checkbox" ${task.completed ? 'checked' : ''}>
        <h3 class="task-title">${task.title}</h3>
        <span class="task-priority priority-${task.priority}">${task.priority.toUpperCase()}</span>
      </div>
      <p class="task-description">${task.description}</p>
      <div class="task-meta">
        <span class="task-category">${task.category}</span>
        ${dueDateDisplay}
      </div>
    </div>
    <div class="task-actions">
      <button class="btn btn-sm btn-secondary edit-task">Edit</button>
      <button class="btn btn-sm btn-danger delete-task">Delete</button>
    </div>
  `;

  return taskEl;
}

4. Event Handling

// Initialize all event listeners
initializeEventListeners() {
  // Task form submission
  document.getElementById('task-form').addEventListener('submit', (e) => {
    e.preventDefault();
    this.handleTaskSubmission(e.target);
  });

  // Filter buttons
  document.querySelectorAll('.filter-btn').forEach(btn => {
    btn.addEventListener('click', (e) => {
      document.querySelectorAll('.filter-btn').forEach(b => b.classList.remove('active'));
      e.target.classList.add('active');
      this.filterTasks(e.target.dataset.filter);
    });
  });

  // Sort dropdown
  document.getElementById('sort-select').addEventListener('change', (e) => {
    this.currentSort = e.target.value;
    this.renderTasks();
  });

  // Search functionality
  document.getElementById('search-input').addEventListener('input', (e) => {
    this.searchTasks(e.target.value);
  });

  // Task list event delegation
  document.getElementById('task-list').addEventListener('click', (e) => {
    const taskItem = e.target.closest('.task-item');
    if (!taskItem) return;

    const taskId = taskItem.dataset.taskId;

    if (e.target.classList.contains('task-checkbox')) {
      this.toggleTask(taskId);
    } else if (e.target.classList.contains('edit-task')) {
      this.editTask(taskId);
    } else if (e.target.classList.contains('delete-task')) {
      this.confirmDeleteTask(taskId);
    }
  });
}

5. Advanced Features

// Search functionality
searchTasks(query) {
  if (!query.trim()) {
    this.renderTasks();
    return;
  }

  const searchResults = this.tasks.filter(task => 
    task.title.toLowerCase().includes(query.toLowerCase()) ||
    task.description.toLowerCase().includes(query.toLowerCase()) ||
    task.category.toLowerCase().includes(query.toLowerCase())
  );

  this.renderFilteredTasks(searchResults);
}

// Task statistics
updateTaskStats() {
  const totalTasks = this.tasks.length;
  const completedTasks = this.tasks.filter(task => task.completed).length;
  const overdueTasks = this.tasks.filter(task => task.isOverdue()).length;

  document.getElementById('total-tasks').textContent = totalTasks;
  document.getElementById('completed-tasks').textContent = completedTasks;
  document.getElementById('overdue-tasks').textContent = overdueTasks;
}

// Notification system
showNotification(message, type = 'info') {
  const notification = document.createElement('div');
  notification.className = `notification notification-${type}`;
  notification.textContent = message;

  document.body.appendChild(notification);

  // Trigger animation
  setTimeout(() => notification.classList.add('show'), 100);

  // Remove notification after 3 seconds
  setTimeout(() => {
    notification.classList.remove('show');
    setTimeout(() => notification.remove(), 300);
  }, 3000);
}

🚀 Initialization and Usage

// Initialize the task manager when DOM is loaded
document.addEventListener('DOMContentLoaded', () => {
  const taskManager = new TaskManager();

  // Make it globally accessible for debugging
  window.taskManager = taskManager;

  console.log('Task Manager initialized successfully!');
});

🎨 Key JavaScript Concepts Demonstrated

1. ES6+ Classes

We use modern class syntax to organize our code into reusable, maintainable components.

2. Array Methods

Extensive use of filter(), map(), find(), sort(), and other array methods for data manipulation.

3. Local Storage

Persistent data storage using the browser's localStorage API.

4. Event Delegation

Efficient event handling using event delegation for dynamic content.

5. Template Literals

Clean string interpolation and multi-line strings for HTML generation.

6. Destructuring and Spread Operator

Modern JavaScript syntax for cleaner, more readable code.

🔧 Performance Optimizations

Event Delegation: Instead of adding listeners to each task, we use a single listener on the container.
Efficient Rendering: Only re-render when necessary and use document fragments for multiple DOM insertions.
Debounced Search: Implement debouncing for search functionality to improve performance.

// Debounced search implementation
const debounce = (func, wait) => {
  let timeout;
  return function executedFunction(...args) {
    const later = () => {
      clearTimeout(timeout);
      func(...args);
    };
    clearTimeout(timeout);
    timeout = setTimeout(later, wait);
  };
}

// Usage
const debouncedSearch = debounce((query) => {
  this.searchTasks(query);
}, 300);

🎯 What You've Learned

Building this task manager teaches you:

Object-Oriented Programming in JavaScript
DOM manipulation techniques
Event handling and delegation
Local storage for data persistence
Array methods for data processing
Modern JavaScript features (ES6+)
Performance optimization techniques

🚀 Next Steps

To extend this project, consider adding:

Drag and drop for task reordering
Task categories with color coding
Export/import functionality
Reminder notifications using the Notification API
Collaborative features with real-time sync
Progressive Web App capabilities

🎉 Conclusion

This task manager demonstrates the power of vanilla JavaScript for building interactive web applications. By understanding these core concepts, you'll be well-equipped to tackle more complex JavaScript projects and frameworks.

The complete source code is available on GitHub. Feel free to fork, modify, and make it your own!

What's your favorite JavaScript feature used in this project? Let me know in the comments below! 👇

Tags: #javascript #webdev #tutorial #programming #beginners

Python Programming

Darshil Mahraur — Thu, 26 Jun 2025 20:53:20 +0000

This is a blog post about Python programming. Please replace this with your actual content.

Building a Weather App: A Complete Guide to Weather APIs and Data Visualization

Darshil Mahraur — Thu, 26 Jun 2025 18:57:32 +0000

Building a Weather App: A Complete Guide to Weather APIs and Data Visualization

Weather applications are among the most popular and useful apps we use daily. Whether you're checking if you need an umbrella or planning a weekend trip, weather data plays a crucial role in our decision-making. In this comprehensive guide, we'll explore how to build a weather application from scratch using modern web technologies.

Why Build a Weather App?

Weather apps are excellent projects for developers because they involve:

API Integration: Working with real-time data from weather services
Data Visualization: Displaying complex information in user-friendly formats
Geolocation: Understanding location-based services
Responsive Design: Creating apps that work across different devices
Real-time Updates: Handling dynamic data that changes frequently

Popular Weather APIs

1. OpenWeatherMap API

OpenWeatherMap is one of the most popular choices for developers:

Free tier: 1,000 calls/day
Features: Current weather, forecasts, historical data
Global coverage: Worldwide weather data
Documentation: Excellent API documentation

2. WeatherAPI

A developer-friendly alternative:

Free tier: 1 million calls/month
Features: Real-time weather, forecasts, astronomy data
JSON/XML: Multiple response formats
Easy integration: Simple REST API

3. AccuWeather API

Enterprise-grade weather data:

High accuracy: Professional weather forecasting
Limited free tier: 50 calls/day
Advanced features: Severe weather alerts, air quality data

Building Your First Weather App

Let's create a simple weather app using JavaScript and the OpenWeatherMap API.

Step 1: HTML Structure

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Weather App</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <div class="container">
        <h1>🌤️ Weather App</h1>
        <div class="search-container">
            <input type="text" id="cityInput" placeholder="Enter city name...">
            <button id="searchBtn">Search</button>
        </div>
        <div class="weather-container" id="weatherContainer">
            <!-- Weather data will be displayed here -->
        </div>
    </div>
    <script src="script.js"></script>
</body>
</html>

Step 2: CSS Styling

* {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
}

body {
    font-family: 'Arial', sans-serif;
    background: linear-gradient(135deg, #74b9ff, #0984e3);
    min-height: 100vh;
    display: flex;
    align-items: center;
    justify-content: center;
}

.container {
    background: rgba(255, 255, 255, 0.95);
    padding: 30px;
    border-radius: 15px;
    box-shadow: 0 15px 35px rgba(0, 0, 0, 0.1);
    min-width: 400px;
}

.search-container {
    display: flex;
    margin-bottom: 30px;
}

#cityInput {
    flex: 1;
    padding: 12px;
    border: 1px solid #ddd;
    border-radius: 5px 0 0 5px;
    font-size: 16px;
}

#searchBtn {
    padding: 12px 20px;
    background: #0984e3;
    color: white;
    border: none;
    border-radius: 0 5px 5px 0;
    cursor: pointer;
    font-size: 16px;
}

.weather-info {
    text-align: center;
}

.temperature {
    font-size: 4em;
    font-weight: bold;
    color: #2d3436;
    margin: 20px 0;
}

.description {
    font-size: 1.5em;
    color: #636e72;
    margin-bottom: 20px;
}

.details {
    display: grid;
    grid-template-columns: repeat(2, 1fr);
    gap: 15px;
    margin-top: 20px;
}

.detail-item {
    background: #f8f9fa;
    padding: 15px;
    border-radius: 8px;
    text-align: center;
}

Step 3: JavaScript Logic

const API_KEY = 'YOUR_API_KEY_HERE'; // Get from OpenWeatherMap
const API_URL = 'https://api.openweathermap.org/data/2.5/weather';

document.getElementById('searchBtn').addEventListener('click', getWeather);
document.getElementById('cityInput').addEventListener('keypress', function(e) {
    if (e.key === 'Enter') {
        getWeather();
    }
});

async function getWeather() {
    const city = document.getElementById('cityInput').value.trim();

    if (!city) {
        alert('Please enter a city name');
        return;
    }

    try {
        const response = await fetch(`${API_URL}?q=${city}&appid=${API_KEY}&units=metric`);

        if (!response.ok) {
            throw new Error('City not found');
        }

        const data = await response.json();
        displayWeather(data);

    } catch (error) {
        alert('Error fetching weather data: ' + error.message);
    }
}

function displayWeather(data) {
    const weatherContainer = document.getElementById('weatherContainer');

    const weatherHTML = `
        <div class="weather-info">
            <h2>${data.name}, ${data.sys.country}</h2>
            <div class="temperature">${Math.round(data.main.temp)}°C</div>
            <div class="description">${data.weather[0].description}</div>
            <div class="details">
                <div class="detail-item">
                    <strong>Feels like</strong><br>
                    ${Math.round(data.main.feels_like)}°C
                </div>
                <div class="detail-item">
                    <strong>Humidity</strong><br>
                    ${data.main.humidity}%
                </div>
                <div class="detail-item">
                    <strong>Wind Speed</strong><br>
                    ${data.wind.speed} m/s
                </div>
                <div class="detail-item">
                    <strong>Pressure</strong><br>
                    ${data.main.pressure} hPa
                </div>
            </div>
        </div>
    `;

    weatherContainer.innerHTML = weatherHTML;
}

// Get user's location weather on page load
window.addEventListener('load', () => {
    if (navigator.geolocation) {
        navigator.geolocation.getCurrentPosition(
            position => {
                const { latitude, longitude } = position.coords;
                getWeatherByCoords(latitude, longitude);
            },
            error => {
                console.log('Geolocation error:', error);
            }
        );
    }
});

async function getWeatherByCoords(lat, lon) {
    try {
        const response = await fetch(`${API_URL}?lat=${lat}&lon=${lon}&appid=${API_KEY}&units=metric`);
        const data = await response.json();
        displayWeather(data);
    } catch (error) {
        console.log('Error fetching weather by coordinates:', error);
    }
}

Advanced Features to Consider

1. Weather Forecasts

Extend your app to show 5-day forecasts:

const FORECAST_URL = 'https://api.openweathermap.org/data/2.5/forecast';

async function getForecast(city) {
    const response = await fetch(`${FORECAST_URL}?q=${city}&appid=${API_KEY}&units=metric`);
    const data = await response.json();

    // Process forecast data
    const dailyForecasts = data.list.filter((item, index) => index % 8 === 0);
    return dailyForecasts;
}

2. Weather Maps

Integrate weather maps using services like:

OpenWeatherMap Maps
Mapbox with weather layers
Google Maps with weather overlays

3. Push Notifications

Add weather alerts and daily forecasts:

// Request notification permission
if ('Notification' in window) {
    Notification.requestPermission().then(permission => {
        if (permission === 'granted') {
            // Schedule weather notifications
            scheduleWeatherNotifications();
        }
    });
}

4. Offline Support

Implement service workers for offline functionality:

// Register service worker
if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/sw.js')
        .then(registration => console.log('SW registered'))
        .catch(error => console.log('SW registration failed'));
}

Best Practices

1. API Key Security

Never expose API keys in client-side code
Use environment variables
Implement server-side proxy for API calls

2. Error Handling

Handle network failures gracefully
Provide meaningful error messages
Implement retry mechanisms

3. Performance Optimization

Cache weather data to reduce API calls
Implement debouncing for search inputs
Use lazy loading for forecast data

4. User Experience

Show loading states during API calls
Implement smooth transitions
Provide fallback content for errors

Conclusion

Building a weather app is an excellent way to learn modern web development concepts while creating something genuinely useful. From basic API integration to advanced features like push notifications and offline support, weather apps offer countless opportunities for learning and improvement.

The key to a successful weather app lies in:

Reliable data sources: Choose APIs with good uptime and accuracy
Intuitive design: Make weather information easy to understand at a glance
Performance: Ensure fast loading times and smooth interactions
Accessibility: Design for users with different needs and devices

Start with a simple implementation and gradually add features as you become more comfortable with the concepts. Remember that the best weather apps are those that solve real problems for real users.

Resources

Happy coding! 🌦️

Convert http to https in AWS

Darshil Mahraur — Sat, 16 Nov 2024 12:13:25 +0000

Upgrade Your EC2 Instance: A Step-by-Step Guide to Securing Your Site with HTTPS!

Overview

To secure the public URL provided by a load balancer when connecting to an EC2 instance within the same VPC, it’s crucial to follow a structured approach. Start by acquiring a registered domain name from a trusted provider like GoDaddy. Next, configure your EC2 instance to function behind an Application Load Balancer (ALB) within the same VPC. Upload your domain to AWS Certificate Manager to obtain a verified SSL/TLS certificate. Finally, integrate this certificate into Route 53 and map it to your load balancer. This setup not only secures your connection but lays the foundation for seamless and reliable traffic management. Let’s dive deeper into the steps—you’re just a few clicks away from an airtight setup!

Prerequisite

Domain Name Registration
Obtain a domain name from a trusted third-party provider say GoDaddy for mapping your load balancer's public URL.
Integration with ALB
Ensure your EC2 instance is connected to an Application Load Balancer within the same VPC to manage traffic securely and efficiently.
You can attain this by referring to this Linkedin post.

Steps

Step 1: Verify Your Domain with AWS Certificate Manager

Go to AWS console and select ACM.
Request a new certificate and keep it public.

Here enter your domain name and keep the setting as selected below. By selecting DNS validation you will get the cname and and it's value.

Copy paste the cname and value to Go Daddy DNS Records. By doing this the certificate will get verified in few minutes.

Once your certificate is successfully issued, the AWS Certificate Manager (ACM) process is complete.

Step 2: Configure Route 53 and Update Nameservers in GoDaddy

Go to AWS Route53 and create your hosted zone with your domain and keep it public zone.

Once the zone is created you will get NS records as shown.

Go to Go Daddy and select nameservers and then change nameservers.
Select the option 'I'll use my own nameservers' and paste the nameserver we got previously from Route53.

Once this is done then your Go Daddy will no more responsible for managing your nameservers. It will look something like this.

Once this is successfully done, the AWS Route53 process is complete.

General Knowledge

Nameservers are part of the Domain Name System (DNS) that translate domain names (like example.com) into IP addresses that computers use to identify each other. They are essential because they direct internet traffic to the correct server, ensuring users can access your website or application seamlessly.
Amazon Route 53 is a scalable DNS web service that connects user requests to internet resources like websites or applications. It manages domain names, routes traffic efficiently, and integrates with AWS services to provide secure, reliable, and highly available routing.

Step 3: Connect your Route53 to Application load balancer.

Create a A record for your domain to connect your Route53 to Application Load Balancer and select 'switch to wizard'

Select simple routing and proceed.

Select 'Define Simple Record' and a pop up menu will appear like this.

Select Application and Classic Load Balancer , the region where it is located and choose the load balancer you have created previously.

Once completed, you'll be able to connect your application using your IP address, but only via HTTP, not HTTPS.

Step 4: Final Step (Make it Https)

Go to Certificate Manager , select your issued certificate and click 'Create record in Route53'. This will link a cname record of this certificate with Route53.

Now link the certificate to the load balancer. Go to your load balancer and add a listener for HTTPS:443.
Under Secure listener settings link your issued certificate from ACM.

Once completed, you'll be able to connect your application using HTTPS.

Conclusion

Congratulations! 🎉 You have successfully completed the HTTP to HTTPS tutorial. Your website is now securely encrypted, providing a safer browsing experience for your users. Great job!

Additionals

Make sure your security groups inbound rules are accepting https traffic.
You can redirect your http traffic to https in the rules section.

New here ,

Darshil Mahraur — Sun, 28 Apr 2024 19:50:42 +0000

Hello everyone , I am new to this platform.