DEV Community: Mindinu Ariyawansha

⚡ Stop Defaulting to WebSockets: Why Server-Sent Events (SSE) are Usually Better

Mindinu Ariyawansha — Fri, 04 Sep 2026 04:56:51 +0000

There is a moment in every web developer's career when a client asks: "Can we make this update in real time?"

Your mind immediately jumps to WebSockets. It is the industry buzzword. It sounds fast. You spin up socket.io or Reverb, spend two days fighting with your load balancer, and finally get it working.

But here is the harsh truth: for about 90% of modern web applications—including AI chat streaming, live dashboards, and notification feeds—WebSockets are massive overkill.

Instead, you should probably be using Server-Sent Events (SSE). Here is why SSE is often the cleaner, cheaper, and more pragmatic choice.

The Core Difference

Both WebSockets and SSE exist to push data from the server to the client without the client needing to constantly poll the server.

WebSockets create a full-duplex, persistent TCP connection. Both the client and the server can shout at each other simultaneously.
SSE is a unidirectional, HTTP-based stream. The server keeps a standard HTTP connection open and pushes text-based events down to the client.

Why WebSockets Are a Headache in Production

WebSockets are amazing for multiplayer games or collaborative tools like Google Docs where clients are constantly sending high-frequency data back to the server. But that power comes with a heavy infrastructure tax.

Stateful Scaling: WebSockets are stateful. If you scale horizontally, your load balancer needs connection-aware routing (sticky sessions) to ensure a client's subsequent messages go to the specific server holding their connection.
Proxy Nightmares: Aggressive corporate proxies and firewalls frequently drop WebSocket protocol upgrades, leaving connections in failure modes that are notoriously hard to debug.
Memory Hogs: Maintaining bidirectional frame buffers and tracking protocol state means every single WebSocket connection consumes significantly more server memory than an equivalent HTTP connection.
No Native Reconnect: If a WebSocket connection drops (and it will), the browser does not care. You have to write all the custom logic to detect the drop, backoff, retry, and resynchronize state.

Why SSE is the Underdog You Need

SSE leans on the mature, battle-tested HTTP ecosystem. It doesn't require a protocol upgrade, it doesn't need a custom server, and it works flawlessly with standard load balancers.

Native Auto-Reconnect: The EventSource API in the browser is brilliant. If the connection drops, the browser automatically attempts to reconnect on its own. It even sends a Last-Event-ID header so your server knows exactly where to resume the stream.
Standard HTTP Routing: Because SSE is just a long-lived HTTP request, it scales like any other HTTP endpoint.
Perfect for AI and Dashboards: If you are streaming an LLM response or pushing live price feeds to a dashboard, the client isn't sending data back through that channel (they just make a standard POST request to trigger the event). SSE perfectly models this server-push architecture.

Talk is Cheap. Look at the Code.

Here is how simple it is to implement SSE. No massive libraries, no custom protocols.

Backend (Node/Express):

app.get('/stream', (req, res) => {
  // 1. Set the headers to keep the connection open
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  // 2. Push data whenever you want
  const intervalId = setInterval(() => {
    res.write(`data: ${JSON.stringify({ status: 'Processing...', time: Date.now() })}\n\n`);
  }, 1000);

  // 3. Clean up on disconnect
  req.on('close', () => {
    clearInterval(intervalId);
  });
});

Frontend (Vanilla JS):

// The browser handles connection, streaming, and auto-reconnecting!
const source = new EventSource('/stream');

source.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log("New update:", data);
};

The Decision Framework

WebSockets and SSE aren't competitors; they solve different shapes of problems.

Choose WebSockets if:

You are building a chat app, multiplayer game, or real-time collaborative canvas.
The client needs to push data to the server at high frequencies (10+ times per second).

Choose SSE if:

You are streaming AI responses, live notifications, news feeds, or financial tickers.
The communication is primarily one-way (Server → Client).
You want to avoid managing custom reconnections and complex load balancing.

Next time someone asks for real-time updates, don't immediately reach for the heaviest tool in the box. Give SSE a try.

Have you struggled with WebSocket scaling in production? Let's talk about it in the comments! 👇

🚨 3 PostgreSQL Anti-Patterns That Are Silently Killing Your App's Performance

Mindinu Ariyawansha — Thu, 03 Sep 2026 17:40:23 +0000

PostgreSQL is one of the most powerful relational databases on the planet. Out of the box, it can handle massive workloads. But as your application scales, the way you write queries and structure your schema matters more than the database engine itself.

If your app is starting to feel sluggish, it might not be a lack of resources. You might be falling into one of these three common PostgreSQL anti-patterns.

Here is how to spot them and how to fix them.

1. The `SELECT *` Trap (and why it ruins memory)

When we are iterating quickly, it is incredibly tempting to just write SELECT * FROM users and let the backend filter out the fields it doesn't need.

Why it’s an anti-pattern:
PostgreSQL has to read the data from the disk, load it into memory, and send it over the network to your application. If your users table has 30 columns (including heavy JSONB blobs or large TEXT fields) and you only need the id and email, you are forcing the database to do 10x the I/O work for no reason.

Furthermore, SELECT * breaks index-only scans. If you have an index on email, a query like SELECT email FROM users WHERE email = 'x' can be resolved purely from the index without even touching the main table. SELECT * forces Postgres to fetch the whole row.

The Fix:
Always explicitly define your columns, even if you are using an ORM.

-- ❌ Bad
SELECT * FROM orders WHERE status = 'pending';

-- ✅ Good
SELECT id, customer_id, total_amount FROM orders WHERE status = 'pending';

2. Over-Indexing (The "Just Add an Index" Fallacy)

When a query is slow, the immediate reaction is usually: "Let's just throw an index on that column!"

Why it’s an anti-pattern:
Indexes are not free. Every time you INSERT, UPDATE, or DELETE a row, PostgreSQL has to update the main table and every single index associated with that table. If you have a write-heavy table (like an event logger or analytics tracker) with 10 different indexes, your write latency will skyrocket.

Additionally, Postgres query planners are smart. If an index isn't highly selective (e.g., a boolean column like is_active where 95% of users are active), Postgres will likely ignore the index entirely and do a sequential scan anyway. You are paying the write penalty for an index that never gets used!

The Fix:

Periodically check for unused indexes. Postgres tracks this for you! You can run this query to find indexes that the database is ignoring:

SELECT relname, indexrelname, idx_scan 
FROM pg_catalog.pg_stat_user_indexes 
WHERE idx_scan = 0;

Drop unused indexes and lean into composite indexes for queries that frequently filter by the same multiple columns.

3. The ORM N+1 Query Disaster

If you are using Prisma, TypeORM, Hibernate, or Eloquent, you have probably written this exact bug without realizing it.

Why it’s an anti-pattern:
The N+1 problem occurs when your code fetches a list of records, and then loops through that list to fetch related data for each record.

// ❌ The N+1 Disaster in action
const users = await db.users.findMany(); // 1 query
for (const user of users) {
  // This runs a NEW query for every single user! (N queries)
  const posts = await db.posts.find({ authorId: user.id }); 
}

If you have 1,000 users, you just hit your database 1,001 times over the network for something that should have been a single round trip. This is the #1 cause of API latency.

The Fix:
Use JOINs or rely on your ORM's eager-loading capabilities to fetch everything in a single optimized query.

// ✅ Good: Fetches users and their posts in a single round trip
const usersWithPosts = await db.users.findMany({
  include: { posts: true }
});

Note: Under the hood, this translates to either a LEFT JOIN or exactly two queries (one for users, one for all posts matching those user IDs via an IN clause).

Summary

Scaling a database isn't just about throwing more RAM and CPU at your cloud provider. It is about respecting the network boundary, understanding your indexes, and keeping a close eye on the SQL your ORM is actually generating.

What is the worst database performance bug you've ever had to debug? Let me know in the comments! 👇

🛑 Stop Wasting API Calls: How to Build a Dead-Simple Caching Layer for AI Apps

Mindinu Ariyawansha — Thu, 03 Sep 2026 07:02:59 +0000

Building AI applications is incredibly fun right up until you check your API dashboard and realize you've been burning through credits by sending the exact same prompts during development and testing.

Whether you are using Claude, Gemini, or OpenAI, rate limits and latency are real bottlenecks. If you are building wrappers, agents, or generation tools, you need a caching layer.

Here is a highly effective, zero-dependency caching wrapper in TypeScript that you can drop into any project today.

The Concept

Instead of calling the LLM directly, we pass the prompt through a caching function. We hash the prompt (or use it as a key) and check if we already have a response stored. If yes, we return the cached string instantly. If no, we make the expensive network call, save the result, and return it.

The Code (TypeScript)

This uses a simple in-memory Map, which is perfect for local development or single-instance edge functions.


typescript
// Define an in-memory cache
const responseCache = new Map<string, string>();

async function fetchWithCache(prompt: string): Promise<string> {
  // 1. Check if we already have the exact prompt cached
  if (responseCache.has(prompt)) {
    console.log("⚡ Returning from Cache (0ms)");
    return responseCache.get(prompt)!;
  }

  // 2. If not, make the actual API call (using a generic fetch as an example)
  console.log("☁️ Fetching from API...");
  const response = await fetch("https://dev.to/[https://api.your-llm-provider.com/v1/generate](https://api.your-llm-provider.com/v1/generate)", {
    method: "POST",
    headers: { "Authorization": `Bearer ${process.env.API_KEY}` },
    body: JSON.stringify({ prompt })
  });

  const data = await response.json();
  const textResult = data.choices[0].text;

  // 3. Store the result in the cache for next time
  responseCache.set(prompt, textResult);

  return textResult;
}

🔌 The 'USB-C of AI': Make Your Own MCP

Mindinu Ariyawansha — Wed, 02 Sep 2026 14:41:48 +0000

If you've been building AI-integrated apps recently, you know the pain: every single LLM, agent, and coding assistant needs a custom integration to read your database, check your GitHub repo, or pull Jira tickets. It's an endless cycle of writing custom API glue code.

Enter the Model Context Protocol (MCP).

Originally open-sourced by Anthropic, MCP is rapidly becoming the universal standard for how AI agents talk to data sources. It is quite literally the USB-C of the AI world.

Here is why MCP is completely changing the modern developer stack—and how you can start using it to turbocharge your workflow today.

🤔 What exactly is MCP?

In simple terms, MCP is an open standard that standardizes how AI models access external context. Instead of building a custom plugin for Claude, a different one for Cursor, and another for your custom Python agent, you build one MCP Server.

Any MCP-compatible client (like Claude Desktop, Cursor, or your own app) can instantly connect to that server and understand what tools and data are available.

The Architecture is simple:

MCP Hosts: The application the user interacts with (e.g., Claude Desktop, Cursor IDE).
MCP Clients: The protocol layer inside the host application that manages connections.
MCP Servers: Lightweight programs you run locally or in the cloud that expose your data (e.g., a local SQLite database, a GitHub repo, a Slack workspace).

🛠️ The 3 Core Primitives of MCP

When an AI connects to an MCP server, it gets access to three core primitives:

1. Resources (Read-only data)

Resources are like file systems for AI. They allow the LLM to read data without modifying it.

Example: Giving the AI read access to your local API documentation, system logs, or a Notion workspace.

2. Tools (Executable actions)

Tools are functions the LLM can call to actually do things. The server defines the required arguments, and the client prompts the user for permission before executing.

Example: execute_sql_query, create_github_issue, or restart_docker_container.

3. Prompts (Reusable templates)

Pre-defined prompt templates that help users get the most out of the connected data.

Example: A "Code Review" prompt that automatically pulls the current git diff and asks the LLM to review it against your company's style guide.

🚀 Why this matters for your workflow right now

You don't need to be building an AI startup to benefit from MCP. You can use it today to make your local dev environment incredibly powerful.

Imagine this workflow:
You are debugging an issue in Cursor. Instead of copying and pasting logs from your terminal, you spin up a local Postgres MCP Server and a Datadog MCP Server.

You simply ask your AI:

"Look at the recent 500 errors in Datadog, query the users table in my local Postgres to see if their accounts are active, and find the bug in my codebase."

Because the AI is connected to those MCP servers, it can autonomously fetch the logs, run the SQL query, and fix the code in one seamless interaction.

💻 Building your first MCP Server

Building a server is surprisingly easy. You can write them in TypeScript or Python. Here is the conceptual skeleton of exposing a simple database tool in TypeScript:


typescript
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

// 1. Initialize the server
const server = new McpServer({
  name: "Local-DB-Server",
  version: "1.0.0"
});

// 2. Add a Tool for the AI to use
server.tool(
  "query_users",
  "Run a search query against the local users database",
  { searchTerm: z.string() },
  async ({ searchTerm }) => {
    // Run your actual DB logic here
    const results = await mockDbSearch(searchTerm);
    return {
      content: [{ type: "text", text: JSON.stringify(results) }]
    };
  }
);

// 3. Start listening over standard I/O
const transport = new StdioServerTransport();
await server.connect(transport);

Scaling Multi-Agent Systems: Why Your Docker Container Keeps Crashing

Mindinu Ariyawansha — Wed, 02 Sep 2026 14:22:02 +0000

If you are building autonomous AI agents, you eventually hit a scaling wall. While developing Saturn AI, I noticed that pushing past five or six simultaneous agents caused the entire X11 Docker container to choke, API requests to time out, and the system to crash.

The issue was not the LLM API latency. It was OS process thrashing.

The Root Cause: Process Overhead and Disk I/O

When prototyping, it is common to rely on CLI wrappers to orchestrate agents. However, this introduces massive overhead. If six agents take a turn simultaneously, the backend spawns six heavy Node or Rust processes. If those agents invoke tools, they spawn additional child processes.

The container rapidly runs out of memory, IPC pipe bandwidth, and CPU threads. Furthermore, if these wrappers maintain state by constantly reading and writing JSON session files, the disk I/O locks up completely.

Three Architectural Fixes for Multi-Agent Stability

To resolve this and scale efficiently, you have to treat agent turns like asynchronous network requests rather than OS shell processes.

1. Implement Concurrency Queuing
If you cannot rewrite your engine immediately, introduce an asynchronous job queue using a library like p-queue. Cap the concurrency to two or three active processes at a time. When a trigger wakes up six agents, the queue allows the first few to execute while the others wait in memory. This eliminates CPU thrashing and keeps response times stable.

2. Shift to In-Process SDK Calls
The long-term fix is removing the CLI middleman entirely. Build a custom ReAct loop using a native framework directly inside your main event loop. By executing agent turns as standard asynchronous network calls to the LLM provider, you can run dozens of concurrent agents in a single instance without spawning external processes.

3. Use a Shared "Blackboard" Memory Model
Isolated JSON files for state management will bottleneck your disk. Transition to a shared state model stored directly in memory or a local Redis instance. All agents can instantly read and write their context, tasks, and tool outputs from this shared space. Additionally, boot a single persistent tool server on startup, and have all agents route through it via internal WebSockets, rather than each agent booting its own tool instances.

By shifting away from process-heavy wrappers toward lightweight, async architecture, you can scale multi-agent environments reliably without burning through compute resources.

I got into Batch0

Mindinu Ariyawansha — Tue, 01 Sep 2026 16:32:51 +0000

Hey DEV community! 👋

My name is Mindinu. I am 14 years old, based in Sri Lanka, and I am the founder of Luveo Technologies.

Today, I am super excited to announce a massive milestone for my journey: Luveo Technologies just got accepted into Batch 0!

For those who might not know, being part of a "Batch 0" cohort means you are in the inaugural, foundational group of an accelerator or incubator program. It’s the launchpad cohort. It means the mentors and organizers saw enough raw potential in the vision to take a bet on it from the very beginning.

And the product that got us here? Saturn AI.

🪐 What is Saturn AI?

Saturn AI is an autonomous AI employee.

You might have seen tools like OpenClaw or Viktor, but Saturn AI is being built to be better, faster, and much more deeply integrated into actual developer and business workflows. It’s not just a chatbot; it’s a self-improving AI environment that executes tasks natively.

Under the hood, here is what I am building:

Infrastructure: The entire platform is hosted on a Contabo private VPS, allowing us to manage our own cloud container orchestration without insane cloud fees.
Authentication: Seamless OAuth integration for secure and frictionless user onboarding.
Monetization: A fully custom tiered subscription model currently transitioning to Dodo Payments.
Tech Stack: I'm utilizing tools like ClaudeCode, Gemini CLI, OpenCode, Vite, Bun, and Cloudflare tunnels to build out a robust, scalable backend and a lightning-fast frontend.

🛠️ How I Will Participate in Batch 0

I am treating Batch 0 as a high-speed sprint. Over the course of the program, my goals are strictly technical and growth-focused:

Ship the MVP: Move Saturn AI from a complex local/cloud environment into a stable, user-ready product.
Stress-Test the AI: Push the autonomous agent capabilities to ensure it actually outperforms existing AI employee models in real-world coding and operational tasks.
Build in Public: I am going to document the entire process right here on DEV. Expect deep dives into my Docker configurations, how I manage my VPS, and how I handle the payment gateway architecture.

🚀 The Road Ahead

Building a SaaS product and running a startup at 14 isn't easy. I have to balance school, table tennis training, robotics competitions, and coding late into the night. But getting accepted into Batch 0 validates that the late nights are worth it.

I can't wait to share this journey with you all.

What is the hardest technical challenge you faced when building your first SaaS? Drop some advice for a young founder in the comments! 👇

If you want to follow the journey of Saturn AI, keep an eye on luveo.net and my personal portfolio mindinu.luveo.net.