DEV Community: David Jesse Odhiambo

Full-Stack Interview Prep #2: XSS (Cross-Site Scripting) Explained Simply (with Go & Node.js Examples)

David Jesse Odhiambo — Tue, 02 Sep 2025 16:32:55 +0000

You’re in a technical interview. The interviewer leans back and asks:
“How would you protect a web app from Cross-Site Scripting (XSS)?”

For a moment, your mind races. You know XSS is common, but how do you explain it clearly under pressure?

Let’s break it down with a simple example: imagine a user comment box on a blog. Instead of leaving normal feedback, an attacker types:

<script>alert('hacked')</script>

If the site displays that comment without filtering or escaping it, the attacker’s code will run in the browser of anyone who visits the page. What should have been a friendly comment section just became a tool for stealing sessions, hijacking accounts, or tricking users into clicking malicious links.

That’s Cross-Site Scripting in a nutshell: when untrusted input makes its way into a webpage, and browsers treat it as executable code instead of harmless text.

Why does this matter? Because XSS is still listed in the OWASP Top 10 — which means that even after two decades, it continues to affect real-world applications. From social media platforms to e-commerce sites, XSS has caused data leaks, account takeovers, and reputational damage for companies that overlooked secure coding practices.

What is XSS? (Explained Simply)

Think of XSS like this: imagine a suggestion box at a store. Customers drop in notes with feedback. Most are normal, like “Great service!” But one prankster slips in a fake note that says “Read this out loud and embarrass yourself.” The staff reads it, not realizing it’s a trick.

That’s what Cross-Site Scripting does — only instead of words, the “fake note” is malicious code, and the victim is every user’s browser.

A Plain-English Example

Imagine a blog with a comment section. A normal user writes:

Great article, thanks for sharing!

But an attacker posts: <script>alert('hacked')</script>

If the site displays that input without escaping it, the browser doesn’t see it as a comment. It sees it as code to run. The result? Every visitor who loads that page gets an unexpected popup — or worse, the attacker could steal cookies, hijack accounts, or inject fake login forms.

The Flow of an XSS Attack

Here’s the basic lifecycle of how XSS sneaks in:

Attacker Input → Saved in Database → Rendered in HTML → Browser Executes Script

At first glance, it looks like harmless text. But once it reaches the browser, the line between “data” and “code” becomes indistinguishable.

Types of XSS (Quick Overview)

There are three common flavors of XSS:

Stored XSS → malicious input is saved in the database (e.g., a comment or profile field).
Reflected XSS → the malicious input comes from a URL or form, and the server reflects it back in the response.
DOM-based XSS → the attack happens entirely in the browser when client-side JavaScript inserts untrusted input into the page.

Don’t worry if these terms feel new — we’ll use simple code examples in the next section to make them concrete.

XSS in Practice (Bad Examples)

So far we’ve talked about XSS in theory — now let’s see what it looks like in real code.

Imagine we’re building a simple comment feature for a website. A user types something, we save it, and then we display it back on the page. Straightforward, right? But if we’re not careful, this is exactly where XSS slips in.

❌ Go Example (Vulnerable Template Rendering)

In Go, if we use the text/template package or print raw input without escaping, we risk injecting user input directly into the HTML:

package main

import (
    "fmt"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    comment := r.URL.Query().Get("comment")
    // ❌ Vulnerable: directly writing unescaped input to the response
    fmt.Fprintf(w, "<h1>User Comment:</h1> %s", comment)
}

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)
}

Now if an attacker visits:

http://localhost:8080/?comment=<script>alert('XSS')</script>

Instead of displaying harmless text, the browser executes the <script> tag, and everyone sees an alert box pop up.

❌ Node.js Example (Express App Rendering Input Directly)

The same issue happens in Node.js if we inject user input straight into the HTML without escaping:

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  const comment = req.query.comment;
  // ❌ Vulnerable: directly embedding user input in HTML
  res.send(`<h1>User Comment:</h1> ${comment}`);
});

app.listen(3000, () => console.log('Server running on http://localhost:3000'));

If someone visits:

http://localhost:3000/?comment=<script>alert('XSS')</script>

Boom — the browser pops up the alert box again. What should have been “just text” was treated as code.

The Key Takeaway: This is a simple example of how XSS works in practice. As we saw earlier, it can appear as stored, reflected, or DOM-based attacks — the form changes, but the root cause is always the same: untrusted input being injected into a page without proper handling.

How to Prevent XSS (Best Practices)

Now that we’ve seen how XSS sneaks into your program, let’s focus on defense. The good news is: protecting against XSS doesn’t require magic — just discipline and the right tools.

Think of prevention as layers of defense: some fixes are essential, others add extra safety nets. Together, they make your app resilient.

1. Output Encoding / Escaping

The golden rule: never trust user input when rendering it back to a page. Instead, escape it so the browser treats it as text, not code.

🚨 Vulnerable vs. ✅ Safe (Quick Comparison)

Sometimes, the fix is just one small change — but it makes all the difference.

In Golang

// ❌ Vulnerable: text/template does NOT escape input
import "text/template"

// ✅ Safe: html/template auto-escapes <script> and other dangerous tags
import "html/template"

In Node.js → if you use template engines like EJS, Pug, or Handlebars, they escape output by default.

// ❌ Vulnerable: raw string interpolation, user input becomes HTML
res.send(`<h1>User Comment:</h1> ${comment}`);

// ✅ Safe: use a template engine (EJS, Pug, Handlebars)
// Escaping happens by default
res.render('index', { comment });

Interview Tip: Be ready to explain that secure defaults (like Go’s html/template or Express template engines) are your best defense. Interviewers love to hear that you understand both the why and the how.

2. Use Security Libraries

Sometimes you do want to allow limited HTML (like bold or italic tags in a blog comment). In that case, use a sanitization library that strips dangerous tags and attributes.

Node.js → DOMPurify is a battle-tested option (often used with server-side rendering).

Go → packages like bluemonday provide configurable sanitizers.

3. Content Security Policy (CSP)

CSP is like a seatbelt: it won’t prevent an accident, but it can reduce the damage. By setting a CSP header, you can tell browsers to only run scripts from trusted sources.

Example header:

Content-Security-Policy: script-src 'self'

This means: only run JavaScript that comes from my own site, not from injected code.

4. Input Validation (Secondary Layer)

Validation alone won’t stop XSS (attackers can always craft clever payloads), but it can reduce noise. For example:

Reject inputs that are clearly invalid for the field (like a birthdate containing <script>).

Limit length of input to reduce payload size.

Think of this as cleaning the water before it reaches your filters.

5. Principle of Least Privilege

Finally, even if something slips through, you can reduce the impact by limiting what the attacker can do.

Cookies → mark them HttpOnly and Secure, so even if a script runs, it can’t steal them easily.

Database / API access → don’t give your web app more permissions than it needs.

Key Takeaway:
If you remember only one thing:
Always escape untrusted output.

Everything else — sanitization, CSP, validation, least privilege — are extra shields. But escaping is your first and strongest line of defense.

Why Interviewers Ask About XSS

At this point, you might be wondering: why does XSS keep showing up in interviews? It’s not because interviewers enjoy watching developers sweat — it’s because this single vulnerability reveals a lot about how you think as an engineer.

Here’s what they’re really looking for:

1. Do you know client-side vulnerabilities, not just backend ones?

Many developers focus only on the server. But XSS is a reminder that security isn’t just about the database — the browser is part of the attack surface too.

2. Can you explain attack → defense clearly?

It’s one thing to say “XSS is bad.” It’s another to walk through:

how it works (untrusted input becomes code), and
how to fix it (escape output, sanitize input, use CSP). That step-by-step clarity is exactly what interviewers want to hear.

3. How do you handle pressure?

Sometimes the question isn’t asked in a calm, textbook way. Instead, you’ll hear things like:

“What’s the difference between stored and reflected XSS?”
“How would you prevent XSS in your favorite language?”
“Can you give me a real-world consequence of XSS?”

These versions test whether you can stay calm, think out loud, and structure your answer under pressure.

4. Do you understand the real-world impact?

Interviewers want to know if you see beyond code snippets. For example, XSS can:

Steal a user’s session cookies.
Hijack an account.
Inject fake login forms to harvest passwords.
Damage a company’s reputation when users lose trust.

A Simple Answer Framework

Here’s a 3-step structure you can use to answer almost any XSS interview question:

1. Define it simply

> “XSS happens when untrusted input is inserted into a webpage and executed as code in the browser.”

2. Give a quick example

> “For instance, if a site displays alert('hacked') from a comment box without escaping, that code will run for every visitor.”

3. Show how to prevent it

> “The fix is to always escape output (Go’s html/template, Node’s template engines), sanitize inputs, and enforce a Content Security Policy as backup.”

The key takeaway: XSS questions aren’t trivia. They’re a way for interviewers to test your security fundamentals, your ability to reason through problems, and your communication skills under pressure.

Pop Quiz: Test Your Understanding

Before we wrap up, let’s do a quick self-check. These aren’t trick questions — just simple ways to reinforce what you’ve learned. Try answering them in the comments to share your take and help others learn too.

1. Scenario Check

Imagine a blog comment box that doesn’t escape <script> tags. What happens if an attacker submits this as a comment?

<script>alert('hacked')</script>

2. True or False

Input validation alone is enough to completely stop XSS attacks.

3. Fix the Code (Go)

Here’s a vulnerable Go snippet:

fmt.Fprintf(w, "<p>%s</p>", comment)

Rewrite it using a safe approach so that <script> tags are not executed in the browser.

4. Fix the Code (Node.js)

Here’s a similar vulnerable snippet in Node.js (Express):

res.send(`<p>${comment}</p>`);

Rewrite it using a templating engine or escaping function to prevent XSS.

💡 Tip: Don’t worry about being “perfect.” The goal is to practice identifying vulnerable code and thinking of safer alternatives.

Conclusion / Call to Action

Cross-Site Scripting (XSS) is dangerous because it hijacks user trust — but it’s also preventable with a few simple practices. If you remember one rule, let it be this: never trust unescaped user input in your HTML output. Add layers like sanitization, CSP, and cookie protections, and you’ll be ahead of most real-world vulnerabilities.

Key Takeaways

XSS happens when untrusted input is executed as code in the browser.

Output escaping (Go html/template, Node templating engines) is your first line of defense.

Sanitization libraries (like DOMPurify) help when HTML input is unavoidable.

Content Security Policy (CSP) and secure cookie flags (HttpOnly, Secure) provide safety nets.

Your Next Steps

Audit your code for any direct string interpolation into HTML.
Use safe defaults: html/template in Go, EJS/Pug/Handlebars in Node.
Add or tighten a CSP header for your app.
Set cookies with HttpOnly and Secure to limit exposure.

Over to You

Have you ever discovered an XSS issue in your own project — maybe even by accident?

What fixes or defensive tricks have you found most useful? Drop your answers and quiz responses in the comments — let’s learn from each other.

Up Next in the Series

This was Full-Stack Interview Prep #2: XSS Explained Simply (with Go & Node.js Examples), a follow up to #1: SQL Injection Explained Simply.
Stay tuned for #3: CSRF (Cross-Site Request Forgery) Explained Simply with Go & Node.js Examples.

Full-Stack Interview Prep #1: SQL Injection Explained Simply (with Go & Node.js Examples)

David Jesse Odhiambo — Wed, 27 Aug 2025 15:06:54 +0000

You’re in a technical interview. The interviewer looks up from their notes and asks: “How would you protect a login form from SQL injection?” In that moment, your answer isn’t just about passing the interview — it’s about whether you understand one of the web’s most common security threats.

SQL Injection is when an attacker sneaks malicious input into a database query. Imagine a login form where you enter a username and password. Normally, the database should only check if those values exist. But if the code isn’t secure, an attacker could type something like admin' OR '1'='1. The database, confused, runs it as a valid command — and suddenly the attacker is logged in without ever knowing the real password.

More technically, SQL Injection happens when untrusted user input is placed directly inside an SQL query string. This breaks the separation between code and data, allowing attackers to alter the query’s logic — for example, turning a simple credential check into a query that returns every user in the database.

There’s a reason this topic keeps coming up in interviews: it’s not just theory. SQL Injection is still in the OWASP Top 10 after more than two decades, and a single overlooked query has cost companies millions in data breaches and lost trust.

💡 This article is the first in my Full-Stack Interview Prep series, where I break down common interview questions into simple explanations, real-world scenarios, and practical code examples in Go and Node.js. Each part of the series focuses on one core concept — from security topics like SQL Injection, XSS, and CSRF, to backend fundamentals like caching and authentication, and even frontend/system design essentials. My goal is to make these topics easier for developers preparing for interviews, while also showing recruiters how I approach teaching, collaboration, and writing clean, secure code.

What is SQL Injection? (Explained Simply)

Now that we’ve set the stage, let’s break down what SQL Injection really is — step by step, and in plain language.

Think of your SQL query as a conversation with the database. Normally, you ask a simple question like:
“Does a user named John exist with this password?”

But with SQL Injection, an attacker interrupts that conversation and sneaks in their own instructions. Instead of just typing John, they might type:

John' OR '1'='1

That small addition changes the meaning of the query. The database is tricked into thinking the condition is always true — which means the attacker could log in without knowing any real password.

Here’s a simplified SQL example to show what happens behind the scenes:

-- Normal query
SELECT * FROM users WHERE username = 'John' AND password = 'secret';

-- Injected query
SELECT * FROM users WHERE username = 'John' OR '1'='1' AND password = 'secret';

In the injected version, '1'='1' is always true. That makes the whole condition true, and the database happily returns a row — even if the password is wrong.

This is the essence of SQL Injection: when user input isn’t handled safely, it can alter the logic of a database query in dangerous ways.

SQL Injection in Practice (Bad Examples)

Let’s see how SQL Injection sneaks in through everyday code. These examples might look harmless, but they show what happens when user input is inserted directly into a query string.

Vulnerable Example in Go

// ❌ Vulnerable code
query := "SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'"
rows, _ := db.Query(query)

At first glance, this looks like a straightforward way to check if a user exists. But notice how we’re building the query by concatenating strings. That means whatever the user types in username or password gets injected directly into the SQL command.

Now imagine the attacker types this as the username:

admin' OR '1'='1

The query becomes:

SELECT * FROM users WHERE username='admin' OR '1'='1' AND password='whatever';

Since '1'='1' is always true, the database happily returns a row — and the attacker is logged in without knowing a real password.

Vulnerable Example in Node.js

// ❌ Vulnerable code
const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;
db.query(query, (err, result) => {
  if (err) throw err;
  console.log(result);
});

The same issue appears here. By embedding username and password directly in the query string, we’re giving attackers a chance to alter the logic.

If the attacker enters the same payload (admin' OR '1'='1), the query becomes:

SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = 'doesntmatter';

Again, the condition always evaluates to true, so the attacker bypasses authentication.

How to Prevent SQL Injection (Best Practices)

The good news is that SQL Injection is preventable. With a few best practices, you can protect your application — and your users — from this attack. Let’s walk through the most important defenses.

✅ Prepared Statements / Parameterized Queries

SQL Injection prevention starts with using prepared statements, sometimes called parameterized queries. Instead of directly inserting user input into a string, you pass the input as parameters. This keeps data separate from the query logic.

In Go (using database/sql):

// ✅ Safe code using parameters
query := "SELECT * FROM users WHERE username=$1 AND password=$2"
row := db.QueryRow(query, username, password)

Here, $1 and $2 act as placeholders. The database ensures that username and password are treated as values, not code.

In Node.js (using mysql2):

// ✅ Safe code using parameters
const query = "SELECT * FROM users WHERE username = ? AND password = ?";
db.query(query, [username, password], (err, result) => {
  if (err) throw err;
  console.log(result);
});

The ? placeholders ensure the same protection. No matter what an attacker types, it will always be treated as data, never as part of the SQL command.

✅ ORMs & Query Builders

Another way to reduce risk is by using an ORM (Object-Relational Mapper) or query builder. Tools like GORM (Go) or Prisma (Node.js) abstract away SQL and usually handle parameterization for you by default.

Example:

// Prisma in Node.js
const user = await prisma.user.findUnique({
  where: { username: username },
});

ORMs aren’t foolproof, but they help developers write cleaner queries with safer defaults.

✅ Input Validation & Escaping

While prepared statements are your primary shield, it’s also good practice to validate input. For example:

Ensure usernames only contain expected characters (letters, numbers).
Validate that email fields actually look like emails.

This isn’t enough on its own — but combined with parameterization, it makes your app much harder to exploit.

✅ Principle of Least Privilege

Even with secure queries, you should avoid giving your database user more permissions than it needs. For example:

Your application’s database account should not have rights to drop tables or manage users.
Restrict it to just what the app needs: SELECT, INSERT, UPDATE, DELETE.

This way, even if something goes wrong, the damage is limited.

Why Interviewers Ask This Question

So why do interviewers love asking about SQL Injection? It’s not just to check if you’ve memorized a definition. They use this question to see how you think, how you explain, and how you handle pressure.

Here are the main things they’re looking for:

🔹 1. Core Knowledge

Do you understand what SQL Injection is and why it matters? Interviewers want to confirm that you’re aware of common web vulnerabilities and can recognize insecure code when you see it.

🔹 2. Communication Skills

Can you explain the attack and its prevention clearly? Being able to walk through attack → defense in a way others can follow shows that you’re not only a good developer, but also someone who can mentor teammates and document your work.

🔹 3. Handling Pressure

Most interviewers won’t stop at a single question. They’ll push a little further to see if you can stay calm and keep your answers structured. For example, they might ask:

“What’s SQL Injection?”
“Can you give me an example in your favorite language?”
“How would you prevent it in Go/Node?”
“What happens if a company ignores this vulnerability?”

These follow-ups aren’t designed to trick you — they’re a chance to show that you understand the fundamentals and can adapt your answers.

Pop Quiz!

Before we wrap up, here’s a quick quiz to test your understanding. Don’t worry — this isn’t an exam. The goal is to practice, reinforce the concepts, and maybe even teach others by sharing your answers in the comments.

📝 Questions

1. Concept Check
What does the condition OR '1'='1 do when it appears in an SQL query?

2. True or False
Input validation alone is enough to completely prevent SQL Injection.

3.0. Fix the Vulnerable Code (Go)
Here’s a vulnerable Go query:

query := "SELECT * FROM users WHERE username='" + username + "' AND password='" + password + "'"
rows, _ := db.Query(query)

How would you rewrite this using a prepared statement to make it safe?

3.1. Fix the Vulnerable Code (Node.js)
Here’s a vulnerable Node.js query:

const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;
db.query(query, (err, result) => { ... });

Rewrite it using parameterized queries to prevent injection.

💬 Try answering in the comments. Even if you’re not fully confident, writing out your thought process is one of the best ways to learn — and your answer might help another developer too.

Conclusion

SQL Injection is one of the simplest attacks to exploit, but also one of the simplest to prevent — as long as we use secure coding practices like prepared statements, validation, and proper permissions.

I’ll admit — early in my career, I wrote queries just like the vulnerable ones we saw earlier. It’s easy to do without realizing the risk. The important part is learning how to spot these mistakes and fix them before they reach production.

💬 Have you ever discovered SQL Injection risks in your own code? Share your experience in the comments — your story might help another developer catch the same mistake. And don’t forget to drop your answers to the quiz above; I’ll be checking in to give feedback.

👉 Next up in this series: XSS (Cross-Site Scripting) explained simply with Go & Node.js examples.

At the end of the day, secure coding isn’t just about passing interviews — it’s about protecting real people who trust us with their data.

Real-Time Messaging with Go and JavaScript

David Jesse Odhiambo — Mon, 02 Jun 2025 12:21:01 +0000

WebSockets allow your frontend and backend to talk instantly, without the old HTTP request/response delay. In this tutorial, we'll show you how to build a real-time chat application using Go on the backend and JavaScript on the frontend.

🚀 This is Part 3 of the WebSocket series. If you're just joining:

Start with Part 1: HTTP vs WebSockets: What Every Beginner Needs Know

Then check out Part 2: How to Build a Simple WebSocket Server in Go

Let’s put all of it to work now.

Project Overview

We’re building a very basic chat room where users can:

Send messages using a frontend form
Receive messages instantly from other users via WebSocket

Tech stack:

Go (Golang) + Gorilla WebSocket backend
HTML + JavaScript frontend

Backend Setup (Recap)

Here’s the Go server we used in Part 2:

package main

import (
    "fmt"
    "log"
    "net/http"

    "github.com/gorilla/websocket"
)

var upgrader = websocket.Upgrader{
    ReadBufferSize:  1024,
    WriteBufferSize: 1024,
    // Allow all connections
    CheckOrigin: func(r *http.Request) bool { return true },
}

func handleWebSocket(w http.ResponseWriter, r *http.Request) {
    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Println("Upgrade error:", err)
        return
    }
    defer conn.Close()

    for {
        messageType, msg, err := conn.ReadMessage()
        if err != nil {
            log.Println("Read error:", err)
            break
        }

        log.Printf("Received: %s\n", msg)

        // Echo message back to client
        if err := conn.WriteMessage(messageType, msg); err != nil {
            log.Println("Write error:", err)
            break
        }
    }
}

func main() {
    http.HandleFunc("/ws", handleWebSocket)

    fmt.Println("Server started at http://localhost:8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

This server listens for incoming WebSocket connections at /ws, upgrades the HTTP connection, and echoes back any message it receives.

Frontend Code (HTML + JavaScript)

Here’s a minimal frontend you can save as index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Go WebSocket Chat</title>
  <style>
    body { font-family: sans-serif; padding: 2rem; }
    #messages { border: 1px solid #ccc; height: 300px; overflow-y: scroll; margin-bottom: 1rem; padding: 1rem; }
  </style>
</head>
<body>
  <h2>Chat</h2>
  <div id="messages"></div>
  <input type="text" id="msgInput" placeholder="Type a message...">
  <button onclick="sendMessage()">Send</button>

  <script>
    const ws = new WebSocket("ws://localhost:8080/ws");
    const messagesDiv = document.getElementById("messages");

    ws.onmessage = (event) => {
      const msg = document.createElement("div");
      msg.textContent = event.data;
      messagesDiv.appendChild(msg);
    };

    function sendMessage() {
      const input = document.getElementById("msgInput");
      ws.send(input.value);
      input.value = "";
    }
  </script>
</body>
</html>

How It Works

The browser opens a WebSocket connection to ws://localhost:8080/ws
When you type and click Send, JavaScript sends the message to the Go backend.
The Go server receives it and immediately echoes it back.
JavaScript listens for incoming messages and displays them.

It's a direct two-way pipeline — no reloading, no polling!

Debugging Tips

Browser Console Errors: Open DevTools (F12) to see if WebSocket failed to connect.
CORS Issues? Make sure your WebSocket server is on the same origin or add CORS headers.
Connection refused? Ensure your server is running on the right port.

Possibilities Beyond Chat

Now that you’ve got WebSockets working, here’s what else you can build:

✅ Real-time notifications
✅ Multiplayer games
✅ Live dashboards
✅ Collaborative editors (like Google Docs)

And with more tools:

🔐 Add authentication with JWT
🔁 Handle reconnects with backoff
⚙️ Scale using Redis pub/sub or message queues

Where We End

This wraps up our 3-part WebSocket series:

HTTP vs WebSockets: Why it matters
Building a WebSocket server in Go
Connecting that server to a live frontend

From here, you're ready to explore more advanced designs:

Broadcasting to many clients
Creating chat rooms
Scaling with channels and goroutines

Let me know in the comments what you're building with Go and WebSockets 👇

How to Build a Simple WebSocket Server in Go (Step-by-Step Guide)

David Jesse Odhiambo — Wed, 28 May 2025 13:40:02 +0000

In the previous article HTTP vs WebSockets: What Every Beginner Needs to Know we learned about WebSockets and how they power real-time features like chat apps and live dashboards. But how do you actually build one with Go?

In this beginner-friendly guide, we’ll walk through how to:

✅ Set up a WebSocket server in Go
✅ Handle real-time messages
✅ Connect to it from a browser using JavaScript

This is Part 2 of the series. If you’re new to WebSockets, read Part 1: HTTP vs WebSockets—What Every Beginner Should Know first.

🔌 What is Gorilla WebSocket?

Gorilla WebSocket is a popular Go package that makes working with WebSockets easier.

✅ Actively maintained
✅ Full control over message handling
✅ Works well with net/http

Setting up a WebSocket server in Go with Gorilla WebSocket

📦 Step 1: Install Gorilla WebSocket

While in your Go project's directory, open your terminal and run:

go get -u github.com/gorilla/websoc

🛠️ Step 2: Build the WebSocket Server

Let’s write a basic WebSocket server in Go.

Create a file named main.go:

package main

import (
    "fmt"
    "log"
    "net/http"

    "github.com/gorilla/websocket"
)

var upgrader = websocket.Upgrader{
    ReadBufferSize:  1024,
    WriteBufferSize: 1024,
    // Allow all connections
    CheckOrigin: func(r *http.Request) bool { return true },
}

func handleWebSocket(w http.ResponseWriter, r *http.Request) {
    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Println("Upgrade error:", err)
        return
    }
    defer conn.Close()

    for {
        messageType, msg, err := conn.ReadMessage()
        if err != nil {
            log.Println("Read error:", err)
            break
        }

        log.Printf("Received: %s\n", msg)

        // Echo message back to client
        if err := conn.WriteMessage(messageType, msg); err != nil {
            log.Println("Write error:", err)
            break
        }
    }
}

func main() {
    http.HandleFunc("/ws", handleWebSocket)

    fmt.Println("Server started at http://localhost:8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

🌐 Step 3: Simple Frontend (HTML + JavaScript)

Create a file named index.html in the same folder:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>WebSocket Test</title>
</head>
<body>
  <h2>WebSocket Echo Client</h2>
  <input id="msgInput" type="text" placeholder="Type a message..." />
  <button onclick="sendMessage()">Send</button>
  <ul id="messages"></ul>

  <script>
    const ws = new WebSocket("ws://localhost:8080/ws");

    ws.onmessage = (event) => {
      const li = document.createElement("li");
      li.textContent = "Received: " + event.data;
      document.getElementById("messages").appendChild(li);
    };

    function sendMessage() {
      const input = document.getElementById("msgInput");
      ws.send(input.value);
      input.value = "";
    }
  </script>
</body>
</html>

▶️ Step 4: Run Your Server

Run the Go server:

go run main.go

Open index.html in your browser (just double-click it).
Type a message and click Send — you should see your message echoed back in the browser!

🧪 How It Works

Your browser connects to /ws using WebSocket protocol.
Messages are sent to the server.
The server reads them and echoes them back.
All communication happens over a persistent connection.

🚀 Next Steps?

You’ve just built a real-time WebSocket server with Go! Now imagine what else you can do:

Build a chat app 🗨️
Add notifications 🔔
Stream sensor data 📈

In the next article, Real-Time Messaging with Go and JavaScript, we’ll take this further with broadcasting messages to multiple clients (like a real chat room).

✅ Follow me for more beginner-friendly Go tutorials!
Drop a comment if you have questions, or if you’ve built something cool with WebSockets!

HTTP vs WebSockets: What Every Beginner Needs to Know

David Jesse Odhiambo — Tue, 27 May 2025 00:01:58 +0000

If you’re learning how the web works—especially as a Go developer—you’ve probably been using REST APIs and exchanging data via JSON. But as soon as you dip your toes into real-time features like live chat, stock tickers, or multiplayer games, you’ll hear about something called WebSockets.

So, what are WebSockets? Can they replace HTTP and JSON? And when should you use one over the other?

Let’s break it down in the simplest way possible.

HTTP: The Old Reliable

HTTP (Hypertext Transfer Protocol) is the most common way for browsers and servers to communicate.

The client (like your browser) sends a request.
The server sends a response.
The connection closes after each interaction.

This is perfect for actions like:

Loading a webpage
Submitting a form
Fetching JSON data from an API

But what if you need real-time updates? Like getting a new message the moment someone sends it?

That’s where HTTP falls short.

Enter WebSockets: Persistent, Real-Time Connections

WebSockets allow a browser and server to open a persistent connection.

The connection stays open.
Both sides can send messages anytime.
No need to repeatedly ask the server, "Is there anything new?"

This is called full-duplex communication: both client and server can talk to each other continuously.

Perfect for:

Live chats
Notifications
Live dashboards
Multiplayer games

WebSocket vs HTTP (with JSON)

Feature	HTTP (JSON)	WebSockets
Connection Model	Request-response	Persistent, open connection
Data Format	JSON	JSON / binary / text
Server-Initiated Msgs	No	Yes
Overhead	High (headers per request)	Low (single handshake)
Best For	CRUD, APIs	Real-time updates

So yes, WebSockets can replace JSON over HTTP in some cases—but they solve a different problem.

JSON is a data format.
WebSocket is a communication protocol.
You can still use JSON over WebSockets.

Real-World Example: Chat App

Using HTTP + JSON:

You keep sending requests every few seconds: “Any new messages?”
Server responds: “Nope. Still nothing.” (Wasted bandwidth)

Using WebSocket:

You connect once.
The server pushes a message to you as soon as someone sends it.
Efficient and instant.

Should You Always Use WebSockets?

Not really. Here's a quick guide:

✅ Use WebSockets when:

You need real-time updates
The server must push data to the client
You’re building chat apps, live games, or notifications

✅ Use HTTP (with JSON) when:

You're building standard CRUD APIs
Data doesn’t change often
SEO or caching is important

Conclusion

WebSockets don’t replace HTTP entirely—but they give you new possibilities. For Go developers (and frontend devs too), learning WebSockets opens the door to building real-time, modern web applications.

In the next article, we’ll build a simple WebSocket server in Go, and connect it to a browser using JavaScript. You’ll see just how easy (and powerful) it can be.

Ready to go real-time? Let’s dive in!

Stay tuned for Part 2: "How to Build a Simple WebSocket Server in Go (Step-by-Step Guide)"