Stop Defaulting to WebSockets: A Practical Guide to SSE, Polling, and Knowing When You Actually Need Them

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 1038036) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } AttractivePenguin Posted on Apr 28 Stop Defaulting to WebSockets: A Practical Guide to SSE, Polling, and Knowing When You Actually Need Them #webdev #javascript #node #tutorial Stop Defaulting to WebSockets: A Practical Guide to SSE, Polling, and Knowing When You Actually Need Them You've been there. A ticket lands in your sprint: "Make the dashboard real-time." Your brain immediately jumps to WebSockets. Open a persistent connection, push data to the client, done — right? Not so fast. In my experience (and the experience of plenty of devs who've debugged WebSocket auth issues at 2 AM), WebSockets are overkill for most "real-time" features. Notifications, live feeds, progress bars — these are one-way pushes from server to client. You don't need a two-way persistent connection for that. This article gives you a practical decision framework and working code for the three main approaches — WebSockets, Server-Sent Events (SSE), and polling — so you can stop reaching for the heaviest tool and start picking the right one. The One Question That Decides Everything Before you write a single line of code, answer this: Does the client need to send data back to the server through the same connection? No → You probably don't need WebSockets. SSE or polling will do. Yes, and it's frequent/continuous → WebSockets are the right call. That's it. That's the framework. Let me show you why, with code. Approach 1: Polling — The Underrated Workhorse Polling gets a bad reputation. Developers treat it like the "amateur" option you eventually graduate away from. But for a lot of features, it's genuinely the best choice. When to Use Polling Updates every 30 seconds or more are acceptable You have few concurrent users checking the same resource You want maximum simplicity and debuggability Your data changes infrequently (e.g., a job status that updates every minute) The Code Client-side, it's laughably simple: async function checkJobStatus(jobId) { const res = await fetch(`/api/jobs/${jobId}/status`); const { status, progress } = await res.json(); updateProgressBar(progress); return status; } // Poll every 15 seconds until the job is done const intervalId = setInterval(async () => { const status = await checkJobStatus('job_123'); if (status === 'completed' || status === 'failed') { clearInterval(intervalId); } }, 15_000); Enter fullscreen mode Exit fullscreen mode Server-side is just a regular endpoint: // Express.js app.get('/api/jobs/:id/status', async (req, res) => { const job = await JobRepository.findById(req.params.id); res.json({ status: job.status, progress: job.progress }); }); Enter fullscreen mode Exit fullscreen mode Why It Works Zero persistent connections — the server doesn't hold state between requests Auth is trivial — regular HTTP, cookies and headers just work Debugging is easy — open the Network tab, see the requests, done Works everywhere — no browser compatibility concerns, no proxy issues The Drawback If you need sub-second updates or have thousands of clients hammering the same endpoint, polling wastes resources. That's where SSE shines. Approach 2: Server-Sent Events — The Sweet Spot SSE is the tool most developers overlook. It…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.