Forem: Bruno Corrêa

JavaScript Countdown Gotcha: Why Date.now() Depends on the User’s Clock

Bruno Corrêa — Wed, 24 Sep 2025 13:21:10 +0000

TL;DR

Date.now() uses the user’s system clock, not the server’s.
If the user’s device time is wrong, your countdown timers will be wrong too.
Always treat the server as the source of truth for time-sensitive flows.

Backstory: A Payment Timer Gone Wrong

While integrating Nubank’s NuPay system, I built a simple countdown timer: 10 minutes (600 seconds) before the payment link expired. Straightforward, right?

Fetch the order, grab the insertedAt timestamp, and compare it with Date.now().

Except my timer kept showing 11:50 minutes instead of 10:00.

The Gotcha: `Date.now()` Uses the Client Clock

After double-checking my math, I tried something unusual: I manually changed my system clock.

Suddenly the timer shifted.

That’s when I realized:

Date.now() isn’t based on server time. It’s based on the user’s system clock.

If the system time is off — even by a couple of minutes — your timer drifts. On payments, that’s a dealbreaker.

How I Fixed It

Store a local timestamp on checkout

   localStorage.setItem(`nupay_order_${orderId}`, Date.now().toString())

This works reliably on the same device.

Use it on the confirmation page
Compare the stored value to Date.now() to calculate remaining time.
Fallback to server data
If the local key doesn’t exist (e.g. user switches devices), use the backend’s insertedAt.

Cross-Device Reality Check

What if a user checks out on their laptop but views the order on their phone?

LocalStorage works only on the same device.
Server timestamps cover cross-device cases.
Best practice: have the backend return its current time along with insertedAt so you can calculate relative to the server clock.

Polling the Order Status

To keep the order status fresh, I used polling (every 5 seconds):

Simpler than WebSockets/SSE
Stateless, reliable, easy to retry
Perfect for a short-lived, critical flow like payments

async function pollOrderStatus(orderId: number, timeout: number, signal: AbortSignal) {
  const startTime = Date.now()
  const interval = 5000

  while (true) {
    // stop polling if request was aborted or max timeout exceeded
    if (signal.aborted || Date.now() - startTime > timeout) break

    const { data } = await client.query({
      query: GetOrder,
      variables: { orderId },
      fetchPolicy: 'no-cache'
    })

    // Checks if order status has changed to paid/failed/canceled/etc
    if (data?.order?.status !== 'pending') {
      window.location.reload()
      break
    }

    await new Promise(r => setTimeout(r, interval))
  }
}

Key Lesson: Don’t Trust the Client Clock

Date.now() is only as correct as the user’s system settings.
Clocks can drift minutes or hours.
Cross-device usage makes things worse.

Always prefer:

Server timestamps as the source of truth
Local storage as a same-device helper
Small tolerances where exactness isn’t critical

Visualizing the Flow

User Checkout → Order Created (10 min timeout) → Store local timestamp
     ↓
Confirmation Page → Calculate Remaining Time → Show Countdown
     ↓
Start Polling (5s intervals) → Check Order Status → Update UI
     ↓
Status Change → Reload Page → Final State (Real-time feedback for user)

Conclusion

Most of us take Date.now() for granted, but in time-sensitive apps like payments, it can quietly undermine your logic.

Next time you build a countdown, remember:

The client clock is not gospel. The server is your source of truth.

References

Let’s Connect

I share real-world problem-solving and debugging lessons:
GitHub | LinkedIn | Portfolio

[Boost]

Bruno Corrêa — Mon, 10 Feb 2025 11:57:43 +0000

Handling Complex File Upload forms

Bruno Corrêa ・ Feb 9

#webdev #react #nextjs #tutorial

Handling Complex File Upload forms

Bruno Corrêa — Sun, 09 Feb 2025 16:17:49 +0000

Picture this: You're working on a mature React application with forms that have evolved over years. Nested objects, array fields, complex validation and maybe even some legacy code. Then comes the requirement:

"We need to add file uploads to this form."

Your first thought? "Easy, just use FormData and multipart uploads!"

But then you open the form component and see something this:

// The existing form structure that gives you nightmares
const { control, handleSubmit } = useForm<{
  project: {
    name: string;
    collaborators: Array<{
      email: string;
      permissions: string[];
    }>;
    timeline: {
      start: Date;
      milestones: Array<{
        title: string;
        description: string;
      }>;
    };
  };
  // ...and 20 more fields
}>();

Suddenly, converting everything to FormData feels like impossible and just not ideal. Let me show you how we tackled this without rewriting our entire form (and backend!).

The Problem of File Uploads

Our requirements were:

✅ Maintain the existing complex JSON structure

✅ Add multiple file uploads

✅ Single API request (no race conditions!)

✅ No massive refactoring

The Obvious (But Flawed) Solution: Two Separate Requests

Submitting form data first, then uploading files separately seemed logical.

But:

❌ What if the form submission succeeds but file upload fails?

❌ How do we handle partial failures?

❌ Double the API surface = double the maintenance

We needed a way to send everything in one payload. Here's what we built.

Approach 1: The Straightforward FormData Method

Best for: Simple forms, quick implementations

Let's start with the solution you wish you could use.

Simple Upload Component

// app/components/simple-upload.tsx
"use client";

export default function SimpleUploadForm() {
  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();

    const formData = new FormData();
    files.forEach((file) => formData.append("files", file));

    const res = await fetch("/api/simple-upload", {
      method: "POST",
      body: formData, // No Content-Type header!
    });
  };

  return (
    <Card>
      <CardContent>
        <form onSubmit={handleSubmit}>
          <Input type="file" multiple />
          <Button type="submit">Upload</Button>
        </form>
      </CardContent>
    </Card>
  );
}

API Route

// app/api/simple-upload/route.ts
export async function POST(request: NextRequest) {
  const formData = await request.formData();
  const files = formData.getAll("files") as File[];

  files.forEach(async (file) => {
    const bytes = await file.arrayBuffer();
    const buffer = Buffer.from(bytes);
    // Write to filesystem or S3
  });

  return NextResponse.json({ success: true });
}

✅ Why this works:

Native browser support
Streams files directly
No size conversion overhead

❌ Why it failed us:

Our existing form wasn't compatible with FormData
Converting nested objects to flat key-value pairs would require:
- Frontend restructuring
- Backend parameter re-mapping
- Breaking changes for mobile clients

Approach 2: The JSON Base64 Shuffle

Best for: Keeping complex JSON structures intact

Instead of breaking our form, we converted files to Base64 and embedded them in JSON. So the flow will be:

Frontend will encode it and send to backend.
Backend will then decode it and be able to treat it (Save to an S3 bucket, save to database, whatever.).

Complex Upload Component

// app/components/complex-upload.tsx
"use client";

const onSubmit: SubmitHandler<FormInputs> = async (data) => {
  const files = await Promise.all(
    Array.from(data.files).map(async (file) => {
      const base64 = await readFileAsBase64(file);
      return {
        name: file.name,
        type: file.type,
        size: file.size,
        base64: base64.split(",")[1], // Strip metadata
      };
    })
  );

  const payload = {
    user: data.user,
    attachments: files,
  };

  await fetch("/api/complex-upload", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(payload),
  });
};

// FileReader Helper Function
const readFileAsBase64 = (file: File) => {
  return new Promise<string>((resolve) => {
    const reader = new FileReader();
    reader.onload = (e) => resolve(e.target?.result as string);
    reader.readAsDataURL(file);
  });
};

API Route

// app/api/complex-upload/route.ts
export async function POST(request: NextRequest) {
  const { user, attachments } = await request.json();

  attachments.forEach((file) => {
    const buffer = Buffer.from(file.base64, "base64");
    fs.writeFileSync(`./uploads/${file.name}`, buffer);
  });

  return NextResponse.json({ 
    user,
    uploadedFiles: attachments.map(f => f.name)
  });
}

✅ Why this works:

Existing structure maintained: No need to flatten nested objects
Single request: Everything succeeds or fails together
Backend agnostic: Works with REST, GraphQL, or even tRPC

Lessons

1. React Hook Form Quirks

When using useForm with file inputs, handle the FileList manually:

{...register("files", { 
  validate: (files) => files?.length > 0 || "Required"
})}

2. Memory Management

Converting 100MB files to base64?

🚨 Your users' browsers will cry.

We added:

if (file.size > 10 * 1024 * 1024) {
  throw new Error("File too big");
}

3. Backend Security Checks

Never trust incoming base64. Validate MIME types properly:

// Validate MIME type from actual content
import fileType from 'file-type';

const buffer = Buffer.from(file.base64, 'base64');
const type = await fileType.fromBuffer(buffer);

if (!type?.mime.startsWith('image/')) {
  throw new Error('Invalid file type');
}

When to Choose Which Approach?

Feature	FormData	JSON + Base64
Payload Structure	Flat key-value	Complex nested JSON
File Size	Better for large files	Keep under 10MB
Browser Support	Universal	Modern browsers
Existing API Surface	Needs modification	Works as-is

Try It Yourself

My complete example repo shows both approaches side-by-side with both the frontend and backend ready to go in one app:

Vercel deploy

git clone https://github.com/brinobruno/file-upload-poc-next
cd file-upload-poc-next

follow README.md

✅ The demo includes:

Side-by-side form comparison
Error handling implementations
File size validation
UI feedback states

Parting Thoughts

This solution helped us ship file uploads without regressing existing functionality.

Is it perfect? No. But in complex codebases, pragmatic solutions often win over theoretical best practices.

🚀 Coming soon: Implementing this pattern in Elixir Phoenix, as I'm learning this framework myself.

👉 What file upload challenges have you faced? Drop your thoughts in the comments!

References

here are some authoritative sources and references you could explore for deeper insights:

WebSockets And SSE Documentation:

MDN Web Docs: File
MDN Web Docs: FormData
MDN Web Docs: Base64

Let's connect

I'll share my relevant socials in case you want to connect:
Github
LinkedIn
Portfolio

Real-Time Web Communication: Long/Short Polling, WebSockets, and SSE Explained + Next.js code

Bruno Corrêa — Mon, 23 Sep 2024 12:24:25 +0000

Backstory: The Unexpected Interview Question

A few months ago, I was in the middle of a technical interview for a mid-level front-end position. Things were going smoothly until I was hit with a question that caught me slightly off guard.

"Imagine you need a form of constant communication to check something every second until you retrieve something you need.

For example, you want to keep checking if a payment has been successful, like in an e-commerce setup. How would you approach this?"

I responded cautiously, “I think you could implement WebSockets to handle that.”

The interviewer smiled. "That’s a good solution, but there are other, arguably better, options depending on the situation."

And that’s when we dove into a conversation about various approaches to real-time communication, including Long Polling, Short Polling, WebSockets, and finally, Server-Sent Events (SSE), which is arguably the best choice for a unidirectional data stream, like in our payment example.

We also discussed choosing the right database for handling these constant, yet lightweight requests without draining server resources. In that context, Redis came up, known for its simplicity and efficiency in managing these types of requests.

This conversation stuck with me. I realized that while WebSockets get a lot of attention, there’s a wide array of techniques that, when understood, can optimize the way we manage real-time communication. Today, I want to break down these four approaches, when to use each, and their pros and cons in a clear, engaging way. By the end, you’ll have a solid understanding of why Server-Sent Events (SSE) often shine for one-way, real-time communication.

Before I begin, huge thanks to Marcos, the experienced Senior Software Engineer who conducted that chat and inspired me to write this article months later, which I much appreciated even though I didn't get the job! :)

The Four Methods of Real-Time Communication

Before jumping into the SSE example, let’s break down the four methods we discussed during that interview:

1. Short Polling

Short polling is probably the simplest method. It involves making a request to the server at regular intervals, asking, “Do you have new data?” The server responds with the current state—whether or not there’s anything new.

Upside:

Easy to implement
Works with traditional HTTP requests

Downside:

It’s resource-heavy. You’re making frequent requests, even when no new data is available.
Can increase server load and network traffic, which becomes inefficient for frequent checks like payment status updates.

Best for: Small, low-frequency data updates, such as a stock market price to update every minute or so.

2. Long Polling

Long polling takes short polling a step further. The client repeatedly requests information from the server, but instead of the server responding right away, it holds onto the connection until new data is available. Once data is sent back, the client immediately opens a new connection and repeats the process.

Upside:

More efficient than short polling because the server only responds when necessary - it's really fast.
Compatible with browsers and HTTP/HTTPS protocols.

Downside:

Still requires reopening connections repeatedly, leading to inefficiency over time - expensive resources.
Slightly more complex than short polling.

Best for: Situations where real-time communication is needed but WebSockets/SSE might be overkill (e.g., chat applications).

3. WebSockets

WebSockets are a more modern solution that provides full-duplex communication between client and server. Once a connection is opened, both sides can send data freely without re-establishing connections - which defines a bidirectional communication.

Upside:

True real-time communication with minimal latency.
Great for bi-directional communication (e.g., real-time games, chat apps).

Downside:

More complex to implement than polling or SSE.
WebSockets aren’t always ideal for one-way communication or less frequent updates, as they can consume resources by maintaining open connections.
May need firewall configuration.

Best for: Applications requiring constant two-way communication, like multiplayer games, collaborative tools, chat applications, or real-time notifications.

4. Server-Sent Events (SSE)

Finally, we come to Server-Sent Events (SSE), the hero of our payment example. SSE creates a one-way connection where the server sends updates to the client. Unlike WebSockets, this is unidirectional—the client doesn’t send data back.

Upside:

Ideal for one-way data streams like news feeds, stock tickers, or payment status updates.
Lightweight and simpler to implement than WebSockets.
Uses the existing HTTP connection, so it’s well-supported and firewall-friendly.

Downside:

Not suitable for bi-directional communication.
Some browsers (particularly older versions of IE) don’t fully support SSE.

Best for: Real-time updates where the client only needs to receive data, such as live scores, notifications, and our payment status example.

SSE in Action: Real-Time Payment Status with Next.js

Let’s get to the heart of the matter. I built a simple Next.js app to simulate a real-time payment process using Server-Sent Events (SSE). It demonstrates exactly how you can set up one-way communication to check the status of a payment and notify the user when the payment succeeds or fails.

It's a bit of a headache to set it up for Next since it works a bit differently than plain js so you can thank me later!

Here’s the setup:

Frontend: Transaction Control Component

In the following component, we have a simple UI displaying buttons to simulate different types of transactions that would come from an actual gateway API (Pix, Stripe, and a failing credit card payment). These buttons trigger real-time payment status updates through SSE.

Here’s where the SSE magic happens. When a payment is simulated, the client opens an SSE connection to listen for updates from the server. It handles different statuses like pending, in transit, paid, and failed.

"use client";

import { useState } from "react";
import { PAYMENT_STATUSES } from "../utils/payment-statuses";

const paymentButtons = [
  {
    id: "pix",
    label: "Simulate payment with Pix",
    bg: "bg-green-200",
    success: true,
  },
  {
    id: "stripe",
    label: "Simulate payment with Stripe",
    bg: "bg-blue-200",
    success: true,
  },
  {
    id: "credit",
    label: "Simulate failing payment",
    bg: "bg-red-200",
    success: false,
  },
];

type transaction = {
  type: string;
  amount: number;
  success: boolean;
};

const DOMAIN_URL = process.env.NEXT_PUBLIC_DOMAIN_URL;

export function TransactionControl() {
  const [status, setStatus] = useState<string>("");
  const [isProcessing, setIsProcessing] = useState<boolean>(false);

  async function handleTransaction({ type, amount, success }: transaction) {
    setIsProcessing(true);
    setStatus("Payment is in progress...");

    const eventSource = new EventSource(
      `${DOMAIN_URL}/payment?type=${type}&amount=${amount}&success=${success}`
    );

    eventSource.onmessage = (e) => {
      const data = JSON.parse(e.data);
      const { status } = data;

      console.log(data);

      switch (status) {
        case PAYMENT_STATUSES.PENDING:
          setStatus("Payment is in progress...");
          break;
        case PAYMENT_STATUSES.IN_TRANSIT:
          setStatus("Payment is in transit...");
          break;
        case PAYMENT_STATUSES.PAID:
          setIsProcessing(false);
          setStatus("Payment completed!");
          eventSource.close();
          break;
        case PAYMENT_STATUSES.CANCELED:
          setIsProcessing(false);
          setStatus("Payment failed!");
          eventSource.close();
          break;
        default:
          setStatus("");
          setIsProcessing(false);
          eventSource.close();
          break;
      }
    };
  }

  return (
    <div>
      <div className="flex flex-col gap-3">
        {paymentButtons.map(({ id, label, bg, success }) => (
          <button
            key={id}
            className={`${bg} text-background rounded-full font-medium py-2 px-4
            disabled:brightness-50 disabled:opacity-50`}
            onClick={() =>
              handleTransaction({ type: id, amount: 101, success })
            }
            disabled={isProcessing}
          >
            {label}
          </button>
        ))}
      </div>

      {status && <div className="mt-4 text-lg font-medium">{status}</div>}
    </div>
  );
}

Backend: SSE Implementation in Next.js

On the server side, we simulate a payment process by sending periodic status updates through SSE. As the transaction progresses, the client will receive updates on whether the payment is still pending, has been completed, or has failed.

import { NextRequest, NextResponse } from "next/server";

import { PAYMENT_STATUSES } from "../utils/payment-statuses";

export const runtime = "edge";
export const dynamic = "force-dynamic";

// eslint-disable-next-line @typescript-eslint/no-unused-vars
export async function GET(req: NextRequest, res: NextResponse) {
  const { searchParams } = new URL(req.url as string);
  const type = searchParams.get("type") || null;
  const amount = parseFloat(searchParams.get("amount") || "0");
  const success = searchParams.get("success") === "true";

  if (!type || amount < 0) {
    return new Response(JSON.stringify({ error: "invalid transaction" }), {
      status: 400,
      headers: {
        "Content-Type": "application/json",
      },
    });
  }
  const responseStream = new TransformStream();
  const writer = responseStream.writable.getWriter();
  const encoder = new TextEncoder();
  let closed = false;

  function sendStatus(status: string) {
    writer.write(
      encoder.encode(`data: ${JSON.stringify({ status, type, amount })}\n\n`)
    );
  }

  // Payment gateway simulation
  async function processTransaction() {
    sendStatus(PAYMENT_STATUSES.PENDING);

    function simulateSuccess() {
      setTimeout(() => {
        if (!closed) {
          sendStatus(PAYMENT_STATUSES.IN_TRANSIT);
        }
      }, 3000);

      setTimeout(() => {
        if (!closed) {
          sendStatus(PAYMENT_STATUSES.PAID);

          // Close the stream and mark closed to prevent further writes
          writer.close();
          closed = true;
        }
      }, 6000);
    }

    function simulateFailure() {
      setTimeout(() => {
        if (!closed) {
          sendStatus(PAYMENT_STATUSES.CANCELED);

          // Close the stream and mark closed to prevent further writes
          writer.close();
          closed = true;
        }
      }, 3000);
    }

    if (success === false) {
      simulateFailure();
      return;
    }

    simulateSuccess();
  }

  await processTransaction();

  // Return the SSE response
  return new Response(responseStream.readable, {
    headers: {
      "Access-Control-Allow-Origin": "*",
      Connection: "keep-alive",
      "X-Accel-Buffering": "no",
      "Content-Type": "text/event-stream; charset=utf-8",
      "Cache-Control": "no-cache, no-transform",
      "Content-Encoding": "none",
    },
  });
}

Also, make sure you add .env.local file with this content:

NEXT_PUBLIC_DOMAIN_URL='http://localhost:3000'

Why SSE Over WebSockets in This Case?

Now that we’ve seen how to implement it, you might be wondering: why use SSE over WebSockets for this? Here’s why:

Unidirectional Communication: In our scenario, the client only needs to receive updates about the payment status. There’s no need for the client to send data back to the server constantly, so the simplicity of SSE fits perfectly.
Lightweight: Since SSE uses a single HTTP connection to stream updates, it’s more resource-efficient compared to WebSockets, which maintain full-duplex communication.
Firewall-Friendly: SSE is easier to work with across different network environments because it runs over HTTP, which is usually open in firewalls, whereas WebSocket connections can sometimes run into issues.
Browser Support: While not as widely supported as WebSockets, SSE is supported by modern browsers, making it reliable for most use cases where unidirectional data is needed.

Conclusion: Know Your Tools

That interview question turned into an incredible learning experience, opening my eyes to the subtle differences between long polling, short polling, WebSockets, and SSE. Each method has its time and place, and understanding when to use which one is crucial for optimizing real-time communication.

SSE might not be as glamorous as WebSockets, but when it comes to efficient, one-way communication, it's the perfect tool for the job—just like in our e-commerce payment example. Next time you're building something that requires real-time updates, don’t just reach for WebSockets by default—consider SSE for its simplicity and efficiency.

Hope this deep dive into real-time communication techniques keeps you sharp for your next project or that tricky interview question!

Let's get our hands dirty

Next.js + TypeScript example repository: https://github.com/brinobruno/sse-next
Next.js + TypeScript example deployment: https://sse-next-one.vercel.app/

References

here are some authoritative sources and references you could explore for deeper insights:

WebSockets And SSE Documentation:

MDN Web Docs: The WebSockets API
MDN Web Docs: Using Server Sent Events

Next API Routes

Next.js: API Routes

Let's connect

I'll share my relevant socials in case you want to connect:
Github
LinkedIn
Portfolio

How to Use Shadow DOM and Honeypots to Deter Crawlers

Bruno Corrêa — Mon, 16 Sep 2024 21:18:53 +0000

This is a short introduction and demonstration on how we can increase security on forms, especially against crawling, it's noticeable that it's most likely overkill for most applications but very interesting for those who want to understand a bit more about such practices as and how it's possible to undermine them.

Disclaimer: This post was inspired by Felippe Regazio, on a late-night coding stream, make sure to give him a follow. Huge thanks. Also, I'm not a senior dev, so please feel free to double-check any information you believe I could've misstated so that we can correct/improve it together.

Next.js + TypeScript implementation app:

For any purposes, you can refer to this repo to check out the application I made to learn and demonstrate the following concepts, You can also just as easily make this with HTML, CSS, and JavaScript, since there were less examples on React, I've decided to build one approach of it here.

Also, feel free to try and hack it too, I've made a deployment available here.

Understanding Web Crawlers

Web crawlers, also known as bots or spiders, are automated programs designed to browse the internet and gather data. They're essential for search engines like Google, but they can also be used for more malicious purposes, like scraping sensitive information or submitting spam through forms. Crawlers often utilize JavaScript methods like document.querySelectorAll() or document.forms to identify and interact with elements, such as form fields, by their name attributes.

Most crawlers look for predictable patterns, such as:

input[name="name"]
input[name="email"]
input[type="submit"]

The Risks of Crawling

While crawling itself isn't inherently bad, when malicious bots target your site, it can result in spam form submissions, scraping sensitive data, or even overloading your server with requests. That's where Shadow DOM and honeypots come into play as security measures.

What is Shadow DOM?

The Shadow DOM is a part of the Web Components standard that allows for the encapsulation of DOM trees. Essentially, elements in a Shadow DOM tree are isolated from the rest of the document, preventing external scripts (like those from crawlers) from easily accessing them.

Another common use for Shadow DOM is when you have any service app that a website can embed into their platform and you want to make sure that any important information won't be able to be changed, such as what an input title represents, or even a copyright statement such as "Powered by my-app-name", which is pretty common on e-commerce apps for Shopify, WordPress, amongst others.

Pros of Using Shadow DOM for Forms:

Encapsulation: Elements within the Shadow DOM are not accessible by global selectors such as document.querySelectorAll. Crawlers won't be able to easily find or interact with these elements.
Style isolation: CSS and JavaScript scoped to a Shadow DOM will not leak into the main document, and vice versa. This makes the UI more secure from unintended changes or external interference. And of course, that can also be a downside from other perspectives.

Downsides:

Limited accessibility: Shadow DOM can make elements harder to access for legitimate purposes, such as custom analytics or third-party tools.
Potential developer complexity: You need to carefully manage interactions between Shadow DOM and the rest of your site to avoid conflicts, especially when debugging.

Using Shadow DOM to Hide Forms

By placing a form inside the Shadow DOM, bots attempting to use document.forms or document.querySelectorAll will not be able to access it. Here’s an example of encapsulating a form using Shadow DOM:

const ShadowForm: React.FC = () => {
  const formRef = useRef<HTMLDivElement>(null);
  const shadowRootRef = useRef<ShadowRoot | null>(null);

  useEffect(() => {
    if (formRef.current && !shadowRootRef.current) {
      shadowRootRef.current = formRef.current.attachShadow({ mode: "closed" });

      const form = document.createElement("form");
      form.noValidate = true;
      form.innerHTML = `
        <input type="text" name="name" aria-hidden>
        <!-- Regular form fields here -->
      `;

      shadowRootRef.current.appendChild(form);
    }
  }, []);

  return <div ref={formRef}></div>;
};

In this example, the form fields, including an anti-crawler honeypot field (name="name"), are encapsulated in the Shadow DOM, preventing external scripts from accessing or interacting with the form.

The Honeypot Technique

A honeypot is a hidden field added to a form, which humans can’t see but bots might fill out. If the field is filled, it indicates a likely bot interaction, and you can prevent the form submission.

In this case, the field is hidden both visually (via aria-hidden) and through its encapsulation in the Shadow DOM:

const FIELD = {
  HONEYPOT: "name",
  NAME: "%",
  EMAIL: "@",
  PASSWORD: "$",
  CONFIRM_PASSWORD: "C",
};

export function handleFormSubmission(formData: FormData, showError: (id: string, message: string) => void) {
  if (formData.get(FIELD.HONEYPOT)) {
    // Prevent submission
    return;
  }

  // Continue with validation...
}

Here, FIELD.HONEYPOT represents a field that bots may fill in. If the field is filled, the form submission is blocked, preventing spam submissions.

Using Special Characters in Input Names

Many crawlers rely on identifying common field names such as name, email, and password. By using unconventional names like @, %, or $, you make it harder for crawlers to identify key fields.

const inputConfigs = [
  { name: "%", type: "text", placeholder: "Name" },
  { name: "@", type: "email", placeholder: "Email" },
  { name: "$", type: "password", placeholder: "Password" },
  { name: "C", type: "password", placeholder: "Confirm Password" },
];

Using non-standard input names reduces the likelihood of bots correctly filling in form fields, while still being fully functional for human users.

Why This Might Be Overkill for Most Sites

While combining Shadow DOM with honeypots and unconventional input names can improve security against automated form submissions, this level of defense is generally more suitable for high-risk environments. Many websites don’t need to go to these lengths because simpler anti-bot solutions, like CAPTCHAs or rate-limiting, are often effective.

Potential Side Effects

SEO Implications: Because elements inside Shadow DOM are hidden from the rest of the document, some search engines might not be able to index your content properly.
User Experience: Over-complicating the form submission process might frustrate legitimate users or make the form inaccessible to certain browsers or assistive technologies.

Conclusion

Using the Shadow DOM, honeypots, and unconventional input names offers a robust, albeit niche, security approach to fend off form-submitting bots. These methods hide form fields from common crawling techniques and add extra layers of protection to ensure your forms are only submitted by humans. However, it’s important to weigh the benefits against the potential downsides and determine if this approach is truly necessary for your site.

Let's get our hands dirty

Next.js + TypeScript example repository: https://github.com/brinobruno/shadow-dom-react-next
Next.js + TypeScript example deployment: https://shadow-dom-react-next.vercel.app/

References

here are some authoritative sources and references you could explore for deeper insights:

Let's connect

I'll share my relevant socials in case you want to connect:
Github
LinkedIn
Portfolio

Forem: Bruno Corrêa

JavaScript Countdown Gotcha: Why Date.now() Depends on the User’s Clock

TL;DR

Backstory: A Payment Timer Gone Wrong

The Gotcha: Date.now() Uses the Client Clock

How I Fixed It

Cross-Device Reality Check

Polling the Order Status

Key Lesson: Don’t Trust the Client Clock

Visualizing the Flow

Conclusion

References

Let’s Connect

[Boost]

Handling Complex File Upload forms

Bruno Corrêa ・ Feb 9

Handling Complex File Upload forms

The Problem of File Uploads

The Obvious (But Flawed) Solution: Two Separate Requests

Approach 1: The Straightforward FormData Method

Simple Upload Component

API Route

Approach 2: The JSON Base64 Shuffle

Complex Upload Component

API Route

Lessons

1. React Hook Form Quirks

2. Memory Management

3. Backend Security Checks

When to Choose Which Approach?

Try It Yourself

Parting Thoughts

References

WebSockets And SSE Documentation:

Let's connect

Real-Time Web Communication: Long/Short Polling, WebSockets, and SSE Explained + Next.js code

Backstory: The Unexpected Interview Question

The Four Methods of Real-Time Communication

1. Short Polling

2. Long Polling

3. WebSockets

4. Server-Sent Events (SSE)

SSE in Action: Real-Time Payment Status with Next.js

Frontend: Transaction Control Component

Backend: SSE Implementation in Next.js

Why SSE Over WebSockets in This Case?

Conclusion: Know Your Tools

Let's get our hands dirty

References

WebSockets And SSE Documentation:

Next API Routes

Let's connect

How to Use Shadow DOM and Honeypots to Deter Crawlers

Next.js + TypeScript implementation app:

Understanding Web Crawlers

The Risks of Crawling

What is Shadow DOM?

Pros of Using Shadow DOM for Forms:

Downsides:

Using Shadow DOM to Hide Forms

The Honeypot Technique

Using Special Characters in Input Names

Why This Might Be Overkill for Most Sites

Potential Side Effects

Conclusion

Let's get our hands dirty

References

Shadow DOM Documentation:

FormData and XMLHttpRequest:

Honeypot Technique:

Cross-Site Request Forgery (CSRF):

Let's connect

The Gotcha: `Date.now()` Uses the Client Clock