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! :)
Before jumping into the SSE example, let’s break down the four methods we discussed during that interview:
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:
Downside:
Best for: Small, low-frequency data updates, such as a stock market price to update every minute or so.
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:
Downside:
Best for: Situations where real-time communication is needed but WebSockets/SSE might be overkill (e.g., chat applications).
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:
Downside:
Best for: Applications requiring constant two-way communication, like multiplayer games, collaborative tools, chat applications, or real-time notifications.
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:
Downside:
Best for: Real-time updates where the client only needs to receive data, such as live scores, notifications, and our payment status example.
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:
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>
);
}
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'
Now that we’ve seen how to implement it, you might be wondering: why use SSE over WebSockets for this? Here’s why:
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!
Next.js + TypeScript example repository: https://github.com/brinobruno/sse-next
Next.js + TypeScript example deployment: https://sse-next-one.vercel.app/
here are some authoritative sources and references you could explore for deeper insights:
MDN Web Docs: The WebSockets API
MDN Web Docs: Using Server Sent Events
Next.js: API Routes
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的详细内容。更多信息请关注PHP中文网其他相关文章！
