DEV Community: Hassan Aziz

WebSockets tutorial: how they work and when to use them

Hassan Aziz — Sat, 24 Oct 2026 08:13:59 +0000

The short version

A WebSocket is a connection that stays open between the browser and the server, so either side can send a message at any time.
HTTP is request and response: the server can only answer when the client asks. WebSockets are events, and neither side has to reply.
A WebSocket starts as an HTTP request with an Upgrade header, and the same connection then carries WebSocket messages.
Use WebSockets when the server has to push updates without being asked, like chat messages or progress from a long-running job. Keep HTTP for everything else.
Use wss:// rather than ws://, and pick it from the page's own protocol so the same code works locally and in production.

A WebSocket is a connection between a browser and a server that stays open, so either side can send a message whenever it wants. Plain HTTP can't do that. With HTTP the server only ever answers requests, so if the client doesn't ask, the server has no way to tell it anything.

That one difference decides when you need WebSockets. Below I go through how HTTP works, how WebSockets work, when to pick each one, and then a small working demo with a Flask server and plain JavaScript in the browser. The video above covers the same ground if you'd rather watch.

How HTTP works: the client asks, the server answers

Every website you visit runs on HTTP. It's a request-response protocol. Your browser (the client) sends a request to the server for index.html, the server sends back the HTML, and the browser renders the page. Then the browser asks for the site's icon, and the server sends the icon back.

Every exchange starts with the client. If the browser never asks for the icon, the server never sends it, because there's no request to respond to. For loading pages and calling most APIs, that's exactly what you want.

The problem HTTP can't solve

Say you're building a messaging app like WhatsApp or Discord. Other people send messages to the server all the time, and your browser has to show them as they arrive. But your browser doesn't know when a new message has landed, so it doesn't know when to ask.

The usual workaround is polling: the browser asks "anything new?" every few seconds. Most of those requests come back empty, and a message can still sit on the server for a few seconds before the next poll picks it up. It works, but it's the wrong shape for the problem. What you want is for the server to say "here's a new message" the moment it has one.

How WebSockets work: events in both directions

A WebSocket starts life as an HTTP request. The browser sends a normal request with an Upgrade: websocket header, the server answers with 101 Switching Protocols, and from then on that same connection stays open and carries WebSocket messages instead of HTTP. That's why people describe WebSockets as an upgrade of HTTP.

After the upgrade, the model is completely different. HTTP is request and response. WebSockets are events. The client can send an event and the server can respond, or the server can send an event and the client can respond, and neither side has to respond at all. Replying is good practice, but nothing in the protocol requires it.

So a real conversation over a WebSocket can look like this: the server sends an event, the client says nothing back, the server sends another one, the client sends one of its own, and then the server sends two more. No request ever has to come first.

WebSocket vs HTTP

	HTTP	WebSocket
Who can start an exchange	Only the client	Either side
Connection	A request, then a response	Stays open until one side closes it
Does every message need a reply?	Yes, every request gets a response	No, a reply is optional
URL scheme	`http://` and `https://`	`ws://` and `wss://`
Good for	Pages and most APIs	Chat, games, live updates, notifications

Use WebSockets when the server has to push something to the client without being asked. Keep HTTP for everything else. They aren't competitors, and most real apps use both: HTTP to load the page and fetch data, and one WebSocket for the live parts.

When to use WebSockets

These are the cases where I'd reach for them:

A messaging app, where new messages have to show up the moment someone sends them.
A multiplayer game, where every player needs to see what the others do many times a second, and sends their own moves up the same connection.
A long-running job on the server. It can send an update to the browser as each step finishes, and the user watches it happen instead of refreshing.
A shared document or whiteboard, where everyone sees each other's edits as they type.

If only the server ever needs to talk, Server-Sent Events are a simpler option worth a look, since they run over plain HTTP. If neither side needs to push anything, you don't need either one.

Build a WebSocket server in Flask

Here's a minimal app to see all of this working. The server sends random events to the browser on its own schedule, and whenever the browser sends a message, the server replies with "Message received".

I'm using Python with Flask and the Flask-Sock extension, and plain JavaScript in the browser with no libraries. Most people will be on Node.js, and that's fine: the server has the same shape in any language, and the browser code is identical.

Install the two packages:

pip install flask flask-sock

The project has three files:

websockets-demo/
├── app.py
├── templates/
│   └── index.html
└── static/
    └── index.js

Here's the server, app.py:


from flask import Flask, render_template
from flask_sock import Sock
from simple_websocket import ConnectionClosed

app = Flask(__name__)
sock = Sock(app)

EVENTS = [
    "New order received",
    "User signed up",
    "Report finished generating",
    "Payment processed",
    "Backup completed",
]

@app.route("/")
def index():
    return render_template("index.html")

@sock.route("/ws")
def websocket(ws):
    # Two threads send on this socket, so they take turns
    send_lock = threading.Lock()

    def send(message):
        with send_lock:
            ws.send(message)

    def background_sender():
        while ws.connected:
            time.sleep(random.uniform(1, 3))
            try:
                send(random.choice(EVENTS))
            except ConnectionClosed:
                break

    threading.Thread(target=background_sender, daemon=True).start()

    # receive() blocks until the client sends something, and raises
    # ConnectionClosed when it leaves, which Flask-Sock handles for us
    while True:
        data = ws.receive()
        send(f"Message received: {data}")

if __name__ == "__main__":
    app.run(debug=True)

The / route is plain HTTP. It renders the page, and that's all it does.

The /ws route is the WebSocket. Flask-Sock handles the upgrade handshake and hands the function a ws object for that one client. The function then does two jobs at once:

It starts a background thread running background_sender, which sends a random event from the list every one to three seconds, for as long as the client stays connected. This is the part HTTP can't do: the server talks without being asked.
It sits in a loop waiting for the client. Every time a message arrives, it sends back "Message received" with the text.

Both of those send on the same socket from different threads, so they share a lock and never write at the same moment. When the browser tab closes, receive() raises ConnectionClosed, Flask-Sock cleans up, and the background thread stops within a few seconds.

The browser side: the native WebSocket API

Browsers have WebSockets built in, so the client needs no library. The page itself is a text box plus a list the messages go into. Here's templates/index.html:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>WebSockets demo</title>
</head>
<body>
  <p>Status: <strong id="status">Connecting...</strong></p>
  <form id="form">
    <input id="message" placeholder="Say something" autocomplete="off">
    <button>Send</button>
  </form>
  <ul id="log"></ul>
  <script src="{{ url_for('static', filename='index.js') }}"></script>
</body>
</html>

And static/index.js, which is where the WebSocket lives:

// Same rule as http and https: use the secure wss:// when the page itself is on https
const scheme = location.protocol === "https:" ? "wss:" : "ws:";
const socket = new WebSocket(`${scheme}//${location.host}/ws`);

const statusText = document.getElementById("status");
const log = document.getElementById("log");

function addLine(text) {
  const item = document.createElement("li");
  item.textContent = text;
  log.append(item);
}

socket.addEventListener("open", () => {
  statusText.textContent = "Connected";
});

socket.addEventListener("message", (event) => {
  addLine(`Server: ${event.data}`);
});

socket.addEventListener("close", () => {
  statusText.textContent = "Disconnected";
});

socket.addEventListener("error", () => {
  addLine("The connection had an error");
});

document.getElementById("form").addEventListener("submit", (event) => {
  event.preventDefault();
  const input = document.getElementById("message");
  if (socket.readyState === WebSocket.OPEN && input.value) {
    socket.send(input.value);
    addLine(`You: ${input.value}`);
    input.value = "";
  }
});

The first two lines pick the URL. The difference between ws:// and wss:// is the same as the difference between http:// and https://: one is encrypted and the other isn't. Use the secure one. Deriving it from the page's own protocol means the same code works on your laptop over http and in production over https. Browsers also block a plain ws:// connection from a page served over https, so getting this wrong breaks the app in production.

The rest is event handlers. open fires when the connection is up, message fires for every event the server sends, close fires when either side ends the connection, and error fires when something goes wrong. socket.send() is how the browser sends its own events, and the form calls it when you press Send.

Run it

From the project folder:

flask --app app run

Open http://127.0.0.1:5000. The status switches to "Connected", and within a few seconds events start appearing in the list, without you sending anything. Type "hello" and press Send, and the server answers with "Message received: hello" in between its own events.

Watch the list for a minute and you'll see the server keep talking to the browser without a single request from it.

Learn how it works, and let AI write the syntax

I didn't spend long on the code in the video, and I'd do the same here. Everyone uses a different stack, and AI writes most of the code for us now anyway. Ask any AI tool for "a WebSocket server in Express" and you'll get something close to the Flask code above in a few seconds.

What AI can't do for you is decide whether you need a WebSocket in the first place. That takes knowing how the protocols work under the hood: HTTP only answers, a WebSocket lets either side speak, and each one fits different problems. WebSockets aren't better than HTTP, and you shouldn't use them everywhere. When the client and server need to talk in real time without waiting on requests and responses, that's where they're the right tool.

Originally published on hassandev.me.

How I score Reddit job posts for scams with an LLM

Hassan Aziz — Fri, 23 Oct 2026 10:15:44 +0000

If you've ever looked for freelance work on Reddit, you know how it goes. You open r/forhire or r/slavelabour, sort by New, and start scrolling. The first post is someone advertising their logo design services. The next one asks whether Upwork is dead. Then there's another freelancer's portfolio, and after that a "job" that wants you to message them on Telegram about an exciting opportunity in crypto.

The real jobs are in there, buried, and some of the ones you find aren't real either.

So I built Only Hiring. It reads every new post from 18 job subreddits and lists only the ones where someone is paying for work, on one page you can scan in a couple of minutes. Each job gets a short summary and a scam score from 0 to 1, and the pay is pulled out into numbers so you can sort by it.

This is how the LLM side of it works, with the prompt rules that mattered most.

How many of the posts are jobs

Here's what the 712 posts the pipeline has read so far turned out to be:

What the post was	Posts	Share
Hiring	311	44%
A question or discussion	208	29%
Someone advertising their own services	111	16%
Spam or promotion	53	7%
Unpaid "collaboration"	13	2%
Something else	16	2%

Those 712 are what's left after skipping every post tagged [For Hire] or [Offer], which never reach the model at all. Even after that, fewer than half are jobs.

Some subreddits are much worse than others. On r/softwareengineerjobs, 14 of the 147 posts I read were hiring. That's under 10%, and most of the rest were career questions. r/RemoteJobs and r/developerjobs weren't much better. On subreddits that enforce their tags, like r/forhire and r/DesignJobs, nearly every post that's left is a real job.

The pipeline

It's a small Python pipeline that runs on my machine:

scrape new posts ──> skip [For Hire] tags ──> LLM grades each post ──> clean the output
                                                                            │
website <── Postgres <── publish jobs only <── drop reposts and deleted posts

The website is Next.js on Vercel, and it only ever reads from the database.

Step 1: Don't send everything to the model

The cheapest filter is one that doesn't need an LLM. Most job subreddits make people tag their posts, so anything tagged [For Hire], [Offer] or Hire Me is skipped before it's even fetched. On r/forhire, a regex gets rid of most of the subreddit.

Everything else goes to the model, because tags don't catch the rest. People tag their own services as [Hiring] to get more views, and some "hiring" posts turn out to be course sales or questions.

Step 2: One prompt, one JSON object

Each post goes to an LLM (I use DeepSeek) with a single prompt. The model decides what kind of post it is and, if it's a job, pulls out everything useful:

{
  "is_job_post": true,
  "post_type": "hiring_job_offer",
  "job_title": "Video Editor",
  "summary": "...",
  "role_category": "video_animation",
  "seniority": null,
  "employment_type": "freelance_project",
  "pay_type": "per_unit",
  "pay_min": 25,
  "pay_max": 40,
  "pay_currency": "USD",
  "pay_raw": "$25-40 per video",
  "work_mode": "remote",
  "location": null,
  "skills": ["Premiere Pro", "After Effects"],
  "apply_method": "reddit_dm",
  "scam_score": 0.1,
  "red_flags": [],
  "reasoning": "A client offering paid editing work per video."
}

The rule I care most about for extraction is this one, copied from the prompt:

If a detail is not stated, set it to null. Missing information is expected and fine; a wrong value is much worse than null.

LLMs love to fill gaps. If a post doesn't say whether the work is remote, a model will often guess "remote" because most Reddit jobs are. That guess then shows up on the site as a fact, and someone filters by it. So only three fields may be inferred: the job title, the summary and the role category. Every other field has to come from the post itself. Every key is required too, so the model has to write null explicitly instead of leaving a field out.

Pay gets the most rules, because it's the field people care about most and it's the messiest. The model first copies the shortest exact bit of the post that states the pay ("$20-25/hr"), then splits it into a type, a min, a max and a currency. Keeping the raw excerpt means I can always check the parsed numbers against what the post said. "Competitive salary" or a bare [PAID] tag keeps its excerpt but gets no numbers.

Step 3: Scoring scams

I spent more time on this part than any other. The prompt has a scoring guide with three bands:

0.0-0.2: identifiable employer or concrete project, specific deliverables, realistic pay.
0.3-0.5: vague work and no details, commission-only with no clear product,
         pay that seems off for the work.
0.6-1.0: classic scam or exploitation signs, such as: upfront fees or paid "training";
         crypto or forex trading and "investment" schemes; contact only through
         Telegram/WhatsApp; requests for ID, bank or personal details; renting or
         "borrowing" someone's LinkedIn/Upwork/bank account; reshipping or payment
         processing; MLM; unpaid "test" tasks that are real work; very high pay for
         trivial work.

The list that made the biggest difference is the opposite one, the things that are not red flags:

Normal on Reddit and NOT warning signs on their own: applying by Reddit DM or comment,
an individual client who gives no company name, pay not stated, payment in crypto,
and job requirements such as location, age, language or equipment.

Without it, a model that has absorbed generic "how to spot a job scam" advice flags half of Reddit. Real clients on r/slavelabour are anonymous individuals who want a DM and don't name a company, because they don't have one. Advice written for LinkedIn treats that as suspicious, and on Reddit it's how most hiring works. So the score has to measure how unusual a post is for Reddit specifically.

The model also has to list each warning sign it found in red_flags. The site shows them next to the warning, so you can see why a post was flagged and decide for yourself. "Scam score: 0.7" on its own tells you very little, while "Telegram-only contact" and "unpaid sample before the go-ahead" tell you what to look out for.

On the site, a score of 0.4 or more gets a visible warning, and 0.6 or more hides the post unless you choose to see likely scams.

Step 4: Never trust the JSON

Even with a strict format, model output is untrusted input. Every response goes through a sanitiser before it's stored:

Unknown keys are dropped, and enum values that aren't on the list become null.
Strings like "N/A", "null", "unknown" and "not specified" become real nulls.
Numbers are parsed ("1,500" becomes 1500), and negative pay is thrown away.
If pay_min is bigger than pay_max, they're swapped.
If the post isn't a job, every job field is cleared, whatever the model said.
Currency codes have to be three letters.

None of it is clever, but without it, bad values leak through to the filters. It's the same rule I follow in client work: check an AI step's output in code before anything else uses it.

Step 5: Reposts and deleted posts

Hiring posts get crossposted to three subreddits at once, or reposted every few days to bump them. A post counts as a duplicate when the same author posts near-identical text (90% similar or more, using Python's difflib). The copy reuses the first one's grade instead of going through the model again, and only the newest copy is published.

Posts also disappear. Authors delete them once the job's filled, and Reddit's spam filters remove others. Every run asks Reddit which of the last 14 days' jobs are gone and takes those off the site. On one day, 24 of the 221 jobs from the previous two weeks had already gone.

What the scores found

I expected the scam scores to catch a lot of scams. They mostly didn't, because there aren't many. Of the 311 hiring posts, 40 got a warning (13%), and only 6 scored high enough to be hidden.

What I found much more often was exploitation: real jobs on bad terms. These are some of the red flags the model wrote down:

"unpaid sample clip requested before go-ahead"
"payment only after all 30 clips are approved"
"full usage rights granted for a $30 bulk set"
"very low pay for live screen-share work"
"unpaid substantive rewriting assessment"
"WhatsApp-only contact"

Most of these jobs are real. They pay very little, or want a lot of free work first, which is why I think the red flags matter more than the score: "payment only after all 30 clips are approved" tells you exactly what you'd be agreeing to. The guide to Reddit job scams breaks it down by subreddit.

An LLM writing tic I didn't expect

The first version of the prompt asked for a summary of "what the work is and who it suits". The model took the second half literally. At one point 65% of the summaries had the word "suit" in them, and 44% had a sentence starting "It suits...". A page of jobs read like a page of horoscopes.

The fix was to ban stock phrases in the prompt ("It suits...", "ideal for", "great opportunity", "Seeking a...") and ask for the most useful specific detail instead, like the deliverables or the timeline. Re-grading every listed job took the summaries mentioning "suit" from 171 to 1.

If you're generating text for lots of similar items, read twenty of them in a row. A tic you'd never spot in one output is obvious in a list.

What you get on the site

All that extracted data is what makes the board quick to scan. Every job from the 18 subreddits is in one list, newest first. You can filter by role (19 categories, from video editing to data and AI), by experience level, by remote, hybrid or on-site, and by how it pays: hourly, fixed price, per piece, monthly and so on. Sorting by highest pay only works because pay is parsed into numbers. One tick hides commission-only jobs, and search covers titles, skills, locations and subreddits.

Scam warnings show their reasons, and likely scams are hidden by default. You can mark jobs you've applied to, then hide them or see only those. That works without an account, and signing in keeps the list across devices. There's also an RSS feed of new jobs, and a page for each subreddit with what it pays and how many of its posts are real jobs.

You still apply on Reddit. Every job links to the original post, and the site only keeps a summary and the post's opening lines.

What it gets wrong

The model makes mistakes. Sometimes it misses a red flag or misreads a pay figure, and now and then it flags something harmless. So the site says so and links every job to its source, and the footer tells you to read the original post before you reply to anyone. Treat a scam score as a hint and make the call yourself.

Some fields are often empty because the posts don't say. Only about one job in five states a seniority level, for example, so the experience filter has a "Not stated" option. I'd rather show that than guess.

Try it

It's free, with no sign-up needed: onlyhiring.hassandev.me. The website's code is on GitHub under the MIT licence.

If you know a subreddit with real job posts that I'm not reading, or you find a post it got wrong, let me know in the comments.