DEV Community: Teja

Stop Prop Drilling: Rendering Deeply Nested Dynamic Roadmaps in React and Node.js

Teja — Tue, 23 Jun 2026 09:36:57 +0000

Rendering flat lists in React is trivial. Rendering a deeply nested, dynamically generated UI tree without crashing the browser is a completely different nightmare.

When I was building Skill Path—an application that generates dynamically structured learning roadmaps—I quickly ran into major state management bottlenecks. Passing data down seven levels of a visual roadmap creates an unmaintainable mess of prop drilling.

Here is the architecture I ended up using to bridge a Flask algorithm, a Node.js API, and a React frontend utilizing CSS Grid and glassmorphism.

The Two-Brain Backend Pipeline
Instead of forcing one framework to do everything, I split the backend into two distinct services.

The Engine (Flask): Python is significantly better for handling the complex algorithms needed to build the learning paths. The Flask service generates the raw node relationships.

The API Gateway (Node.js/Express): Node.js handles the client requests, authentication, and caching. It fetches the heavy JSON from Flask, flattens it, and sends it to the frontend.

The JSON Payload Structure
The absolute best trick to making React render fast is formatting your backend payload as a flat dictionary with parent-child ID references, rather than a deeply nested JSON object.

JSON
// How our Node.js server formats the payload for React
{
"roadmap_id": "fullstack_2026",
"nodes": {
"node_1": { "title": "HTML/CSS", "children": ["node_2", "node_3"] },
"node_2": { "title": "CSS Grid", "children": [] },
"node_3": { "title": "JavaScript Basics", "children": ["node_4"] }
}
}
The Frontend: Avoiding the Re-render Trap
If you try to map over a massive nested array in React, any state change (like clicking "Mark as Complete" on a skill) triggers a re-render of the entire tree.

To fix this, I used a centralized state store and rendered individual node components that only care about their specific ID.

The Component Setup
Instead of passing the entire tree down, the top-level component just renders the root node.

JavaScript
import React, { useState } from 'react';
import RoadmapNode from './RoadmapNode';

const SkillPathViewer = ({ roadmapData }) => {
// roadmapData is the flattened JSON from our Node.js backend
const [completedNodes, setCompletedNodes] = useState(new Set());

const toggleComplete = (nodeId) => {
setCompletedNodes(prev => {
const newSet = new Set(prev);
newSet.has(nodeId) ? newSet.delete(nodeId) : newSet.add(nodeId);
return newSet;
});
};

return (

{/* We only render the starting node. It handles its own children. */}

);
};
The Recursive Layout
Because the layout relies on a modern SaaS aesthetic, I used CSS Grid combined with a glassmorphism wrapper for the UI cards. The component is recursive—it calls itself if it detects children.

JavaScript
const RoadmapNode = ({ nodeId, data, toggleComplete }) => {
const node = data[nodeId];
if (!node) return null;

return (

toggleComplete(nodeId)}>

{node.title}

  {/* Recursively render children in a CSS Grid row */}
  {node.children.length > 0 && (
    <div className="grid-children-container">
      {node.children.map(childId => (
        <RoadmapNode data={data} key={childId} nodeId={childId} toggleComplete={toggleComplete} />
      ))}
    </div>
  )}
</div>

);
};
Why This Works
By flattening the state shape on the Node.js server before it ever hits the browser, React only has to execute shallow lookups. Combining this with CSS Grid allowed the visual tree to expand dynamically without requiring messy JavaScript height calculations.

Hardware is Messy: Building DravyaSense, an ESP32 IoT Purity Testing Pipeline

Teja — Tue, 23 Jun 2026 09:29:27 +0000

Building software is relatively predictable. Building IoT hardware pipelines that merge physical sensors with cloud-based machine learning is a complete nightmare of noisy data, dropped packets, and memory leaks.

I recently built DravyaSense, an IoT-based purity testing platform designed to evaluate herbal and chemical samples. The goal was to stream data from multiple physical sensors through an ESP32, pipe it into a cloud dashboard, and run an ML classification model to determine the purity of the sample in real-time.

Here is the architecture I used to keep the ESP32 from crashing while maintaining a deterministic data stream.

The Hardware Constraint (ESP32)

The ESP32 is incredibly powerful for its size, but if you try to read analog sensors, run a WiFi stack, and push MQTT messages all on a single synchronous loop, the watchdog timer will panic and reset the board.

To solve this, I decoupled the sensor reading from the network transmission using a FIFO (First-In, First-Out) buffer and FreeRTOS tasks.

Core Architecture

Task 1 (Core 0): Dedicated entirely to polling the multi-sensor array at a strict 1 kHz frequency. It pushes the raw telemetry into a thread-safe buffer.
Task 2 (Core 1): Handles the WiFi connection, pulls data from the buffer, and publishes it to the cloud dashboard.

The Sensor Polling Logic (C++)

Here is a simplified look at how to handle the deterministic sensor reads without blocking the network layer:


cpp
#include <freertos/FreeRTOS.h>
#include <freertos/task.h>
#include <freertos/queue.h>

QueueHandle_t sensorQueue;

// Structure to hold our multi-sensor payload
struct SensorData {
  float opticalDensity;
  float moistureLevel;
  uint32_t timestamp;
};

void readSensorsTask(void *pvParameters) {
  TickType_t xLastWakeTime = xTaskGetTickCount();
  const TickType_t xFrequency = pdMS_TO_TICKS(1); // 1 kHz loop

  while(true) {
    SensorData currentRead;
    // Simulate reading analog pins
    currentRead.opticalDensity = analogRead(34) * (3.3 / 4095.0);
    currentRead.moistureLevel = analogRead(35) * (3.3 / 4095.0);
    currentRead.timestamp = millis();

    // Push to the queue without blocking
    xQueueSend(sensorQueue, &currentRead, 0);

    // Ensure strict timing
    vTaskDelayUntil(&xLastWakeTime, xFrequency);
  }
}
The Cloud Pipeline & ML Classification
Once the ESP32 successfully packages the raw telemetry, it is pushed to a cloud dashboard. But raw voltage data is useless to an end user.

Instead of trying to run heavy TensorFlow Lite models directly on the ESP32 (which was eating up too much SRAM), I offloaded the inference to the cloud.

How the Pipeline Flows:
Ingestion: The ESP32 publishes the JSON payload to an MQTT broker.

Processing: A Node.js worker service subscribes to the MQTT topic, normalizes the noisy hardware data (applying a simple moving average filter), and stores it in a time-series database.

Inference: A Python backend running a pre-trained scikit-learn Random Forest model pulls the last 5 seconds of data and classifies the sample's purity percentage.

Dashboard: The React frontend updates in real-time, showing the live sensor graphs alongside the ML confidence score.

The Takeaway
When I first prototyped DravyaSense, I tried to do everything on the ESP32—reading, filtering, and classifying. It was a disaster.

The biggest lesson I learned in IoT architecture is to keep the edge device as "dumb" as possible. Let the microcontroller do what it does best (gathering raw electrical signals rapidly) and let the cloud handle the heavy mathematical lifting.
***

**Final Steps for this article:**
1. Copy and paste it into DEV.to.
2. Hit **Preview** to ensure the C++ code block looks clean.
3. Add a cover image if you have a photo of your ESP32 board or your DravyaSense dashboard!
4. **Publish!**

Once this is live, you will officially have three high-quality, deeply technical, and human-sounding articles. 

<FollowUp label="Ready for Draft.dev?" query="Let me know as soon as you hit publish on this third one, so we can go over exactly how to fill out the Draft.dev application to ensure you get accepted!"/>

Killing Latency: Wiring a Voice-Activated Cyber Triage Bot with Gemini and Deepgram

Teja — Tue, 23 Jun 2026 09:25:18 +0000

Typing out incident reports while a server is actively under attack is a massive waste of time. I wanted a way to triage network threats using just my microphone, so I built Aegis-Twin.

Aegis-Twin is a voice-activated AI digital twin specifically engineered for cybersecurity triage. The concept is straightforward: I describe the anomaly out loud, the AI processes the threat context, and it speaks back immediate mitigation steps.

To make this work without lag, I had to completely ditch standard REST APIs for the audio ingestion and wire together Deepgram, Google Gemini, and Murf AI. Here is how the actual pipeline looks under the hood.

The Latency Problem (And Why REST Fails)

If you try to record a WAV file, save it locally, POST it to a transcription API, wait for a response, and then send that to an LLM, your bot is going to take 10 seconds to reply. In a SOC environment, that is useless.

The only way to make conversational AI feel real is by using WebSockets to stream raw PCM audio chunks in real-time.

Phase 1: Streaming Audio to Deepgram

I used Deepgram for the speech-to-text layer because their WebSocket integration is incredibly fast. Instead of waiting for me to stop speaking, it transcribes the audio stream on the fly.

Here is the core async connection loop using Python:


python
import asyncio
from deepgram import DeepgramClient, LiveTranscriptionEvents, LiveOptions

async def stream_mic_audio():
    # Never hardcode this in production, grab it from your .env
    client = DeepgramClient("YOUR_DEEPGRAM_AFFILIATE_KEY")
    dg_connection = client.listen.live.v("1")

    # This fires the millisecond Deepgram detects a spoken word
    def on_transcript(self, result, **kwargs):
        sentence = result.channel.alternatives[0].transcript
        if sentence:
            print(f"Analyst Input: {sentence}")
            asyncio.run(trigger_gemini_reasoning(sentence))

    dg_connection.on(LiveTranscriptionEvents.TranscriptReceived, on_transcript)

    # nova-2 is currently their fastest model for tech jargon
    options = LiveOptions(model="nova-2", language="en-US")
    await dg_connection.start(options)

##  Phase 2: Constraining Google Gemini
import google.generativeai as genai

async def trigger_gemini_reasoning(threat_text):
    genai.configure(api_key="YOUR_GEMINI_API_KEY")

    # Force the LLM to act like a Tier 3 SOC Engineer
    system_rules = """
    You are a cybersecurity triage AI. 
    Do not use conversational filler. 
    Analyze the threat, state the severity, and output exactly two immediate mitigation steps.
    """

    model = genai.GenerativeModel(
        model_name="gemini-1.5-pro",
        system_instruction=system_rules
    )

    response = model.generate_content(threat_text)
    print(f"Aegis-Twin: {response.text}")
    return response.text

## Phase 3: Giving It a Voice with Murf AI
import requests

def speak_mitigation(triage_text):
    url = "[https://api.murf.ai/v1/speech/generate](https://api.murf.ai/v1/speech/generate)"
    headers = {
        "token": "YOUR_MURF_API_KEY",
        "Content-Type": "application/json"
    }
    # Using a crisp, professional voice model
    payload = {
        "voiceId": "en-US-marcus", 
        "text": triage_text
    }

    response = requests.post(url, json=payload, headers=headers)
    if response.status_code == 200:
        audio_url = response.json().get("audioUrl")
        # Pipe this URL to your system's audio output device