Real-Time Email Notifications

The Polling Problem

Most temporary email services check for new messages using polling. Your browser sends a request to the server every few seconds to ask if there are any new emails. The server checks the inbox. It responds to your browser. Then your browser waits and asks again. This creates a noticeable delay. You might wait anywhere from 5 to 30 seconds depending on how often the browser checks.

From a user perspective, this delay is painful. You have just submitted a signup form and you're staring at an empty inbox waiting for the verification email. You don't know if the email hasn't arrived yet or if it's being delayed or if something went wrong. You start clicking the refresh button. This action sometimes resets the polling timer and makes the wait even longer.

Some services try to hide this with a "Checking for new emails..." animation. The real problem is still there because there is a delay between the email arriving at the server and your browser finding out it is there.

Polling wastes bandwidth and server resources. Every polling request is a full HTTP round-trip even when there are no new messages. If you multiply that by thousands of concurrent users polling every 5 seconds you create a heavy load on the server doing nothing useful. Some services have slow or inconsistent performance because of this. Their systems spend more time answering "no new mail" than actually processing emails.

How Real-Time Delivery Works

NukeMail uses Supabase Realtime. This is a system based on WebSockets that keeps a persistent connection between your browser and the database. When a new email arrives in the messages table, Supabase pushes a notification through the WebSocket to every client connected and subscribed to that specific inbox.

The practical result is that emails arrive in your inbox one or two seconds after they hit the mail server. You don't need a polling interval, a refresh button or any manual checking. The email just shows up, usually before you have finished switching tabs back to NukeMail.

The connection is lightweight. A single WebSocket uses minimal bandwidth and battery compared to repeated HTTP polling requests. If the connection drops because of a network blip or your laptop sleeping, it automatically reconnects when the page becomes active again.

Why This Matters for Verification Emails

Most people use temporary email to grab verification codes and confirmation links. These links are time-sensitive. Some codes expire in 5 or 10 minutes. A temp email service with a 15-second polling interval wastes 15 seconds of that window on every single attempt.

Real-time delivery means your verification email shows up the moment the sending service dispatches it. You can click the link or copy the code right away without waiting around. For services that send a code and then start a countdown timer, the difference between instant delivery and a 15-second delay matters.

This is important for two-factor authentication because you're usually looking at a login form on one screen and your temp email on another. The code appears quickly so the whole process feels fast. Real-time delivery makes temporary email feel just like using your real email inbox.

Visual Feedback

NukeMail displays a pulsing indicator when your inbox is actively listening for new emails. This confirms that the real-time connection is working. You know the system is ready to show you emails the moment they arrive.

When a new email arrives, it appears in the list with a brief fade-in animation. This is the only animation in the interface. Everything else is static and immediate. The animation has a functional purpose because it draws your eye to the new entry so you don't miss it if you have looked away from the screen.

There are no desktop notifications, sound effects or popup alerts. The email simply appears in the list. If you are on the page you see it. If you're not on the page it will be there when you return. This keeps the experience focused and non-intrusive.

The visual feedback design shows the NukeMail philosophy of being functional instead of flashy. The pulsing dot isn't an animated loading spinner built to entertain you. It is a status indicator that communicates system state. The fade-in on new emails isn't a decorative transition. It prevents you from missing a new entry in the list. Every visual element has a specific purpose.

Technical Reliability

Real-time systems are more complex than simple polling. The trade-off is worth it for your experience. NukeMail handles common failure modes. If the WebSocket connection drops, the client attempts to reconnect automatically. If the reconnection fails, it shows a Connection lost indicator so you know to refresh manually.

The real-time subscription is limited to your specific inbox so you only get notifications for emails sent to you. The server doesn't broadcast every email to every connected client. Each connection is filtered at the database level to show only your address IDs.

Haraka runs on the server to process incoming email and insert it into the database. Supabase sees that insertion and pushes a notification through the Realtime channel. The full pipeline from SMTP receipt to browser display usually takes 1-3 seconds. Haraka parsing the email content accounts for most of that time.