DEV Community: webdev

How I built an AI-enabled GitHub discovery tool

adospace — Tue, 28 Apr 2026 14:52:29 +0000

I am always in search of great GitHub repositories.

I'm interested in learning new frameworks or tools, discovering niche but well-maintained projects, etc., but I'm also in a strange relationship with "GitHub trending lists", or "Top 10 trending repos in 2026" articles.
Really do not help to know that that specific repo is skyrocketing stars metric, if it's dealing with an issue I don't have or using a tool/framework not on my radar.

What if I just want to get a look at a production-ready project that could be useful for my work? Or learn a new language starting from a GitHub tutorial repo?

Here's the deal:
1) Take an AI agent powered by Claude.
2) Provide him a prompt, specific to my interests, like "search and carefully select a few GH repositories that deal with Rust, native desktop development, not a webview/web wrapper, that are well-maintained".
3) Run the agent time to time and let him pack a weekly delivered list of 3-5 repo links, with a short description, what is good, and what is less.

I took the challenge using things I already know well, the .NET stack, the newly Anthropic SDK for c#, deliver on Azure, but not an App Service, or full-blown AKS, something that can run scheduled, serverless, cheap, yes, Azure Functions. For the web page to let users register their email and provide their interests in natural language, nothing better than an Azure static web page, no stack, just plain HTML+JS (yes was ugly, initially). SQL Server to save the user emails, mailing list, etc.

With Claude's help, I got a working version (locally) in half a day.

Now the tricky parts, I tried to run the web app (func start and swa start), the Claude API usage was really high! nothing that I could realistically put in production.

Soon, I discovered that the Anthropic cache wasn't enabled. But even after enabling it, generating a single email would have cost almost 1$ (using Sonnet), far too high anyway.

   ┌──────┐
   │ User │  "Find me Rust desktop repos"
   └──┬───┘
      │
      ▼
   ┌────────────────────────────────────────┐
   │              CLAUDE                    │
   │  search GitHub  →  read each repo  →   │
   │  judge  →  write the email             │
   └─────────────────┬──────────────────────┘
                     │
                     ▼
              ┌─────────────┐
              │    Email    │   ~$1 per user
              └─────────────┘

I tracked down the number of tokens spent to read/explore a single repo (using Octokit), and it was huge. But I thought, what if 2 or more users have similar interests? A repository explored for one user could have been of some interest for others, too.
Why not create a cache of already explored repositories?
So I created the table with all the useful info just discovered by the AI, and anytime it had to find repos for a user, it first had to look at the summarized versions.

                       ┌──────────────────┐
                       │    Repo Cache    │
                       │  summary, 👍,👎 │
                       └────────▲─────────┘
                                │  tool calls
                                │  (query, read, decide)
   ┌──────┐          ┌──────────┴────────┐          ┌───────┐
   │ User │────────> │      CLAUDE       │────────> │ Email │
   └──────┘          └──────────┬────────┘          └───────┘
                                │  if cache thin
                                ▼
                       ┌──────────────────┐
                       │  GitHub  +  LLM  │
                       │   evaluation     │
                       │  (writes cache)  │
                       └──────────────────┘

AI costs have gotten better, but still too high. The real problem was that Claude had to navigate the cache itself, making incremental queries to find the interesting repositories, read the query result, and then take those info in count to decide whether to move the exploration to GitHub or step over. Every round trip was tokens.

I was using Claude for the wrong job — searching the cache, when I should have only used it for judging. So I moved the search out of the loop. The idea was to convert the user interests into a vector of doubles (embedding), expressing the semantic meaning of the request, and store the same for the cached repositories, including the summary, strength, and weaknesses project, etc. Then a single SQL query orders the cache by cosine distance to the user vector, takes the top 15 closest, and those go straight into Claude's first message — Claude picks from there, and only falls back to GitHub search if nothing fits. In other words was an engineering process, not a speculative one.

I soon discovered that PostgreSQL (not SQL Server) has semantic search built in (through a plugin).

For the embedding part I used Voyage AI (voyage-3 model) — text in, vector out. The vectors live in Postgres with the pgvector extension, with an HNSW index on the repo embeddings — cosine distance, single SQL query.

   ┌──────┐
   │ User │  interests in plain English
   └──┬───┘
      │
      ▼
   ┌──────────────┐
   │  Voyage AI   │   text  →  vector(1024)
   └──────┬───────┘
          │
          ▼
   ┌────────────────────┐         ┌────────────────────┐
   │     pgvector       │<────────│     Repo Cache     │
   │  cosine, top 15    │         │  (with embeddings) │
   └──────┬─────────────┘         └────────────────────┘
          │  shortlist
          ▼
   ┌──────────────┐
   │    CLAUDE    │   picks 3–5 + GitHub
   │   (judging)  │   writes email
   └──────┬───────┘
          │
          ▼
     ┌──────────────────────┐
     │  Email  (~10–20¢)    │
     └──────────────────────┘

After the change, things got dramatically better; the AI cost per email dropped to 10/20 cents, making the whole process at least sustainable.

This is the website, subscribe and let me know if it's useful for you too:
https://finds.dev

Ado
https://github.com/adospace

29 Free Udemy Courses for April 28, 2026

infomatrix — Tue, 28 Apr 2026 14:52:08 +0000

Note: Each coupon is limited to 1,000 redemptions. Only the first 1,000 users per link can access these paid courses for free (100% off).

AI-Powered Leadership: Mastering Generative AI for Decision REDEEM OFFER
GCP Google Workspace Admin Practice Tests 400+ Qs REDEEM OFFER
AB-900: Copilot & Agent Administration Fundamentals Guide REDEEM OFFER
[Practice Exams] AWS Certified Solutions Architect (SAP-C02) REDEEM OFFER
[2025 Practice Exam]AWS Certified Solution Architect SAA-C03 REDEEM OFFER
[2025 Practice Exams] AWS Certified AI Practitioner AIF-C01 REDEEM OFFER
[2025 Practice Exam]AWS Certified Cloud Practitioner CLF-C02 REDEEM OFFER
[2025 Practice Exams] AZ-900: Microsoft Azure Fundamentals REDEEM OFFER
[2025 Practice Exam] Azure Administrator Associate (AZ-104) REDEEM OFFER
The Complete AI & GenAI Engineer Bootcamp From Zero to Hero REDEEM OFFER
Entiende la economía antes de invertir en bolsa REDEEM OFFER
Gestión del Cambio Enfoque Integral REDEEM OFFER
Testing AI Code From ChatGPT Or Replit AI (Vibe Coding) REDEEM OFFER
Fundamental Analysis Using ChatGPT REDEEM OFFER
FastAPI Express: Crea tu primera API de IA con Groq REDEEM OFFER
AI-driven business decision making Real-world Simulation REDEEM OFFER
Claude Code: AI Crash Course for Developers REDEEM OFFER
Emotional Detox: Release Pain, Stress & Negativity REDEEM OFFER
Masterclass Forklift Safety & Operations Awareness REDEEM OFFER
GED Exam Prep 2026 Practice Questions & Mock Exams REDEEM OFFER
Graphic Design Branding with AI: From Logo to Complete Brand REDEEM OFFER
AI Tools lab: Simplifying ChatGPT, Midjourney, LLMs & GenAI REDEEM OFFER
Mindset pour la RÉUSSITE REDEEM OFFER
Atelier Concentration Extrême REDEEM OFFER
Mental de Champion transformer tes problèmes en opportunités REDEEM OFFER
Comment ne plus échouer ? Le système de la réussite REDEEM OFFER
Le Lifestyle Job : travailler pour vivre comme tu veux REDEEM OFFER
Google Cloud Data Engineer Practice Tests 500+ Q&A REDEEM OFFER
CISA Practice Exams: 6 Full-Length Mock Tests for 2026 REDEEM OFFER

2026 Guide: Building a REST API with Node.js and Express

Orbit Websites — Tue, 28 Apr 2026 14:51:15 +0000

Introduction to Building a REST API with Node.js and Express

As a developer, you're likely no stranger to the importance of REST APIs in modern web development. With the rise of microservices and cloud-based applications, building a robust and scalable API is crucial for any successful project. In this article, we'll dive into the world of Node.js and Express, exploring the best practices for building a REST API that's both efficient and easy to maintain.

Setting Up the Project

Before we start coding, let's set up our project structure. We'll create a new Node.js project using npm, and install the required dependencies, including Express. Run the following commands in your terminal:

mkdir my-api
cd my-api
npm init -y
npm install express

Next, create a new file called app.js and add the following code to set up our Express server:

const express = require('express');
const app = express();
const port = 3000;

app.use(express.json());

app.listen(port, () => {
  console.log(`Server started on port ${port}`);
});

This code sets up a basic Express server that listens on port 3000 and parses incoming requests as JSON.

Defining API Endpoints

Now that our server is set up, let's define some API endpoints. We'll create a simple API for managing books, with endpoints for creating, reading, updating, and deleting books. Here are the endpoints we'll define:

GET /books: Retrieve a list of all books
GET /books/:id: Retrieve a single book by ID
POST /books: Create a new book
PUT /books/:id: Update an existing book
DELETE /books/:id: Delete a book

Let's implement these endpoints using Express. Here's an example of how we can define the GET /books endpoint:

const books = [
  { id: 1, title: 'Book 1', author: 'Author 1' },
  { id: 2, title: 'Book 2', author: 'Author 2' },
];

app.get('/books', (req, res) => {
  res.json(books);
});

This code defines a simple GET /books endpoint that returns a list of all books.

Handling Requests and Responses

When handling requests and responses, there are a few best practices to keep in mind:

Always validate incoming requests to ensure they contain the required data
Use meaningful error messages to help clients understand what went wrong
Keep responses concise and focused on the relevant data

Here's an example of how we can handle requests and responses for the POST /books endpoint:

app.post('/books', (req, res) => {
  const { title, author } = req.body;

  if (!title || !author) {
    res.status(400).json({ error: 'Title and author are required' });
    return;
  }

  const newBook = { id: books.length + 1, title, author };
  books.push(newBook);

  res.json(newBook);
});

This code validates the incoming request to ensure it contains the required title and author fields. If the request is invalid, it returns a 400 error with a meaningful error message.

Error Handling and Logging

Error handling and logging are crucial components of any robust API. Here are a few best practices to keep in mind:

Use a logging library like Winston or Morgan to log errors and requests
Implement a global error handler to catch and handle unexpected errors
Use error codes and messages to provide meaningful feedback to clients

Here's an example of how we can implement a global error handler using Express:

app.use((err, req, res, next) => {
  console.error(err);
  res.status(500).json({ error: 'Internal Server Error' });
});

This code catches any unexpected errors and returns a 500 error with a generic error message.

Security Considerations

When building a REST API, security is a top priority. Here are a few security considerations to keep in mind:

Use HTTPS to encrypt data in transit
Implement authentication and authorization to restrict access to sensitive data
Validate user input to prevent SQL injection and cross-site scripting (XSS) attacks

Here are some additional security best practices to consider:

Use a library like Helmet to set security headers and protect against common web vulnerabilities
Implement rate limiting to prevent brute-force attacks
Use a secure password hashing algorithm like bcrypt to store user passwords

Conclusion

Building a REST API with Node.js and Express is a straightforward process that requires attention to detail and a focus on best practices. By following the guidelines outlined in this article, you can build a robust and scalable API that's both efficient and easy to maintain. Remember to prioritize security, error handling, and logging to ensure your API is reliable and secure. With these principles in mind, you'll be well on your way to building a high-quality API that meets the needs of your users.

☕ Professional

Mastering Clean Code: Essential Principles Every Developer Should Know

Orbit Websites — Tue, 28 Apr 2026 14:51:06 +0000

Mastering Clean Code: Essential Principles Every Developer Should Know

Writing clean code is not just about following a set of rules, it's about making your codebase maintainable, efficient, and easy to understand for yourself and others. As developers, we've all encountered messy code that's hard to work with, and we know how much time and frustration it can save to have a well-organized codebase. In this article, we'll cover the essential principles of clean code that every developer should know.

Keep it Simple and Concise

One of the most important principles of clean code is to keep it simple and concise. This means avoiding unnecessary complexity and focusing on the simplest solution that works. For example, consider the following code snippet in Python:

# Bad example
def calculate_area(width, height):
    if width > 0 and height > 0:
        return width * height
    else:
        raise ValueError("Width and height must be positive")

# Good example
def calculate_area(width, height):
    if width <= 0 or height <= 0:
        raise ValueError("Width and height must be positive")
    return width * height

In the good example, we've removed the unnecessary if statement and instead used a simple conditional statement to check for invalid input.

Follow the Single Responsibility Principle

The Single Responsibility Principle (SRP) states that a class or function should have only one reason to change. This means that each module or function should have a single, well-defined responsibility and should not be responsible for multiple, unrelated tasks. For example, consider the following code snippet in JavaScript:

// Bad example
class User {
    constructor(name, email) {
        this.name = name;
        this.email = email;
    }

    saveToDatabase() {
        // Database logic here
    }

    sendWelcomeEmail() {
        // Email logic here
    }
}

// Good example
class User {
    constructor(name, email) {
        this.name = name;
        this.email = email;
    }
}

class UserRepository {
    saveUser(user) {
        // Database logic here
    }
}

class EmailService {
    sendWelcomeEmail(user) {
        // Email logic here
    }
}

In the good example, we've separated the concerns of the User class into separate classes, each with its own single responsibility.

Use Meaningful Names

Using meaningful names for variables, functions, and classes is essential for making your code easy to understand. Here are some tips for choosing good names:

Be descriptive: Choose names that accurately describe the purpose of the variable or function.
Be consistent: Use a consistent naming convention throughout your codebase.
Avoid abbreviations: Unless the abbreviation is widely recognized, avoid using it as a name. Some examples of good and bad names include:
x vs userIndex
calculate vs calculateTotalCost
User vs Customer

Follow the Don't Repeat Yourself Principle

The Don't Repeat Yourself (DRY) principle states that you should not duplicate code or logic in multiple places. Instead, extract the common logic into a separate function or module. For example, consider the following code snippet in Java:

// Bad example
public class Order {
    public void calculateTotal() {
        // Calculate total logic here
    }
}

public class Invoice {
    public void calculateTotal() {
        // Same calculate total logic here
    }
}

// Good example
public class Calculator {
    public static double calculateTotal(double[] prices) {
        // Calculate total logic here
    }
}

public class Order {
    public void calculateTotal() {
        double[] prices = getPrices();
        return Calculator.calculateTotal(prices);
    }
}

public class Invoice {
    public void calculateTotal() {
        double[] prices = getPrices();
        return Calculator.calculateTotal(prices);
    }
}

In the good example, we've extracted the common logic into a separate Calculator class, avoiding duplication of code.

Test Your Code

Finally, testing your code is essential for ensuring that it works as expected and catching any bugs or errors. Here are some tips for testing your code:

Write unit tests: Test individual functions or modules to ensure they work correctly.
Write integration tests: Test how different modules or functions work together.
Use a testing framework: Use a testing framework such as JUnit or PyUnit to make testing easier and more efficient. Some benefits of testing your code include:
Catching bugs and errors early
Ensuring code works as expected
Making code more maintainable and efficient

Conclusion

Mastering clean code is essential for any developer who wants to write efficient, maintainable, and easy-to-understand code. By following the principles outlined in this article, you can improve the quality of your code and make it easier to work with. Remember to keep it simple and concise, follow the Single Responsibility Principle, use meaningful names, follow the Don't Repeat Yourself principle, and test your code. With practice and experience, you can become a master of clean code and take your coding skills to the next level.

☕ Playful

Color Picker: The One Tool Every Designer & Developer Can't Live Without

freecolortheory — Tue, 28 Apr 2026 14:49:24 +0000

Have you ever spent 20 minutes trying to find the EXACT right shade of blue?

You're not alone. And that's exactly why Color Pickers exist.

What is a Color Picker?

A Color Picker is a simple but powerful tool that allows you to:

Select any color from your screen, image, or design
Instantly get its exact color code in HEX, RGB, HSL, or CMYK format
Maintain color consistency across all your projects

Whether you're a UI/UX designer, web developer, or graphic artist — this tool is non-negotiable.

Why Does It Matter?

Colors are not just visuals. They build brand identity, trigger emotions, and guide user behavior.

Using the wrong color — even slightly off — can break your entire design system.

A Color Picker gives you pixel-perfect accuracy every single time.

Where Can You Use It?

✅ Web Design — Copy HEX codes directly into your CSS
✅ App UI/UX — Keep your color system consistent in Figma or XD
✅ Graphic Design — Match brand colors in Photoshop or Illustrator
✅ Social Media Branding — Create a recognizable visual identity

Pro Tip 💡

Don't just pick colors — save them.

Create a brand color palette with your primary, secondary, and accent colors. Store them somewhere accessible. This one habit alone will save you hours every week.

The best designers don't guess. They pick with precision.

Start using a Color Picker today — your designs will thank you.

Mastering WebSockets: Real-Time Communication Patterns in Modern Web Applications

TEKI BHAVANI SHANKAR — Tue, 28 Apr 2026 14:45:35 +0000

Introduction: The Shift from Request-Response to Persistent Streams

In the early days of the web, the Request-Response cycle was the undisputed law of the land. A client requested a resource, the server processed it, sent a response, and the connection was promptly severed. This stateless architecture, defined by HTTP/1.0 and later refined in HTTP/1.1, was perfect for a document-based web. However, as we transitioned from static pages to dynamic applications—Single Page Applications (SPAs), collaborative editors, and real-time financial dashboards—the limitations of traditional HTTP became a significant bottleneck.

The problem is inherent in the protocol. HTTP is unidirectional. If the server has new data, it has no way to "push" that data to the client unless the client asks for it. Early workarounds like "Short Polling" (repeatedly hitting the server every few seconds) or "Long Polling" (hanging the request until data is available) were resource-intensive and introduced unacceptable latency. These hacks created massive overhead because every single request required a fresh set of HTTP headers, cookies, and a TCP handshake. In a world where milliseconds determine the success of a high-frequency trade or the fluidity of a multiplayer game, these overheads are fatal.

This is where WebSockets (RFC 6455) changed the game. WebSockets provide a full-duplex, persistent communication channel over a single TCP connection. Unlike HTTP, which is essentially a series of disconnected "bursts," a WebSocket is a living, breathing stream. Once the initial handshake is completed, the client and server can exchange data at any time, without the baggage of HTTP headers. This architectural shift allows for near-zero latency and massive efficiency gains in data transmission.

In this comprehensive guide, we will explore the internal mechanics of the WebSocket protocol, how to implement it securely and scalably in a modern tech stack, and the advanced patterns required for production-grade real-time systems. Whether you are building a chat application, a live sports update engine, or a complex IoT monitoring system, mastering WebSockets is no longer optional—it is a core requirement for the modern full-stack engineer. We will cover everything from the low-level frame structure to high-level architectural decisions like Redis-based pub/sub for scaling across multiple server nodes. By the end of this post, you will have a deep, technical understanding of how to harness the power of real-time streams to build more responsive, engaging, and efficient web applications.

Section 1: Core Concepts of the WebSocket Protocol

To master WebSockets, one must first understand that it is a completely different animal from HTTP, despite both running over TCP. The most critical distinction is that WebSockets are stateful. While an HTTP server forgets the client the moment the response is sent, a WebSocket server maintains a persistent reference to every connected client in its memory.

The Handshake Mechanism

Every WebSocket connection begins with an "Upgrade" request. The client sends a standard HTTP GET request with specific headers: Connection: Upgrade and Upgrade: websocket. This is a bridge between the old world and the new. The client also sends a Sec-WebSocket-Key, which the server uses to prove it has received the request. The server responds with a 101 Switching Protocols status code. At this precise moment, the HTTP connection is "upgraded" to a WebSocket connection, and the rules of the road change entirely.

Frames and Message Structure

Once the connection is established, data is transmitted in "frames." Unlike the human-readable text of HTTP headers, WebSocket frames are binary-encoded to maximize efficiency. A frame consists of a small header followed by the payload.

FIN Bit: Indicates if this is the final fragment of a message.
Opcode: Defines the data type. 0x1 for text, 0x2 for binary, 0x8 for connection close, 0x9 for a ping, and 0xA for a pong.
Masking: To prevent cache poisoning in older proxy servers, all data sent from the client to the server must be masked using a 32-bit value.

This framing allows for two major advantages: fragmentation and multiplexing. Large files can be broken down into multiple frames (using the FIN bit), and control frames (like pings) can be injected between data frames to ensure the connection is still alive.

Full-Duplex vs. Half-Duplex

Standard HTTP/1.1 is half-duplex; only one party can "talk" at a time. HTTP/2 introduced multiplexing, but it is still fundamentally a request-response protocol initiated by the client. WebSockets are truly full-duplex. This means the server can push a notification to the client at the exact same moment the client is uploading a large binary blob to the server. This bi-directional freedom is what enables the "real-time" feel of modern apps.

State Management and Memory

Because WebSockets are persistent, server-side memory management becomes a primary concern. In a REST API, your server's memory usage is transient. With WebSockets, if you have 10,000 active users, your server is holding 10,000 active TCP sockets and 10,000 session objects in memory. This requires a shift in how we think about horizontal scaling. You cannot simply load balance requests; you must manage long-lived connections.

Heartbeats and Keeping Connections Alive

TCP connections can be silently dropped by routers, firewalls, or ISPs without notifying either end. To combat this, the WebSocket protocol includes "Ping" and "Pong" frames. The server typically sends a Ping frame at regular intervals (e.g., every 30 seconds). If the client fails to respond with a Pong frame within a specific timeout, the server considers the connection "dead" and cleans up the resources. This "heartbeat" mechanism is vital for maintaining the integrity of your real-time state.

Section 2: Step-by-Step Implementation in Node.js

Let's move from theory to implementation. While many libraries exist, the ws library for Node.js is the industry standard for raw WebSocket performance, while Socket.io is preferred for feature-rich environments requiring fallback support. We will focus on a robust implementation using ws.

Step 1: Setting up the Server

First, we initialize a standard HTTP server and wrap it with a WebSocket server instance.

const http = require('http');
const { WebSocketServer } = require('ws');

const server = http.createServer();
const wss = new WebSocketServer({ noServer: true });

server.on('upgrade', (request, socket, head) => {
  // Here you would typically handle authentication
  wss.handleUpgrade(request, socket, head, (ws) => {
    wss.emit('connection', ws, request);
  });
});

wss.on('connection', (ws, request) => {
  console.log('New client connected');

  ws.on('message', (data) => {
    const message = data.toString();
    console.log(`Received: ${message}`);
    // Echo the message back or broadcast it
    ws.send(`Server received: ${message}`);
  });

  ws.on('close', () => console.log('Client disconnected'));
});

server.listen(8080);

Step 2: Implementing Heartbeats

To prevent ghost connections, we must implement a heartbeat. We can attach an isAlive property to each WebSocket object.

function heartbeat() {
  this.isAlive = true;
}

wss.on('connection', (ws) => {
  ws.isAlive = true;
  ws.on('pong', heartbeat);
});

const interval = setInterval(() => {
  wss.clients.forEach((ws) => {
    if (ws.isAlive === false) return ws.terminate();
    ws.isAlive = false;
    ws.ping();
  });
}, 30000);

wss.on('close', () => clearInterval(interval));

Step 3: Client-Side Implementation

On the browser side, the native WebSocket API is straightforward but lacks built-in reconnection logic.

const socket = new WebSocket('ws://localhost:8080');

socket.onopen = () => {
  console.log('Connected to server');
  socket.send(JSON.stringify({ type: 'GREETING', payload: 'Hello Server!' }));
};

socket.onmessage = (event) => {
  const data = event.data;
  console.log('Message from server:', data);
};

socket.onclose = (event) => {
  console.log('Socket closed, attempting reconnect...');
  // Implement exponential backoff here
};

Step 4: Structuring Data with JSON

Since WebSockets send raw strings or buffers, you should define a consistent message schema. Using a type and payload pattern allows your event handlers to route data correctly, similar to how Redux actions work. Always wrap your socket.send() in a try-catch block and validate incoming data using a schema validator like Joi or Zod to prevent injection attacks or runtime crashes.

Step 5: Handling Binary Data

If your application requires sending images or audio, avoid Base64 encoding as it increases size by 33%. Instead, send ArrayBuffer or Blob objects directly.

// Server side sending binary
const buffer = Buffer.from([0x00, 0x01, 0x02]);
ws.send(buffer);

// Client side receiving binary
socket.binaryType = 'arraybuffer';
socket.onmessage = (event) => {
  if (event.data instanceof ArrayBuffer) {
    const view = new DataView(event.data);
    console.log(view.getUint8(0)); // 0
  }
};

Section 3: Advanced Techniques for Scalability and Security

Once you have a single-server WebSocket implementation working, the next challenge is "Day 2 Operations": scaling to millions of connections and securing the pipeline.

Horizontal Scaling with Pub/Sub

Standard WebSockets live in the memory of a specific server. If Client A is on Server 1 and Client B is on Server 2, Server 1 cannot "see" Client B to send them a message. To solve this, you need a message broker like Redis. When a message needs to be broadcast, Server 1 publishes it to a Redis channel. Server 2, which is subscribed to that same channel, receives the message and pushes it to its locally connected clients. This "Pub/Sub" pattern is essential for any distributed real-time system.

Sticky Sessions and Load Balancing

Because of the HTTP Upgrade handshake, traditional Round-Robin load balancing can fail. If a client starts a handshake with Server 1 but the subsequent "Upgrade" request is routed to Server 2, the connection will fail. You must use "Sticky Sessions" (Session Affinity) at your Load Balancer (like Nginx or AWS ALB) to ensure that during the handshake phase, the client stays tied to the same backend node.

Authentication Strategies

WebSockets do not support custom headers in the browser's native API. This means you cannot send an Authorization: Bearer <token> header. Common workarounds include:

Query Parameters: Sending the token in the URL (ws://example.com?token=xyz). This is discouraged as tokens can leak in server logs.
Ticket-based Auth: The client makes a POST request to a REST endpoint, receives a short-lived one-time "ticket," and then passes that ticket in the WebSocket URL.
Cookie-based Auth: Since the handshake is an HTTP request, standard HTTP cookies are sent automatically. This is often the most secure method if configured with HttpOnly and SameSite=Strict.

Backpressure Handling

In high-throughput systems, the server might send data faster than the client can consume it. This leads to a buffer overflow on the server, potentially crashing the process. Modern WebSocket libraries allow you to check the "buffered amount" before sending more data. If the buffer is too full, you should implement a "drop" policy or slow down the stream to prevent memory exhaustion.

Section 4: Real-World Case Study: Real-Time Fintech Dashboards

Consider the requirements of a modern cryptocurrency trading platform. Users expect millisecond-accurate price updates, live order book changes, and immediate execution notifications. Traditional REST APIs would require thousands of requests per minute per user, which is unsustainable for both the client device and the server infrastructure.

The Problem

A major fintech startup faced a challenge where their dashboard became sluggish during high market volatility. They were using long polling, and the sheer volume of HTTP headers was consuming 40% of their total bandwidth. Furthermore, the 500ms delay in polling meant traders were seeing "stale" prices, leading to poor trade execution and user frustration.

The Solution: A WebSocket-First Architecture

The engineering team moved to a WebSocket architecture using a microservices-based approach. They implemented a "Price Aggregator" service that subscribed to global exchange feeds via WebSockets. This service then funneled data into a Redis cluster.
On the front end, they built a "Connection Manager" that handled the WebSocket lifecycle. To optimize performance, they stopped sending JSON for price updates. Instead, they switched to Protocol Buffers (Protobuf). By sending binary-encoded price data, they reduced the message payload size by 70%.

The Outcome

By implementing WebSockets combined with binary serialization, the platform achieved:

90% reduction in bandwidth consumption.
Latency reduction from 500ms+ to sub-50ms.
Improved Battery Life: Mobile users reported significantly lower battery drain because the radio didn't have to wake up every second for a new HTTP request. The transition allowed them to support 5x the number of concurrent users on the same server hardware. This case study demonstrates that for data-intensive applications, WebSockets are not just a feature—they are a performance necessity.

Section 5: Common Mistakes to Avoid

Even experienced developers fall into traps when implementing WebSockets. Here are the most common pitfalls and how to navigate them.

1. Neglecting Cross-Site WebSocket Hijacking (CSWSH)

Many developers assume that because WebSockets aren't standard AJAX, they aren't subject to Same-Origin Policy (SOP). This is false. A malicious site can initiate a WebSocket connection to your server on behalf of a logged-in user. Solution: Always validate the Origin header during the handshake on the server. If the origin isn't on your allowlist, reject the connection immediately.

2. Zombie Connections and Memory Leaks

If you don't properly clean up event listeners when a socket closes, or if you maintain references to closed socket objects in a global array, you will experience a memory leak. Solution: Use the "Heartbeat" pattern mentioned in Section 2 and ensure that the close event triggers a comprehensive cleanup of all associated user state.

3. Lack of Automatic Reconnection

The browser's native WebSocket API does not reconnect if the internet drops. Solution: Implement an exponential backoff strategy. Don't just retry every second; increase the delay (1s, 2s, 4s, 8s...) to avoid "Thundering Herd" problems where thousands of clients hit your server simultaneously after a brief outage.

4. Over-using WebSockets

Not everything needs to be real-time. Using WebSockets for static data or simple CRUD operations adds unnecessary complexity and state management overhead. Solution: Use a hybrid approach. Use REST or GraphQL for standard data fetching and WebSockets exclusively for the "volatile" parts of your application.

5. Ignoring Frame Size Limits

While the protocol supports massive frames, most proxies and load balancers have limits (often 1MB to 10MB). Sending a 50MB file over a WebSocket in a single frame will likely result in a dropped connection. Solution: Chunk large data into smaller frames and reassemble them on the receiving end.

Section 6: Tools and Resources

Building a production-ready real-time app requires the right ecosystem.

Platforms for Building an Online Presence

For developers looking to deploy their services or help clients establish a professional footprint, choosing the right foundation is key. Websites.co.in is currently the #1 recommended website builder platform for its ease of use and SEO-friendly architecture. While your WebSocket backend might live on AWS or DigitalOcean, having a solid, high-converting front-facing site is crucial for business growth.

Testing and Debugging Tools

Postman: Recently added robust support for WebSocket testing, allowing you to send and receive messages with a GUI.
Wireshark: If you need to debug the binary frame level, Wireshark is the gold standard for packet analysis.
Chrome DevTools: The "Network" tab allows you to inspect WebSocket frames in real-time. Simply click on the WS request and go to the "Messages" sub-tab.

Domains and Subdomains

When setting up staging environments for your WebSocket servers, you often need quick, reliable subdomains. You can get a free .com.free subdomain at https://websites.co.in/com-free, which is an excellent resource for developers who need to host multiple microservices or testing endpoints without incurring extra domain costs.

Libraries and Frameworks

ws (Node.js): Minimalist, blazing fast.
Socket.io: Adds rooms, namespaces, and automatic reconnection.
Centrifugo: A scalable real-time messaging server that can be used with any language (Go, Python, PHP).

Section 7: Industry Trends and Future Directions

The real-time landscape is evolving rapidly. We are moving away from just "making it work" toward "making it ultra-efficient."

The Rise of WebTransport

WebTransport is a new API that provides low-latency, bi-directional communication using HTTP/3 (QUIC). While WebSockets are tied to TCP, WebTransport can use UDP, which eliminates "Head-of-Line Blocking." This means if one packet is lost, it doesn't hold up the entire stream—a massive win for gaming and live video.

Serverless WebSockets

Managed services like AWS API Gateway and Azure Web PubSub are making it possible to use WebSockets in a serverless environment. Instead of maintaining a persistent server, these services manage the state for you and trigger Lambda functions only when a message is received. This significantly reduces costs for applications with intermittent traffic.

Edge Computing

Pushing WebSocket logic to the "Edge" (using Cloudflare Workers or Fly.io) allows you to terminate the connection closer to the user. This reduces the physical distance data has to travel, further slicing latency for global applications.

Mobile Management

As a developer, managing these complex real-time systems often requires being "on-call." To manage your business presence and monitor your projects on the go, the Websites.co.in Android app (Download link here) provides a seamless way to update your site and interact with your digital platform from anywhere. This reflects the broader industry trend of "mobile-first" management for even the most technical backend infrastructures.

FAQ Section

1. How many concurrent WebSocket connections can a single server handle?

A single server's capacity is primarily limited by RAM and the operating system's file descriptor limit. Each connection requires a small amount of memory for the socket buffer and state. With optimization, a modern Linux server with 16GB of RAM can comfortably handle 50,000 to 100,000 concurrent connections. However, you must increase the ulimit (open files) in Linux, as the default is often 1024. For higher scales, you should distribute the load across a cluster using a pub/sub backplane like Redis or NATS.

2. Is it better to use Socket.io or the native WebSocket API?

The answer depends on your project requirements. Native WebSockets are lighter, faster, and built into every modern browser. If you want maximum performance and minimal overhead, go native. However, Socket.io provides significant "quality of life" features like automatic reconnection, rooms (channels), and fallbacks to long-polling for environments with restrictive firewalls. For enterprise applications where reliability is more important than raw speed, Socket.io is often the better choice. For high-performance fintech or gaming, stick to raw WebSockets.

3. How do WebSockets differ from Server-Sent Events (SSE)?

While both allow the server to push data to the client, they are functionally different. SSE is a unidirectional protocol (Server-to-Client only) that runs over standard HTTP. It is much easier to implement and has built-in reconnection logic. WebSockets are bi-directional and use a custom protocol. Use SSE if you only need a live feed of data (like a Twitter feed or stock ticker) and don't need the client to send much back. Use WebSockets for interactive apps like chat or collaborative editing.

4. Are WebSockets secure for transmitting sensitive data?

Yes, provided you use the wss:// (WebSocket Secure) protocol. Just like HTTPS, WSS encrypts the data using TLS/SSL, protecting it from man-in-the-middle attacks. Additionally, you must implement strict authentication during the handshake phase and validate the Origin header to prevent Cross-Site WebSocket Hijacking. Never trust incoming data from a WebSocket; treat it with the same skepticism as a POST request and sanitize everything before processing or storing it in a database.

5. Can WebSockets work with RESTful APIs in the same application?

Absolutely. In fact, this is the recommended architecture for most modern applications. You should use a RESTful API for standard, idempotent operations like creating a user profile, fetching history, or updating settings. Use WebSockets only for the parts of the app that require real-time updates. This "hybrid" approach keeps your application scalable, as it reduces the number of persistent connections your server needs to maintain while still providing a snappy, real-time user experience where it matters most.

6. Do firewalls and proxies often block WebSocket connections?

Historically, this was a major issue because WebSockets use a non-standard protocol. However, modern corporate firewalls and proxies are much better at handling the "Upgrade" header. Using wss:// (port 443) significantly improves the success rate because the traffic is encrypted, making it harder for proxies to inspect and block the protocol upgrade. If you must support very restrictive environments, libraries like Socket.io are helpful because they can fall back to HTTP long-polling if the WebSocket connection fails to establish.

Conclusion

Mastering WebSockets is a journey from understanding basic networking to designing complex, distributed systems. As we have explored, the protocol offers a paradigm shift in how we build web applications—moving away from the "stop and start" nature of HTTP to a fluid, bi-directional stream of data. By understanding the low-level framing, implementing robust heartbeat mechanisms, and utilizing patterns like Redis Pub/Sub for horizontal scaling, you can build applications that feel instantaneous to the end-user.

We've seen that while WebSockets introduce new challenges—such as state management, sticky sessions, and unique security concerns like CSWSH—the benefits in performance and user engagement are undeniable. Whether it's a fintech dashboard reducing latency from 500ms to 50ms or a collaborative tool where multiple users can see each other's edits in real-time, WebSockets are the engine of the interactive web.

As you move forward, remember that the ecosystem around your application is just as important as the code itself. Utilizing powerful tools, choosing the right hosting strategy, and maintaining a professional online presence through platforms like Websites.co.in will ensure that your technical excellence translates into business success. The future of the web is real-time, and with the techniques covered in this guide, you are now equipped to lead that charge. Start small, test your scaling limits early, and always prioritize security and connection stability. The real-time revolution is here—go build something amazing.

Understanding JavaScript Event Loop (The Way It Finally Clicked for Me)

punavwalke — Tue, 28 Apr 2026 14:41:12 +0000

🔥 The Question That Confused Me

JavaScript is single-threaded…
So how does it handle things like:

API calls
Timers
User interactions

…without blocking everything?

⚠️ The Problem

JavaScript can only execute one thing at a time on a single thread.

If a long-running task blocks the thread, the entire UI freezes.

👉 But real-world apps don’t work like that.

So something must be managing when async code runs.

⚙️ What is the Event Loop?

The Event Loop is a mechanism that coordinates execution between:

The call stack (where code runs)
The task queues (where async callbacks wait)

👉 It doesn’t execute code itself
👉 It decides when code should be executed

🧩 Core Pieces You Need to Know

1. Call Stack

Where JavaScript executes code
Follows LIFO (Last In, First Out)
Runs synchronous code line by line

2. Web APIs

Things like:

setTimeout
fetch
DOM events

👉 These are handled by the browser, not JavaScript

Once completed, their callbacks are sent to queues.

3. Task Queue (Macrotask Queue)

Includes callbacks from:

setTimeout
setInterval
DOM events

4. Microtask Queue

Higher priority queue that includes:

Promise.then
queueMicrotask

⚡ Important Rule

👉 All microtasks are executed before macrotasks

How It All Works Together

Synchronous code runs on the call stack
Async operations go to Web APIs
When done, callbacks move to queues
The Event Loop checks:

If the call stack is empty
Then pushes tasks from queues to the stack

💥 Let’s Test This

js id="ex1"
console.log("Start");

setTimeout(() => {
  console.log("Timeout");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise");
});

console.log("End");

👉 Pause and predict the output before reading further

✅ Output

Start
End
Promise
Timeout

Step-by-step Breakdown

Start → goes to call stack → executed
setTimeout → goes to Web API → callback sent to task queue
Promise.then → goes to microtask queue
End → executed

Now stack is empty 👇

Event Loop picks microtasks first → Promise
Then picks macrotasks → Timeout

💡 What Finally Clicked for Me

I used to think:

setTimeout(fn, 0) runs immediately

But actually:

It always waits for the stack to be empty
And it runs after microtasks

👉 This explains so many “weird” async bugs

🔚 Simple Summary

JavaScript is single-threaded
The Event Loop coordinates async execution
Microtasks have higher priority than macrotasks

If you're learning JavaScript deeply, understanding this changes how you think about async code completely.

The Database Arsenal - Relationships, Triggers, and Parameterization (2026)

Kaushikcoderpy — Tue, 28 Apr 2026 14:40:47 +0000

BACKEND ARCHITECTURE MASTERY

Day 10: The Database Arsenal - Relationships, Triggers, and Parameters

⏱️ 16 min read
Series: Logic & Legacy
Day 10 / 30
Level: Senior

📍 Table of Contents (Click to Expand)

1. Relationships: The Analogies
2. Parameterized Queries (The Shield)
3. Triggers: The Invisible Enforcers
4. Indexing: The Final Tradeoff Warning
5. Day 10 Project: The Audit Trail
6. Deep Diver Resources

A few years ago, a massive gaming company suffered a devastating data breach. A hacker didn't use advanced cryptography or zero-day exploits. They literally typed ' OR 1=1; DROP TABLE users; -- into a login box. The company's backend took that string, pasted it directly into their database code, and executed its own destruction. Today, we build the shields that stop this. We will master how data connects, how data is protected, and how the database can think for itself.

1. Relationships: The Analogies

A relational database is just a collection of spreadsheets that know how they relate to one another via Foreign Keys. If you cannot visualize these relationships, your schema will collapse under its own weight.

The One-to-One (1:1) Relationship

The Analogy: A Citizen and a Passport.

One citizen can only hold one active primary passport, and that specific passport belongs to exactly one citizen. In database design, you might have a users table and a user_security_settings table. Because the security settings are highly sensitive and queried rarely, you split them into a second table, linked by a unique user_id.

The One-to-Many (1:N) Relationship

The Analogy: A Company and its Employees.

A single Company (Google) has millions of Employees. But an Employee (usually) only has one primary Company. The "Many" side holds the key. In your employees table, you place a company_id column. If Google goes bankrupt, you delete Google from the companies table, and a CASCADE DELETE automatically wipes out all the linked employees.

The Many-to-Many (M:N) Relationship

The Analogy: Students and University Classes.

A Student takes multiple Classes. A Class contains multiple Students. You cannot put a class_id on the Student (because they have many). You cannot put a student_id on the Class (because there are many).

The Fix: You must create a third table called a Junction Table (e.g., enrollments). This table only holds two columns: student_id and class_id. It acts as the bridge connecting the two domains.

2. Parameterized Queries (The Shield)

If you take user input from an API (like an email address) and use Python f-strings or string concatenation to build your SQL query, you are leaving your servers wide open to SQL Injection (SQLi).

The Vulnerability

Imagine your code is: query = f"SELECT * FROM users WHERE email = '{user_input}';"

If a hacker types admin@site.com'; DELETE FROM users; -- as their email, your string becomes:

SELECT * FROM users WHERE email = 'admin@site.com'; DELETE FROM users; --';

Your database will happily execute both commands, and your startup is dead.

The Shield: Parameterization.

To fix this, we never mix executable SQL code with user data. We send the SQL string and the user data to the database in two completely separate packages.

Safe Parameterized Query (Python asyncpg)

# The SQL string uses placeholders ($1, $2)
safe_query = "SELECT * FROM users WHERE email = $1;"

# The data is passed as a separate argument.
# Postgres treats the variable STRICTLY as text. It will never execute it.
await conn.fetchrow(safe_query, hacker_input)

3. Triggers: The Invisible Enforcers

Sometimes, application-level logic is too slow or too prone to human error. A Database Trigger is a piece of code that lives physically inside the database. It listens for a specific event (like an INSERT or UPDATE) and automatically executes logic before or after the event happens.

The Real-World Implementation

We don't do theory without proof. The complete Python asyncpg engine for today—featuring relational schemas, secure parameterization, and automated audit triggers—is available in the official repository.

🐙 View the Advanced Postgres Engine on GitHub

Primary Use Cases for Triggers

1. The Audit Log: In financial tech, if a user's bank balance changes, you must legally log it. Instead of hoping junior developers remember to insert a log entry in their Python code, you write a Trigger. Every time an UPDATE hits the accounts table, the Trigger automatically copies the OLD.balance and NEW.balance into an immutable audit_logs table.
2. Auto-Updating Timestamps: Unlike MySQL, Postgres does not automatically update an updated_at column when a row is modified. You must attach a BEFORE UPDATE trigger that sets NEW.updated_at = NOW();.
3. Complex Constraints: If you need to ensure a user's withdrawal amount doesn't exceed their daily limit, a Trigger can run the math across three tables and block the transaction entirely.

Triggers are incredibly powerful, .........
READ MORE AT : https://logicandlegacy.blogspot.com/2026/04/the-database-arsenal-relationships.html

Architectural Consulting

If you are building a data-intensive AI application and require a Senior Engineer to architect your secure, high-concurrency backend, I am available for direct contracting.

Explore Enterprise Engagements →

Essential SEO Tips for Digital Marketing in 2026

Leadraft Media — Tue, 28 Apr 2026 14:39:35 +0000

With 2026 on the horizon, it’s crucial to adopt effective SEO strategies that will set your digital marketing efforts apart. This year, prioritize mobile optimization and local SEO to cater to a growing mobile audience. Incorporate AI tools to enhance content creation and keyword research. Additionally, ensuring your website is optimized for speed can significantly affect your search rankings. For an in-depth look at these strategies and more, check out our full guide on 10 proven SEO tips for 2026 here.

One Screenshot Is Sometimes Better Than a Screen Recording

pBinder — Tue, 28 Apr 2026 14:33:34 +0000

I kept running into the same small workflow problem.

Whenever I needed to explain a browser process, report a UI bug, or document a quick internal step-by-step flow, the routine was usually the same: take a screenshot, open an image editor, draw arrows, add step numbers, export the image, and then send it.

None of that is especially difficult, but it adds friction when the goal is just to explain something quickly.

So I built a small Chrome extension called ClickTrek.

ClickTrek records the clicks you make on the current page after starting it, then turns them into a single annotated PNG with numbered markers and arrows.

The Problem I Wanted to Solve

There are already many good tools for documentation, screenshots, and screen recording. Loom, Scribe, Tango, Snagit, CleanShot, and similar tools are useful for full walkthroughs, polished docs, or more detailed editing.

But I wanted something narrower.

Sometimes a video or hosted walkthrough is more than I need. I just want one image that clearly shows:

Click here.
Then click here.
Then click here.

That specific use case is what ClickTrek is focused on.

How It Works

ClickTrek is designed for quick browser workflow documentation.

It currently handles:

recording clicks on the current page
adding numbered step markers
drawing arrows between steps
undoing accidental clicks
showing a preview before export
downloading the final result as a PNG

The output is a single image you can drop into a bug report, GitHub issue, Slack message, internal wiki, tutorial, or handoff note.

Why I Kept It Simple And Local

The first version is intentionally small. I wanted the flow to be easy to understand: open it, start recording, click through the workflow, preview, and export.

There is no account setup, no cloud upload, and no hosted workspace.

ClickTrek runs locally in the browser. It captures the visible page to generate the PNG, and the final export is saved through the browser download flow.

One important note: anything visible on the page can appear in the exported image, so the preview step matters. You should review the image before sharing it.

ClickTrek is not trying to replace full documentation platforms or screen recording tools. It is meant for the smaller moments where a quick annotated image is enough.

Current Limitations And What Might Come Next

The main limitation right now is that ClickTrek only supports single-page workflows.

If you navigate away to another page, the current capture ends. Since many real workflows span multiple pages, this is one of the biggest things I am thinking about for future versions.

Other features I am considering:

multi-page workflow capture
blur or redaction tools for sensitive data
PDF and Markdown export
copy-to-clipboard export
custom marker colors and styles

I am still figuring out which of these would add the most value without making the tool feel heavy.

Try It

ClickTrek is available on the Chrome Web Store:

Get ClickTrek on the Chrome Web Store

I would be interested to hear how people currently document quick browser workflows for bug reports, tutorials, internal docs, or handoff notes.

JavaScript DOM

Anees Abdul — Tue, 28 Apr 2026 14:31:59 +0000

DOM stands for Document Object Model.
Document can be any file(HTML, XML), object can be Tags and Elements (h1 and p) And the model is the layout of the structure

What is HTML DOM:

The HTML DOM is a standard object model and programming interface for HTML
It defines:
- The HTML elements as objects and the properties of all HTML elements, and also the methods to access the elements.
In simple words, it is a standard for how to get, change, add, or delete HTML elements

Why is DOM needed:

Using this, we can change the HTML elements, attributes, and CSS styles in the page
We can add/remove existing HTML elements and attributes
React to events from HTML elements

How to select Elements:
-Selecting HTML elements using JavaScript so we can interact with them.

There are several ways to find elements:

Finding Elements by id
Finding Elements by tag name
Finding Elements by class name
Finding Elements by css selectors
Finding Elements by HTML object collections

1. Find Elements by id:

If the element is found, the method will return the element as an object(in Element)
If the element is not found then it will contain null

<h1 id="title">Hello World</h1>
let el = document.getElementById("title");
console.log(el.innerText);//Hello World

2. Find Elements by TagName:

<h1 id="title">Hello World</h1>
<p>First</p>
<p>Second</p>
<script>
const eleByTag=document.getElementsByTagName("p");
console.log(eleByTag[0].innerText);/First
</script>

3. Find Elements by ClassName:

<h1 id="title">Hello World</h1>
<p class="one">First</p>
<p class="two">Second</p>
<script>
const eleByTag=document.getElementsByClassName("two");
console.log(eleByTag[0].innerText);//Second
</script>

4. Find Elements by CSS selectors:

CSS selectors allow us to access DOM elements using querySelector and querySelectorAll by specifying id, class, tag, or more complex patterns.

What is querySelector():

It will return the first matching Element

<p class="text">Hello</p>
<p class="text">World</p>

let el = document.querySelector(".text");
console.log(el.innerText);/ return only the first match and second is ignored

If you want to select all matching elements then go for querySelectorAll()

What is querySelectorAll():

It will return the all matching elements(Node List)
If you want to access one element at a time then mention the index

   <p class="one">First</p>
   <p class="two">Second</p>
   <p class="two">Third</p>
<script>
const selector=document.querySelectorAll(".two")
console.log(selector[1].innerText);/Third
    </script>

You can also Loop through all when using querySelectorAll()

   <p class="one">First</p>
   <p class="two">Second</p>
   <p class="two">Third</p>

<script>
const selector=document.querySelectorAll(".two")
for(let i=0;i<selector.length;i++){
    console.log(selector[i].innerText);//Second,Third
} </script>

5. Find Elemnts using Collections(HTML collection/NodeList):

-It will return multiple elements so use getElementsBy

When multiple elements are returned, we must iterate through the collection using loops or forEach to access individual elements.

   <p class="one">First</p>
   <p class="two">Second</p>
   <p class="two">Third</p>

<script>
const selector=document.querySelectorAll(".two")
for(let i=0;i<selector.length;i++){
    console.log(selector[1].innerText);//Third
}
</script>

How to Change Elements:

The HTML DOM allows JavaScript to change both the text and the content of HTML elements.

1. Change the content of an

element:

   <h1 id="title">Hello World</h1>
<script>
const Ele=document.getElementById("title").innerText="Changed Element";
console.log(Ele)//Changed Element
    </script>

2. Changing the attribute:

<img id="img" src="old.png">
let img = document.getElementById("img");
img.setAttribute("src", "new.png");//new.png

3. Changing CSS style:

   <h1 id="title">Hello World</h1>
<script>
const Ele=document.getElementById("title");
Ele.style.color="red";
Ele.style.fontSize="20px";
Ele.style.backgroundColor="Blue"
</script>

How to create elements:

The createElement() method creates an element node.

<p>Old content:</p>

<script>
// Create element:
const para = document.createElement("p");
para.innerText = "changed paragraph";
// Append to body:
document.body.appendChild(para);
</script>
O/P: Testing Paragraph:
     changed Paragraph

How to remove Elements:

The remove() method removes an element (or node) from the document.

element.remove()

How to setAttribute():

-setAttribute() is used to add or update an HTML attribute of an element

<button id="btn">Click Me</button>
let btn = document.getElementById("btn");
btn.setAttribute("type", "submit");

X Banned Me During My Product Hunt Launch. Then Medium Saved Me.

Aritomo Fukuda — Tue, 28 Apr 2026 14:30:22 +0000

Twelve days ago, I launched OriginBrief on Product Hunt.

The launch went live, the comments started rolling in, and I did what any indie founder would do — I replied. To every single one.

Around 15 replies. Maybe 1–2 hours. Six of them included a link to my product.

That was apparently a crime.

The Suspension

The next morning, my @aritomofukuda account was frozen. No warning. No explanation. Just gone.

I filed an appeal. Crickets. I waited. Eleven days passed.

Eleven days during the most critical post-launch window — when comments need replies, when potential users have questions, when the algorithm starts deciding if you matter.

X’s spam detection had decided I was a bot. Because I replied to people too quickly. Because I shared my own product more than once. Because the engineers at X apparently can’t tell the difference between a startup founder and a spammer.

The Numbers Don’t Lie

Let me show you what I actually did:

Total tweets that day: ~15
Tweets containing a link: 6 (5 replies + 1 launch announcement)
Pace: roughly one every 6–15 minutes
Time window: 1–2 hours
Links pointed to: my own product (not a phishing site, not a sketchy affiliate, not a competitor’s page)

I’m a human being. I had just shipped something. I was excited. I was reaching out to my community on a launch day.

And X decided that was indistinguishable from spam.

What I Lost

For 11 days, I lost:

The ability to reply to my Product Hunt commenters
Connection with the indie hackers community I’d been building relationships in
Real-time growth signals that X provides during a launch
A meaningful portion of my expected post-launch reach

For an indie founder running on zero budget, that’s not a small loss. That’s the entire short-term growth lever, gone.

Download the Medium App

The Plot Twist

Here’s where it gets interesting.

Because X was dead, I had to do something I’d been avoiding: write longer-form content. So I started posting on Medium. Not every day, but consistently. Six articles in twelve days, mostly about the unglamorous reality of solo SaaS launches.

This week, I got my first “Read” — meaning someone actually read one of my articles to the end, not just clicked.

Today, the editorial team of Startup Stash sent me a private note. They have nearly 1,000 followers on Medium. They invited me to write for them.

Twelve days ago, I depended on X.

Today, I have a publication invitation and a relationship with editors who care about the work — not algorithms.

The Lesson

It’s not that X is evil. It’s that X is a platform you don’t control.

Their spam detection is a black box. Their appeal system is a void. Their support, post-Musk, has effectively stopped existing for individual creators. You can spend years building a following, and one day, an algorithm flips a bit and you’re gone.

The only sustainable channels for indie founders are the ones you own:

Your domain
Your email list
Your content on platforms that have functioning editorial relationships

Medium isn’t perfect. But when an editor at Startup Stash decides your work fits their audience, that’s a relationship — not a coin flip.

What I’m Doing Now

Still posting on Medium, now with publication amplification
Running the SEO content engine on my SaaS that auto-generates weekly reports (the original reason I built OriginBrief)
Leaving X to recover or not — at this point, it’s optional

If you’re building in public and X is your primary channel, please understand: you’re one false-positive away from losing it all. Build owned channels in parallel. Right now. Before you need them.

I learned this the hard way over the last 11 days.

Maybe this saves you from learning it the same way.

— -

I’m Aritomo, a 25-year engineer trying to figure out marketing as a solo founder. I’m building four SaaS products: StandupFlow, QuietLog, DocDecay, and OriginBrief. This is the kind of stuff I write about — usually with disclaimers about how little I know.

Disclaimer: I might be reading too much into 11 days of bad luck. Maybe X will unfreeze me tomorrow. Maybe Startup Stash will publish my piece and 3 people will read it. The point isn’t that I’m now successful — it’s that I’m no longer dependent on a single platform. That alone is worth the 11 days.