DEV Community: James Mateer

“Simple” live chat almost sank this release

James Mateer — Thu, 18 Jun 2026 13:55:31 +0000

The feature that’s giving me the most trouble right now isn’t some fancy AI or 3D animation. It’s a “basic” live chat system glued to geolocation-based matching and a rating flow that looks trivial in the UI. Under the hood, tying all of this together has been one of the most technical things I’ve shipped so far.

This post is a deep dive into how the app is structured, the decisions that aged well (and the ones that didn’t), and the surprising complexity behind “just show nearby users and let them chat.”

High-level architecture
At a high level, the app is:

Frontend: React + TypeScript SPA, talking to a JSON API over HTTPS.

Backend: Node.js (Express) API server with WebSocket support for live chat.

Data: PostgreSQL for relational data (users, sessions, ratings), Redis for ephemeral presence / active sessions.

The flow:

User signs in → frontend stores a short-lived access token.

Frontend sends location (coarse, not precise) to the backend.

Backend matches user with nearby users based on a distance query.

When a match is confirmed, the backend creates a chat room and establishes a WebSocket channel for both sides.

After the session, users submit a rating, which feeds into a simple reputation system.

Nothing exotic, but the devil is in the details of those three features: geolocation matching, live chat, and ratings.

Geolocation matching: more edge cases than expected
The goal: show users other users “nearby” and match them into sessions. Sounds like a single SQL query, right?

In practice, it involved:

Normalizing and storing locations as latitude/longitude.

Using Postgres with the earthdistance / cube extensions (or a geospatial index) to query by distance.

Handling users with no location / denied permission gracefully.

A simplified version of the core matching query looks like this (roughly):

ts
// Pseudo-DAO: find users within radius (km)
async function findNearbyUsers(userId: string, radiusKm: number) {
const userLocation = await db.query<{
lat: number;
lng: number;
}>(
SELECT lat, lng FROM user_locations WHERE user_id = $1,
[userId]
);

if (!userLocation.rowCount) {
return [];
}

const { lat, lng } = userLocation.rows[0];

const result = await db.query(
SELECT u.id, u.name, ul.lat, ul.lng FROM users u JOIN user_locations ul ON ul.user_id = u.id WHERE u.id != $1 AND earth_distance( ll_to_earth($2, $3), ll_to_earth(ul.lat, ul.lng) ) <= $4 * 1000 ORDER BY earth_distance( ll_to_earth($2, $3), ll_to_earth(ul.lat, ul.lng) ) ASC LIMIT 20,
[userId, lat, lng, radiusKm]
);

return result.rows;
}
The hard parts weren’t just the math; they were:

Deciding how to bucket “nearby” to avoid constantly recalculating for every move.

Handling stale locations when someone moves but doesn’t reopen the app.

Designing fallbacks when location permissions are denied.

If starting over, there would probably be a clearer separation between “location collection” and “matching,” maybe even separate services or queues for heavier recalculations.

Live chat: WebSockets meet reality
Live chat looked straightforward on paper: WebSocket server, rooms, message broadcast. In reality, the tricky part was handling disconnects, reconnections, and keeping the UI in sync with backend state.

The stack:

WebSocket server running alongside the Node.js API.

Redis pub/sub to broadcast messages across multiple server instances.

A simple protocol: JOIN_ROOM, MESSAGE, LEAVE_ROOM, TYPING, etc.

Here’s a simplified version of the server-side message handler that caused the most headaches:

ts
// Simplified WebSocket message handler
type IncomingMessage =
| { type: 'JOIN_ROOM'; roomId: string }
| { type: 'LEAVE_ROOM'; roomId: string }
| { type: 'MESSAGE'; roomId: string; text: string };

function createWebSocketHandler(ws: WebSocket, userId: string) {
const currentRooms = new Set();

ws.on('message', async (raw) => {
let msg: IncomingMessage;

try {
  msg = JSON.parse(raw.toString());
} catch {
  // ignore invalid messages
  return;
}

switch (msg.type) {
  case 'JOIN_ROOM': {
    currentRooms.add(msg.roomId);
    await subscribeUserToRoom(userId, msg.roomId);
    break;
  }

  case 'LEAVE_ROOM': {
    currentRooms.delete(msg.roomId);
    await unsubscribeUserFromRoom(userId, msg.roomId);
    break;
  }

  case 'MESSAGE': {
    if (!currentRooms.has(msg.roomId)) {
      return; // ignore messages sent to rooms user hasn't joined
    }

    const saved = await saveMessage({
      roomId: msg.roomId,
      senderId: userId,
      text: msg.text,
    });

    await broadcastToRoom(msg.roomId, {
      type: 'MESSAGE',
      payload: {
        id: saved.id,
        senderId: userId,
        text: saved.text,
        createdAt: saved.createdAt,
      },
    });

    break;
  }
}

});

ws.on('close', () => {
// Cleanup all rooms on disconnect
for (const roomId of currentRooms) {
void unsubscribeUserFromRoom(userId, roomId);
}
currentRooms.clear();
});
}
What made this hard:

Ensuring messages aren’t processed for rooms the user “left” mid-flight.

Cleaning up subscriptions on unexpected disconnects.

Handling duplicate joins / reconnects without creating ghost sessions.

If rebuilding, there would likely be a more explicit state machine for connection and room membership, instead of ad-hoc flags and sets.

Rating system: deceptively simple
The rating system is “just a 1–5 star rating after each session,” but it quickly touches:

Data modeling (who rates whom, per session).

Preventing duplicate ratings for the same session.

Aggregating ratings efficiently for profile display.

The current approach:

Each session has an id.

Each rating is tied to session_id, rater_id, and ratee_id.

A unique constraint on (session_id, rater_id) to prevent duplicates.

A materialized view / cached aggregate to show average rating and count on profiles.

The part that took time was realizing the need for proper constraints and avoiding over-calculating aggregates on every profile view.

What would be done differently
If starting this project again:

Split “matching” and “chat” into separate modules (or services) with clear boundaries.

Invest in more explicit modelling of connection state for WebSockets.

Add more observability (logs, metrics, tracing) earlier, especially around chat and matching.

Prototype the rating system as an event stream first, then derive aggregates from events.

This has been the most technical article written so far on this project, but it matches how the work actually feels: lots of little decisions that add up to either a clean system or a brittle one.

Your turn (and the repo)

If you’ve built something similar—geolocation, matching, or live chat—there’s a lot that can be learned from your experience.

What would you do differently in this architecture, or what’s one pattern you’ve used for live chat / matching that worked especially well?

AI wrote my bug. I shipped it anyway. Here’s what I learned.

James Mateer — Wed, 20 May 2026 11:08:43 +0000

Last month, I let AI “help” me refactor a small but performance-critical bit of frontend code. It confidently gave me a clean, modern solution. Types checked, tests were green, and the code looked nicer than what I’d written before. I merged it.

Two days later, a user reported that a key interaction was randomly failing. Turned out the bug was subtle, intermittent, and 100% introduced by that AI-generated snippet. The worst part: the code looked so reasonable that my brain just rubber-stamped it.

This is how AI is in my workflow now: incredibly useful, occasionally dangerous, and something I treat more like a junior teammate than a trusted source of truth.

Tools in my day-to-day workflow
Here’s what I actually use as a JavaScript/web dev working on real projects:

GitHub Copilot for inline suggestions, writing boilerplate React components, and quick refactors.

Claude for “bigger brain” tasks: explaining legacy code, generating first-draft docs, and exploring alternative designs.

Browser devtools + tests as the “reality check” layer when AI feels too confident.

AI’s job in my workflow is to speed up the “typing” and help me explore ideas, not to replace my thinking.

When AI really helped: reducing noisy event handlers
I had a React component that attached a scroll listener and did some heavy work on every event. It wasn’t catastrophic, but it caused jank on low-end devices. I asked Copilot to suggest a lightweight throttling solution.

AI-generated suggestion (good enough start)
js
// AI suggestion: basic throttle for scroll handler
function throttle(fn, delay) {
let lastCall = 0;

return function (...args) {
const now = Date.now();
if (now - lastCall >= delay) {
lastCall = now;
fn.apply(this, args);
}
};
}

function handleScroll() {
// expensive calculation
}

window.addEventListener('scroll', throttle(handleScroll, 100));
This was actually pretty decent for my use case. It avoided calling handleScroll on every scroll event and eliminated most of the jank.

I still made adjustments:

Extracted the throttle into a shared utility.

Added proper typing and tests.

Verified behavior in the browser with real scrolling patterns.

Final version after review
ts
// utils/throttle.ts
export function throttle void>(
fn: T,
delay: number
) {
let lastCall = 0;
let timeoutId: number | null = null;

return function (this: unknown, ...args: Parameters) {
const now = Date.now();
const remaining = delay - (now - lastCall);

if (remaining <= 0) {
  lastCall = now;
  if (timeoutId !== null) {
    window.clearTimeout(timeoutId);
    timeoutId = null;
  }
  fn.apply(this, args);
} else if (timeoutId === null) {
  timeoutId = window.setTimeout(() => {
    lastCall = Date.now();
    timeoutId = null;
    fn.apply(this, args);
  }, remaining);
}

};
}
AI got me 60–70% of the way. I added the rest: better handling of calls at the edges, reuse, and type safety.

This is AI at its best in my workflow: drafting something reasonable that I then refine.

When AI misled me: a subtle async bug
Now the painful story.

I had some code that needed to ensure a DOM element existed before measuring it. I asked Copilot for a small helper that “waits for an element to exist then resolves with it or times out.” Copilot produced something like this:

AI suggestion (looked correct, wasn’t)
js
function waitForElement(selector, timeout = 3000) {
return new Promise((resolve, reject) => {
const element = document.querySelector(selector);
if (element) {
resolve(element);
return;
}

const observer = new MutationObserver(() => {
  const el = document.querySelector(selector);
  if (el) {
    observer.disconnect();
    resolve(el);
  }
});

observer.observe(document.body, { childList: true, subtree: true });

setTimeout(() => {
  observer.disconnect();
  reject(new Error('Element not found'));
}, timeout);

});
}
At a glance, it looked fine: observe DOM mutations, resolve when the element appears, reject on timeout. I skimmed it, tests passed, and I shipped it.

The bug? Under certain conditions, the timeout fired after the element was found and resolved. In rare race conditions, the promise would resolve and then later be rejected, causing unpredictable error handling elsewhere.

Corrected version with proper cleanup
js
function waitForElement(selector, timeout = 3000) {
return new Promise((resolve, reject) => {
const existing = document.querySelector(selector);
if (existing) {
resolve(existing);
return;
}

let settled = false;
const observer = new MutationObserver(() => {
  const el = document.querySelector(selector);
  if (el && !settled) {
    settled = true;
    observer.disconnect();
    window.clearTimeout(timeoutId);
    resolve(el);
  }
});

observer.observe(document.body, { childList: true, subtree: true });

const timeoutId = window.setTimeout(() => {
  if (!settled) {
    settled = true;
    observer.disconnect();
    reject(new Error(`Element not found: ${selector}`));
  }
}, timeout);

});
}
Key differences:

Introduced a settled flag.

Cleared the timeout when resolving.

Guarded both paths so the promise only settles once.

This is exactly the kind of subtle bug AI is prone to: the logic is “plausible” and looks idiomatic, but it hasn’t been truly thought through.

My framework for trusting AI (or not)
Here’s how AI fits into my decision-making:

Use AI for:

Boilerplate and repetitive patterns.

Utility functions that I heavily review.

Alternative approaches I might not think of on my own.

Writing tests and docs drafts that I refine.

Be skeptical when:

The code touches async, concurrency, or subtle browser behavior.

It involves security, authentication, or data validation.

The code “just works” and I don’t fully understand why.

Non-negotiables before merging AI code:

Read it line by line and explain it in plain language.

Add tests that would have caught the bug if the code were wrong.

Run it in a realistic environment, not just unit tests.

The mindset shift: AI is a junior engineer with infinite stamina but no real understanding. If it writes something you don’t fully get, that’s your bug waiting to happen.

Your turn
AI is now part of most dev workflows, for better or worse. For me, it’s worth the risk—but only when paired with a strong review habit and healthy skepticism.

How are you using AI in your workflow right now, and what’s one time it either saved you hours or nearly burned you—what happened?

The Scientific Method Made Me Better at Debugging Than I Expected

James Mateer — Fri, 08 May 2026 13:21:00 +0000

One of the first major bugs I hit as a junior developer looked simple at first.

My React frontend refused to talk to my Express backend. The terminal kept throwing errors, the browser showed failed requests, and after a few hours I was convinced I had fundamentally misunderstood how APIs worked.

At first, I did what I think a lot of beginners do: randomly changed things until something worked.

Bad idea.

Eventually I stopped, took a breath, and approached it the same way I used to approach problems in scientific environments: isolate variables and identify root causes.

I started using a simple “5 Whys” approach.

Problem: Frontend couldn’t connect to backend.

Why?
→ The request was failing.

Why?
→ The API endpoint returned a CORS error.

Why?
→ Express wasn’t configured to allow requests from the Vite frontend.

Why?
→ I never added CORS middleware.

Why?
→ I didn’t fully understand how frontend/backend communication actually worked yet.

That single debugging session changed how I think about development.

Instead of treating bugs like random disasters, I started treating them like experiments.

import express from "express";
import cors from "cors";

const app = express();

app.use(cors());

app.listen(3000, () => {
console.log("Server connected on port 3000");
});

The fix itself was tiny.

The lesson was not.

What surprised me most about software development is that professional developers don’t seem to know everything either. Before I started coding, I honestly thought experienced engineers just remembered entire frameworks and instantly knew solutions.

What I’ve discovered instead is that good developers:

Read documentation constantly
Break problems into smaller problems
Search intelligently
Debug methodically
Document what they learn

That last one surprised me most.

I used to think documentation was just corporate busywork. Now I understand it’s one of the most practical skills in development. Half the battle of solving future problems is leaving breadcrumbs for yourself.

I’ve started keeping notes on:

recurring errors
useful terminal commands
ESLint fixes
Git commands I always forget
project setup issues
debugging patterns

Something as simple as this has saved me hours:

git status
git add .
git commit -m "fix: resolved auth middleware issue"
git push origin main

Another thing that surprised me was how emotionally challenging development can be.

There were days where I felt genuinely underqualified. I’d spend hours on something that turned out to be a missing bracket or incorrect import path.

But I’m starting to realise that debugging is not proof that you’re failing.

Debugging is the work.

Every bug forces you to understand the system better than you did before.

One of the most encouraging moments I’ve had so far was seeing this message after hours of troubleshooting:

Server connected on port 3000

Tiny win. Massive confidence boost.

I’m still early in my journey, but I already think my previous experience outside tech gave me an advantage: learning how to think systematically under pressure.

Turns out that skill transfers surprisingly well into software development.

If you're career changing into dev, what's the biggest thing your old career taught you?