DEV Community: dundun sun

Title: Building a Zero-Backend AI Stock Bubble Tracker: Architecture, Web Scraping, and Performance Lessons

dundun sun — Thu, 23 Jul 2026 02:17:36 +0000

Every time I open X (formerly Twitter) or Hacker News, I see developers arguing about the AI ecosystem. One camp claims we’re in a permanent super-cycle, while the other insists that massive GPU Capex without proportional software revenue will trigger a dot-com-style market crash.

Instead of taking sides on social media, I decided to do what any sane software engineer would do: build a lightweight, real-time metrics dashboard to track the data myself.

The result is AI Stock Bubble Index.

In this post, I want to walk you through the architectural decisions, client-side performance tricks, data pipeline challenges (like crawling Google News RSS via local proxies without getting rate-limited), and why I chose a completely zero-backend / JAMstack approach for a data-heavy utility site.

The Goal: Low Latency, Zero Server Costs, Max Scannability

When I set out to build this dashboard, I had a strict set of architectural rules:

Zero Database Overheads: I didn't want to maintain a Postgres or MongoDB instance just to serve static or semi-static analytical metrics.
Sub-second Page Loads: Financial dashboards are notoriously bloated. Most stock portals load 40MB of tracking scripts and take five seconds to render a single chart. My site needed to feel instant.
Flawless Core Web Vitals: Cumulative Layout Shift (CLS) needed to be zero, and First Contentful Paint (FCP) had to stay under 500ms on low-end mobile devices.
Automated Data Discovery: News headlines, P/E ratio shifts, and sentiment metrics needed to be updated asynchronously via simple, build-time or client-side JSON hydration.

Here’s how the architecture looks and the engineering lessons learned along the way.

Architectural Overview

The stack is deceptively simple:

Frontend: React (SPA) with component-driven state management.
Component Library: Ant Design, custom-shaken to ensure minimal CSS and JS bundle footprints.
Data Layer: Asynchronously generated, statically served JSON schemas hosted via CDN endpoints.
Scrapers & Aggregators: Node.js (ESM) automation scripts that fetch RSS discovery candidate streams, parse XML, score relevance via term-matching algorithms, and generate structured data payloads.

┌───────────────────────────────┐
│ Google News / Financial Feeds │
└───────────────┬───────────────┘
                │
                ▼ (Node.js ESM Scraper + Proxy)
┌───────────────────────────────┐
│ Term Matching & Weighting     │
└───────────────┬───────────────┘
                │
                ▼
┌───────────────────────────────┐
│ JSON Static Assets (Data CDN) │
└───────────────┬───────────────┘
                │
                ▼ (React Hydration)
┌───────────────────────────────┐
│  AI Stock Bubble UI Dashboard │
└───────────────────────────────┘

Technical Challenge 1: Fetching External Feeds Without Bottlenecks or Proxy Failures

One of the first features of the platform was an automated news discovery tool that aggregates headlines regarding AI Capex, valuations, revenue, and model releases.

If you’ve ever tried scripting Node.js to fetch Google News RSS feeds ([https://news.google.com/rss/search?q=](https://news.google.com/rss/search?q=)...), you know it is a minefield.

Lesson A: Node.js `fetch` (Undici) Ignores Native Proxy Environment Variables

If you run Node 18+ and try using the native fetch() method with standard export HTTPS_PROXY variables in your local environment, it will fail with `UND_ERR_CONNECT_TIMEOUT`.

Why? Because Node's global fetch is built on top of undici, which intentionally bypasses standard system environment proxy flags to maintain spec compliance with Web APIs.

To fix this, you have to explicitly pass a dispatcher or use ProxyAgent directly inside your request logic:

import fs from "node:fs";
import { XMLParser } from "fast-xml-parser";
import { ProxyAgent } from "undici";

// Explicitly route requests through local proxy when testing from restrictive networks
const proxyAgent = new ProxyAgent({ uri: "http://127.0.0.1:7890" });

async function fetchFeed(feedUrl) {
  const response = await fetch(feedUrl, {
    dispatcher: proxyAgent, // Mandatory for undici to route through local tunnels
    headers: {
      "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Chrome/120.0.0.0 Safari/537.36",
      "Accept": "application/rss+xml, application/xml;q=0.9, */*;q=0.8",
      "Accept-Language": "en-US,en;q=0.9"
    }
  });

  if (!response.ok) throw new Error(`HTTP ${response.status}`);
  return await response.text();
}

Lesson B: Custom User-Agents Will Get You Instantly Blocked

Do not set custom User-Agents like "My-Cool-Crawler/1.0". Google’s edge security will identify the non-browser headers and instantly drop your connections with a 403 Forbidden or 503 Service Unavailable. Always mirror standard modern Chrome/Safari User-Agents and include Accept-Language headers.

Technical Challenge 2: Client-Side Scoring & Data Normalization

Instead of sending unstructured text to expensive LLM endpoints on every scrape iteration, I implemented a lightweight, term-matching relevance engine directly in the ingestion script.

We define two primary arrays:

Company Entities: Hardware, cloud, and foundation model providers (Nvidia, Microsoft, TSMC, OpenAI, DeepSeek, etc.).
Relevance Keywords: Financial & risk terms (bubble, valuation, Capex, data center, debt, inference cost, ROI, guidance).

const companyTerms = ["Nvidia", "Microsoft", "TSMC", "OpenAI", "DeepSeek", "Broadcom"];
const relevanceTerms = ["bubble", "valuation", "capex", "debt", "inference cost", "margin"];

export function evaluateHeadline(headline) {
  const normalized = headline.toLowerCase();

  const matchedCompanies = companyTerms.filter((c) => 
    normalized.includes(c.toLowerCase())
  );

  const matchedTerms = relevanceTerms.filter((t) => 
    normalized.includes(t.toLowerCase())
  );

  // Weighted scoring logic: Companies are weighted higher than generic financial buzzwords
  const relevanceScore = (matchedCompanies.length * 2) + matchedTerms.length;

  return {
    matchedCompanies,
    matchedTerms,
    relevanceScore
  };
}

This simple algorithm filters out noisy headlines and retains high-signal candidates without requiring a heavy Python NLP server or paying $50/month in LLM token fees.

Technical Challenge 3: Eliminating Cumulative Layout Shift (CLS) on Financial Charts

If you are rendering interactive line charts or data tables on client devices, layout thrashing is your biggest enemy. Users hate clicking a button only for the layout to jump 200 pixels down because a chart canvas finished rendering a second late.

Here is how I kept CLS down to 0.00 on aistockbubbleindex.com:

1. Explicit Aspect-Ratio Wrappers

Never let your charting component dictate container height dynamically upon data arrival. Always wrap canvases in CSS grid/flex containers with fixed or aspect-ratio locked placeholders:

.chart-container {
  width: 100%;
  min-height: 380px;
  aspect-ratio: 16 / 9;
  contain: layout intrinsic-size; /* Prevents browser reflow during dynamic canvas mounting */
}

2. Decoupled UI State from Canvas Rendering

When users toggle between different metrics (e.g., P/E ratios vs. Capex spending trends), the DOM metadata (headers, index numbers, legend text) updates immediately in React state, while heavy canvas re-draws are deferred using standard requestIdleCallback or microtask queuing.

Technical Challenge 4: SPA SEO for Niche Keywords

Single Page Applications are historically terrible at ranking for specific search terms like "AI stock bubble index" unless you handle DOM structure carefully.

Since I opted against a full server-side Node instance (like Next.js) to keep hosting costs at absolute zero, I focused heavily on semantic HTML optimization:

Semantic Landmarks: No generic <div> soup for critical data blocks. I used <main>, <article>, <section>, and <aside> strictly for structured content.
Structured JSON-LD: Injecting Schema.org data schemas directly into the head tag during static generation so search engine bots can parse metric definitions instantly.
Automated Build-time Sitemaps: Every time news or index candidate files update, a build script updates the sitemap.xml and pings Search Console endpoints automatically.

Results & Performance Benchmarks

By eliminating backend database queries and keeping the frontend architecture razor-thin:

Lighthouse Performance Score: 98/100
First Contentful Paint (FCP): ~0.4s
Cumulative Layout Shift (CLS): 0.00
Monthly Server Costs: $0 (served directly via CDN static edge networks)

Most importantly, I have a functional, noise-free utility that I actually use every week to check the temperature of the AI market without wading through social media hype.

Takeaways for Developers

If you want to build data-driven tools or side projects in 2026, you don't always need a complex server infrastructure.

Before you launch a Docker cluster or pay for database instances:

Ask if your data can be pre-parsed and served as static, edge-cached JSON.
Keep your frontend component bundles minimal.
Optimize your scraping logic with simple term-matching algorithms before reaching for heavy AI models.

Check out the live platform here: https://aistockbubbleindex.com

I’d love to hear your thoughts! How are you handling external API feeds in Node.js ESM setups? How do you keep client-side dashboard rendering fast? Let’s chat in the comments below!

Building a Low-Cost, Zero-Backend AI Stock Bubble Index Tracker

dundun sun — Thu, 16 Jul 2026 02:22:05 +0000

As the discussion around Artificial Intelligence shifts from generative hype to financial sustainability, I wanted to build a dedicated tool to track the "bubble status" of AI-related equities.

Instead of spinning up a heavy Kubernetes cluster or paying for expensive enterprise data pipelines, my goal was to build a highly responsive, SEO-optimized, and low-latency metrics dashboard.

Here is the architectural breakdown of how I built AI Stock Bubble Index.

The Architecture: Keeping it Lightweight
To handle real-time financial sentiment and market data without breaking the bank, I adopted a modern JAMstack / Zero-Backend inspired architecture.

Frontend Framework: Built entirely with a components-driven framework (React) to ensure instant UI state updates when users toggle different tracking metrics.

Data Ingestion: Instead of keeping an active database connection open for every single visitor, market volatility metrics and structural data schemas are processed asynchronously and served via highly optimized JSON endpoints.

Styling & Interactivity: Leveraged highly responsive UI kits alongside custom CSS logic to ensure smooth rendering of data charts across both desktop and mobile viewports.

Technical Challenge 1: Micro-Frontend SEO & Indexing
One of the biggest hurdles for data-heavy, single-page web applications is ensuring that search engine bots can effectively index dynamic keywords like "AI stock bubble".

To tackle this:

Semantic HTML Layouts: I structured the FAQs and dashboard summaries using strict semantic markup rather than nested

soup.

Sitemap & Index Management: Implemented an automated build pipeline that updates the indexation status and alerts search consoles whenever market thresholds trigger significant index shifts.

Technical Challenge 2: Client-Side Data Rendering Efficiency
Rendering multi-asset financial charts on low-end mobile devices can easily choke the main thread.

// A snippet of how data structural layers are evaluated before canvas rendering
export const evaluateBubbleIndex = (metrics) => {
  const { peRatio, sentimentScore, capitalInflow } = metrics;
  // Weighted algorithmic formula to determine the current market exposure
  return (peRatio * 0.5) + (sentimentScore * 0.3) + (capitalInflow * 0.2);
};

By decoupling the layout state from the heavy charting canvas, the page achieves an exceptionally high performance score, keeping cumulative layout shifts (CLS) near zero.

Key Takeaways
Building this index proved that you don't need a complex microservice architecture to launch a functional, data-driven utility platform. By prioritizing clean semantic markup, lightweight state management, and strict build-time optimizations, you can achieve enterprise-grade responsiveness on a hobbyist budget.

Check out the live dashboard here: AI Stock Bubble Index

I'd love to hear your thoughts on the metric weights! How are you handling real-time data streaming on client-side dashboards? Let's discuss in the comments below.

I Built a Sandbox for Neal.fun's Cursor Camp — Here's What Happened

dundun sun — Wed, 03 Jun 2026 07:35:59 +0000

A few months ago I opened Neal Agarwal's Cursor Camp for the first time. You know that feeling when a website completely derails your afternoon? That was me. I spent two hours just watching dozens of cursors wander around a pixel campground, kicking a soccer ball, sitting by the fire.

And then I thought: what if this world kept going even after I closed the tab?

That question eventually turned into CursorCamp Sandbox, a fully interactive browser companion built from scratch. No game engines, just Canvas 2D, SVG, and TypeScript. Here's how a moment of curiosity became a 6,000-line obsession.

The Moment It Clicked
The original Cursor Camp is a genius piece of ambient design. There are no objectives, no tutorials, no signups. You just move your cursor and discover things. The campers (other cursors) wander around doing their own thing. It feels alive, but it's ephemeral — close the tab and it's gone.

I wanted to make a version that felt permanent. A place you could return to. Same whimsical energy, but with persistence, more interactivity, and deeper secrets to uncover.

What I Actually Built
The sandbox ended up with:

55 AI campers, each with a 5-phase movement state machine (idle → accelerate → cruise → decelerate → overshoot). They wander between points of interest, occasionally chasing the soccer ball, randomly joining and leaving throughout the day
An 8,000×5,000 pixel procedurally-generated world with oceans, rivers, roads, a soccer field, running track, vegetable garden, and scattered decorations — all generated from math, no external assets
Dynamic weather — rain and snow with particle systems, wind that drifts over time
Spatial audio — 11 independent sound sources that fade as you move around. The DJ booth has a 4-track playlist that crossfades
17 hidden seashells, a soccer goal, interactive houses you can enter, and benches you can rest on
The entire thing runs at 60fps in a browser with zero dependencies beyond React and Next.js.

The Hardest Part Wasn't the Code
It was resisting the urge to add objectives. I kept wanting to add quests, levels, progression systems. But that would've missed the point. The magic of Cursor Camp is that nothing asks anything of you. You're just... there.

The hardest technical challenge was the camera system. With an 8,000×5,000 world, you can't just center on the player — that would be disorienting. I ended up with a dead-zone approach: the camera only pans when your cursor approaches the screen edges, giving the feel of looking around a physical space.

Why I'm Sharing This
Fan projects don't need to be commercial to be worth building. This one taught me more about Canvas rendering, procedural generation, and game feel than any tutorial ever could. And it brought a small community of people who just wanted to hang out at a virtual campfire.

If you've ever been inspired by someone else's creative work, I encourage you to build something in response. Not a clone, not a competitor — just your own take. It's the most fun you'll have coding.

The sandbox is free and open at https://www.cursorcamp-sandbox.com. No signup, no downloads, no objectives. Just a camp that's always open.

Built with React, Next.js, TypeScript, and exactly zero game engines.

Building a Game with Zero Game Libraries — The Architecture Behind CursorCamp Sandbox

dundun sun — Mon, 25 May 2026 03:26:47 +0000

You'd think building a browser game requires a stack of dependencies. Phaser, PixiJS, maybe Three.js. A physics engine, an audio library, a state manager.

CursorCamp Sandbox does none of that. Zero game engines. Zero physics libraries. Just Next.js, TypeScript, raw Canvas 2D, and inline SVG. Under 6,000 lines of hand-rolled code.

Here's how the architecture works.

What Is It?

An interactive fan-made companion for Neal.fun's Cursor Camp. You explore a procedurally-detailed world, collect seashells, kick soccer balls, and share the space with 55 AI campers. Weather changes. Music fades as you move around. Everything runs in the browser at cursorcamp-sandbox.com.

The Stack (Spoiler: It's Empty)

{
  "dependencies": {
    "next": "14.2.0",
    "react": "^18.3.0",
    "react-dom": "^18.3.0"
  }
}

That's it. Every extra dependency — next-sitemap, tailwindcss, postcss, typescript — is either build tooling or a sitemap generator. The runtime ships with Next.js and React only.

No Phaser. No Matter.js. No Howler.js. No Redux. No Framer Motion.

The Dual-Canvas Rendering Pipeline

The most interesting architectural decision: two HTML Canvas elements overlaid on top of each other, separated by z-index, each responsible for a different set of concerns.

Layer 1 (canvasRef)     → terrain, trees, structures, entities, bots
Layer 2 (cursorCanvasRef) → weather particles, cursor pointers, accessories

This avoids globalCompositeOperation tricks and makes the render loop cleaner. Each canvas gets fully cleared and redrawn every frame via requestAnimationFrame. No dirty-rect tracking, no spatial partitioning — just brute-force, draw-everything, every tick.

Between the two canvas layers sit inline React SVG components positioned absolutely over the world. The DJ stage, the lake, the gym equipment, the banner — all rendered as SVG elements with CSS animations (rotating spotlights, rippling water). They share the same viewBox coordinate system as the canvas, so positioning is consistent.

Why SVG for these? Because CSS animations on SVG elements are GPU-accelerated and don't need to be re-drawn in the canvas loop. The DJ's moving-head spotlights rotate with a few lines of CSS @keyframes instead of recalculating angles in JavaScript every frame.

The State Split That Makes It Work

React isn't built for game loops. If you put framerate-critical state into useState, you'll trigger re-renders 60 times per second and kill performance.

The solution: a deliberate split between useRef and useState.

// Game state → useRef (no re-renders)
const camRef    = useRef<Vec2>({ x: 4000, y: 1050 });
const botsRef   = useRef<Bot[]>(createBots(55));
const ballRef   = useRef<Ball>({ pos: FIELD_CENTER, vel: { x: 0, y: 0 } });

// UI state → useState (triggers re-renders for UI updates)
const [shellsCollected, setShellsCollected] = useState(0);
const [notification, setNotification] = useState("");
const [showJournal, setShowJournal] = useState(false);

The game loop reads and mutates refs 60 times per second without touching React's render cycle. Only UI-relevant state — collected shell counts, notification popups, journal visibility — lives in useState and triggers the normal React pipeline.

This is embarrassingly simple compared to ECS (Entity Component System) architectures, but for a single-developer project with ~200 entities, it works perfectly.

The Bot AI State Machine

55 campers wander the map simultaneously. Each one runs a 5-phase movement state machine:

idle → accel → cruise → decel → overshoot → idle (loop)

State	What It Does
idle	Stands still for 1-4 seconds, fidgets slightly, picks a random destination
accel	Eases into movement along a quadratic Bezier curve toward the target
cruise	Moves at full speed with sub-pixel jitter for natural-looking motion
decel	Eases out as it approaches the target
overshoot	If it passes the target, corrects back with a small counter-movement

A couple bots also keep an eye on the soccer ball. If the ball is kicked near them, they enter a chase mode and move toward it. When the ball is idle too long, a random nearby bot kicks it.

The result looks organic — not like pathfinding soldiers, more like actual people wandering a campsite.

Spatial Proximity Audio

The audio system has no external dependencies. It uses raw HTMLAudioElement objects with proximity-based volume:

export function updateDJProximity(distance: number) {
  const vol = Math.max(0, (1 - distance / 600) * 0.5);
  djAudio.volume = vol;
}

Each sound source — DJ booth, campfire, ocean, river, car horn, football — has its own init and update function. The audio elements are created once at startup and their volumes are modulated every frame based on the player's distance to the sound source.

The DJ system is the most complex: a 4-track playlist that auto-advances on the ended event with crossfading. Walk toward the DJ booth, the music fades in. Walk away, it fades out.

Procedural Terrain, Deterministically

An 8,000 × 5,000 pixel world with oceans, rivers, beaches, roads, soccer fields, running tracks, vegetable gardens, and scattered decorations — all generated at runtime from math.

The secret weapon is a hash2d function that takes two integers and returns a deterministic pseudo-random number:

export function hash2d(x: number, y: number): number {
  let h = (x * 374761393 + y * 668265263 + 1274126177) | 0;
  h = ((h >> 13) ^ h) * 1274126177;
  return (h >>> 0) / 4294967296;
}

Every flower, grass tuft, bush, and stone is positioned using this hash. The result looks organic but is completely deterministic — every render produces the same layout. No random seed, no saved state, just math.

Isometric 2.5D Without a 3D Engine

All SVG components use "fake isometric" rendering: explicit 2D coordinates that simulate depth. Building roofs are parallelograms. Shadows are dark ellipses under entities. The DJ stage platform surface is computed using bilinear interpolation. Everything is top-down isometric drawn in pure 2D — no projection matrices, no 3D transforms.

SVG Data URIs as Sprite Sheets

Every game asset — trees, the campfire, houses, the soccer ball, shells — is an inline SVG stored as a data URI in assets.ts. These are loaded into Image objects once at startup, then drawn with ctx.drawImage() in the game loop.

const TREE_ROUND_SVG = "data:image/svg+xml,...";  // 2KB of hand-crafted SVG
const img = new Image();
img.src = TREE_ROUND_SVG;
// Later, in the render loop:
ctx.drawImage(img, x, y, width, height);

This eliminates all external image requests. The entire game loads as a single HTML page with inline assets.

Weather That Works

Rain and snow are particle systems running on the cursor canvas layer. Rain drops are angled streaks with wind variation. Snow particles float with multi-frequency wobble. Splash particles spawn when rain hits the "ground" at the bottom of the viewport.

The weather system transitions on a timer — 50-100 seconds of clear sky, then 25-35 seconds of rain or snow, with a smooth fade transition in between. Wind direction drifts slowly over time using a sine function.

Water Physics

Wading into the ocean or river doesn't just change the visual — it changes how you move. Ocean depth uses a quadratic resistance curve: ankle-deep gives light drag, while 200px deep makes you nearly immovable. The river applies a consistent 85% drag plus directional current force. Diving in triggers a splash sound via edge-triggered audio.

Why This Matters

The takeaway isn't "you should build games without engines." It's that the browser platform is incredibly capable on its own. Canvas 2D, SVG, CSS animations, and the Web Audio API can handle far more than most developers assume — especially when you're one person building something for the love of it.

No build pipeline for sprite sheets. No WebGL shader debugging. No physics engine configuration. Just TypeScript, math, and the raw browser.

If you want to see it in action, it's at cursorcamp-sandbox.com. The source is all there in your browser's dev tools — no minification, no obfuscation, just readable code.

Built with Next.js 14, TypeScript, and precisely zero game libraries.