web application - freeCodeCamp.org

How to Build Real-Time Update Systems with MQTT and Express.js

David Aniebo — Tue, 10 Mar 2026 16:05:25 +0000

Real-time updates are everywhere – like live sports scores, stock tickers, chat applications, and IoT dashboards. If you want to build systems that push data to users the moment it changes, you need the right tools.

Message Queuing Telemetry Transport (MQTT) is a lightweight messaging protocol that excels at this. Combined with a broker like Mosquitto and a web framework like Express, you can build a production-ready real-time system in a single afternoon.

In this tutorial, you'll build a complete real-time football (soccer) sports update system from scratch. You'll create an admin interface for uploading scores and match details, a viewer interface for watching live updates, and a backend that uses MQTT to broadcast changes instantly to every connected client.

By the end of this guide, you'll understand how to integrate MQTT with Express, set up the Mosquitto broker, and deliver real-time data to web browsers using Server-Sent Events. You will have a working system that you can extend for production use.

What You Will Learn
Prerequisites
Understanding the Architecture
What is MQTT and Why Use It?
- MQTT Topic Design
- Why Server-Sent Events Instead of WebSockets?
Project Setup
How to Set Up the MQTT Broker
How to Build the Express Server
How to Implement the Match Routes
How to Bridge MQTT to the Browser with Server-Sent Events
How to Build the Admin Upload Interface
- Admin HTML Structure and Styles
- Admin JavaScript Logic
How to Build the Live Viewer Interface
- Viewer JavaScript Logic
How to Build the Home Page
How to Run and Test the System
How to Extend the System for Production
API Reference
Troubleshooting
Conclusion

What You Will Learn

During this tutorial, you'll learn how to:

Connect an Express server to an MQTT broker using the MQTT.js library
Publish and subscribe to MQTT topics for real-time messaging
Use Server-Sent Events to push MQTT messages to web browsers
Build a REST application programming interface (API) for match and score management
Create a simple admin interface for uploading match data
Create a viewer interface that updates in real time without page refreshes

Prerequisites

Before you start, you should have:

Node.js version 18 or later installed on your machine
Basic familiarity with JavaScript, Express, and HTML
A terminal or command line for running commands
Docker installed (optional, for running Mosquitto in a container)

If you don't have Node.js installed, you can download it from the official Node.js website.

Understanding the Architecture

The system has three main parts:

Admin interface – A web page where you create matches, update scores, and add events such as goals and cards.
Express server – Receives HyperText Transfer Protocol (HTTP) requests from the admin, publishes data to MQTT, subscribes to MQTT topics, and streams updates to viewers via Server-Sent Events.
Viewer interface – A web page that connects to the server and displays live scores and events as they arrive.

How the flow works
When you submit a score update in the admin panel, the Express server publishes a message to the MQTT broker. The server also subscribes to those same topics. When a message arrives, the server forwards it to all connected viewers through Server-Sent Events. The viewers update their display without refreshing the page.

What is MQTT and Why Use It?

MQTT stands for Message Queuing Telemetry Transport. It's a lightweight, publish-subscribe messaging protocol designed for low bandwidth and unreliable networks. It's widely used in Internet of Things (IoT) applications, but it works well for any real-time system where you need to broadcast updates to many subscribers.

Here are some reasons to use MQTT for a sports update system:

Low overhead: Messages are small and efficient, which helps when you have many clients.
Built-in Quality of Service (QoS): You can choose how many times a message is delivered (at most once, at least once, or exactly once).
Topic-based routing: You organize messages by topic (for example, sports/football/match/123) so subscribers receive only what they need.
Broker-based: A central broker (Mosquitto) handles all message distribution, so your application logic stays simple.

Mosquitto is a popular, open-source MQTT broker that's easy to install and configure.

MQTT Topic Design

MQTT uses a hierarchical topic structure. For this project, the topics are:

sports/football/match/{id}: One topic per match. When you publish the full match object here, any subscriber receives the complete state. This makes it easy to add new match fields later without changing the topic structure.
sports/football/scores: A single topic for score-related notifications. Messages include a type field (match_created or score_update) so subscribers can handle them differently.
sports/football/events: A topic for match events such as goals and cards. Subscribers receive { type: 'match_event', matchId, event }.

The # wildcard in a subscription means "match this level and all levels below." So sports/football/# subscribes to every topic under sports/football, including sports/football/match/abc123 and sports/football/scores. The + wildcard matches exactly one level. For example, sports/+/match/# would match any sport, not just football.

Why Server-Sent Events Instead of WebSockets?

You might wonder why this tutorial uses Server-Sent Events (SSE) instead of WebSockets. Both can push data to the browser. The main difference:

Server-Sent Events: One-way (server to client). Built on HTTP. Automatic reconnection in the browser. Simpler to implement. No extra libraries.
WebSockets: Two-way. Requires a different protocol. More flexible but more complex.

For a sports score viewer, you only need server-to-client updates. The viewer never sends messages back over the same channel. Server-Sent Events is a better fit. If you later need the client to send commands (for example, to filter by league), you can add a separate HTTP API or switch to WebSockets.

Project Setup

Start by creating a new folder for your project and initialize it with npm. The mkdir command creates the directory, cd moves into it, and npm init -y creates a package.json file with default values without prompting you for input.

mkdir mqtt-football-scores
cd mqtt-football-scores
npm init -y

Install the required dependencies. Each package serves a specific role in the application. Run this command in the project root directory.

npm install express cors mqtt uuid

express: Web framework for the HTTP server and API. It provides routing, middleware, and static file serving.
cors: Enables Cross-Origin Resource Sharing so your frontend can call the API from a different origin (for example, if you serve the HTML from a different port or domain).
mqtt: MQTT client for Node.js. It handles connection, publish, subscribe, reconnection, and Quality of Service (QoS) flows.
uuid: Generates unique identifiers (Universally Unique Identifiers) for matches and events. Each ID is practically unique across all systems.

Next, create the following folder structure. The server folder holds the Node.js backend code. The public folder holds the HTML, CSS, and client-side JavaScript that the browser loads. The routes subfolder keeps the match-related route handlers separate from the main server file.

mqtt-football-scores/
├── server/
│   ├── index.js
│   ├── sse.js
│   └── routes/
│       └── matches.js
├── public/
│   ├── index.html
│   ├── admin.html
│   └── viewer.html
├── mosquitto.conf
├── docker-compose.yml
└── package.json

Add "type": "module" to your package.json so you can use JavaScript modules (import and export). The type field tells Node.js to treat .js files as ES modules, which allows you to use import and export syntax instead of CommonJS require and module.exports.

{
  "name": "mqtt-football-scores",
  "version": "1.0.0",
  "type": "module",
  "main": "server/index.js"
}

How to Set Up the MQTT Broker

You need an MQTT broker running before the server can connect. You have three options.

Option 1: Docker (Recommended)

Create a docker-compose.yml file. This file defines a single service named mosquitto that runs the Eclipse Mosquitto 2 image. The ports directive maps port 1883 on your host to port 1883 in the container so your Express server can connect. The volumes directive mounts your local mosquitto.conf into the container so the broker uses your configuration. The restart: unless-stopped option ensures the container restarts automatically if it crashes or if you reboot your machine.

version: "3.8"

services:
  mosquitto:
    image: eclipse-mosquitto:2
    container_name: mqtt-football-mosquitto
    ports:
      - "1883:1883"
    volumes:
      - ./mosquitto.conf:/mosquitto/config/mosquitto.conf
    restart: unless-stopped

Create a mosquitto.conf file. The listener 1883 directive tells Mosquitto to listen on port 1883 for MQTT connections. The protocol mqtt specifies the standard MQTT protocol (as opposed to WebSocket). The allow_anonymous true setting permits connections without a username and password, which is fine for local development but should be disabled in production. The log_dest stdout and log_type all directives send all log output to the console so you can debug connection issues.

listener 1883
protocol mqtt
allow_anonymous true
log_dest stdout
log_type all

Start the broker:

docker-compose up -d

Option 2: Local Install

On macOS with Homebrew:

brew install mosquitto
mosquitto -c mosquitto.conf

On Ubuntu or Debian:

sudo apt install mosquitto mosquitto-clients
sudo systemctl start mosquitto

Option 3: Public Test Broker

You can use the public test broker at test.mosquitto.org without installing anything. Set the environment variable when you start the server:

MQTT_BROKER=mqtt://test.mosquitto.org npm start

Note: The public broker is shared and not suitable for production. Use it only for development and testing.

How to Build the Express Server

In this step, you'll create the main server that powers the real-time application. The Express server handles HTTP requests, serves static files like HTML and JavaScript, and acts as the bridge between the browser and the MQTT broker. It also provides endpoints that allow data to be sent and received in real time. Essentially, this server is the backbone of the application, enabling communication between all components.

Begin by creating the main server file at server/index.js:

import express from 'express';
import cors from 'cors';
import mqtt from 'mqtt';
import { fileURLToPath } from 'url';
import { dirname, join } from 'path';
import { v4 as uuidv4 } from 'uuid';

import { matchRoutes } from './routes/matches.js';
import { setupSSE, addSSEClient } from './sse.js';

const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);

const MQTT_BROKER = process.env.MQTT_BROKER || 'mqtt://localhost:1883';
const PORT = process.env.PORT || 3000;

const app = express();
app.use(cors());
app.use(express.json());
app.use(express.static(join(__dirname, '../public')));

let mqttClient = null;

function connectMQTT() {
  mqttClient = mqtt.connect(MQTT_BROKER, {
    clientId: `football-scores-${uuidv4().slice(0, 8)}`,
    reconnectPeriod: 3000,
    connectTimeout: 10000,
  });

  mqttClient.on('connect', () => {
    console.log('Connected to MQTT broker at', MQTT_BROKER);
    mqttClient.subscribe('sports/football/#', { qos: 1 }, (err) => {
      if (err) console.error('Subscribe error:', err);
    });
  });

  mqttClient.on('error', (err) => {
    console.error('MQTT error:', err.message);
  });

  mqttClient.on('close', () => {
    console.log('MQTT connection closed');
  });

  mqttClient.on('reconnect', () => {
    console.log('MQTT reconnecting...');
  });

  return mqttClient;
}

const mqttClientInstance = connectMQTT();
const { publishMatch, publishScoreUpdate, publishEvent, getMatches } = matchRoutes(mqttClientInstance);
setupSSE(mqttClientInstance);

app.get('/api/events', (req, res) => addSSEClient(res));
app.post('/api/matches', publishMatch);
app.patch('/api/matches/:id/score', publishScoreUpdate);
app.post('/api/matches/:id/events', publishEvent);
app.get('/api/matches', getMatches);

app.listen(PORT, () => {
  console.log(`Football Scores Server running at http://localhost:${PORT}`);
  console.log(`Admin (upload):  http://localhost:${PORT}/admin.html`);
  console.log(`Viewer:          http://localhost:${PORT}/viewer.html`);
});

Here is what each part does:

Imports: The fileURLToPath and dirname utilities replicate the __dirname variable that CommonJS provides, since ES modules don't have it. You need __dirname to build the path to the public folder.
Environment variables: MQTT_BROKER defaults to mqtt://localhost:1883 so the server connects to a local Mosquitto instance. You can override it for Docker or a remote broker. PORT defaults to 3000.
Middleware: cors() allows requests from any origin, which is useful during development. express.json() parses JSON request bodies. express.static() serves files from public so /admin.html and /viewer.html are available.
connectMQTT: Creates an MQTT client with a unique client ID (required by the broker), a 3-second reconnect interval, and a 10-second connection timeout. On connect, it subscribes to sports/football/# with QoS 1. The # wildcard means "all topics under sports/football."
matchRoutes: Returns the route handlers that create matches, update scores, and add events. Each handler publishes to MQTT and responds with JSON.
setupSSE: Registers a listener on the MQTT client's message event. When a message arrives, it forwards the payload to all connected Server-Sent Events clients.
addSSEClient: Called when a viewer opens /api/events. It sets the response headers for Server-Sent Events, flushes the headers so the connection stays open, and adds the response object to a set of active clients.
Routes: The GET /api/events route establishes the Server-Sent Events stream. The POST, PATCH, and GET routes for matches delegate to the handlers from matchRoutes.

The server serves static files from the public folder, so your HTML pages are available at the root.

How to Implement the Match Routes

In this step, you'll create the route handlers that manage matches, scores, and events. These routes allow the server to receive requests from the admin interface, update match data, and publish real-time updates to MQTT. They also store match information in memory so it can be retrieved and updated during the session.

Begin by creating the file at server/routes/matches.js:

import { v4 as uuidv4 } from 'uuid';

const TOPIC_MATCH = 'sports/football/match';
const TOPIC_SCORES = 'sports/football/scores';
const TOPIC_EVENTS = 'sports/football/events';

const matches = new Map();

function publish(client, topic, payload, qos = 1) {
  if (!client?.connected) {
    console.warn('MQTT not connected, message not published');
    return false;
  }
  client.publish(topic, JSON.stringify(payload), { qos, retain: false });
  return true;
}

export function matchRoutes(mqttClient) {
  return {
    publishMatch: (req, res) => {
      const { homeTeam, awayTeam, league, venue, kickoff } = req.body;
      if (!homeTeam || !awayTeam) {
        return res.status(400).json({ error: 'homeTeam and awayTeam are required' });
      }

      const match = {
        id: uuidv4(),
        homeTeam,
        awayTeam,
        homeScore: 0,
        awayScore: 0,
        league: league || 'Premier League',
        venue: venue || 'TBD',
        kickoff: kickoff || new Date().toISOString(),
        status: 'scheduled',
        minute: 0,
        events: [],
        createdAt: new Date().toISOString(),
      };

      matches.set(match.id, match);

      const topic = `\({TOPIC_MATCH}/\){match.id}`;
      publish(mqttClient, topic, match);
      publish(mqttClient, TOPIC_SCORES, { type: 'match_created', match });

      res.status(201).json(match);
    },

    publishScoreUpdate: (req, res) => {
      const { id } = req.params;
      const { homeScore, awayScore, minute, status } = req.body;

      const match = matches.get(id);
      if (!match) {
        return res.status(404).json({ error: 'Match not found' });
      }

      if (homeScore !== undefined) match.homeScore = homeScore;
      if (awayScore !== undefined) match.awayScore = awayScore;
      if (minute !== undefined) match.minute = minute;
      if (status !== undefined) match.status = status;

      const topic = `\({TOPIC_MATCH}/\){id}`;
      publish(mqttClient, topic, match);
      publish(mqttClient, TOPIC_SCORES, {
        type: 'score_update',
        matchId: id,
        homeScore: match.homeScore,
        awayScore: match.awayScore,
        minute: match.minute,
        status: match.status,
      });

      res.json(match);
    },

    publishEvent: (req, res) => {
      const { id } = req.params;
      const { type, team, player, minute, description } = req.body;

      const match = matches.get(id);
      if (!match) {
        return res.status(404).json({ error: 'Match not found' });
      }

      const event = {
        id: uuidv4().slice(0, 8),
        type: type || 'goal',
        team,
        player: player || 'Unknown',
        minute: minute ?? match.minute,
        description: description || `\({type}: \){player}`,
        timestamp: new Date().toISOString(),
      };

      match.events.push(event);
      if (type === 'goal') {
        if (team === match.homeTeam) match.homeScore++;
        else if (team === match.awayTeam) match.awayScore++;
      }

      const topic = `\({TOPIC_MATCH}/\){id}`;
      publish(mqttClient, topic, match);
      publish(mqttClient, TOPIC_EVENTS, { type: 'match_event', matchId: id, event });

      res.status(201).json({ match, event });
    },

    getMatches: (req, res) => {
      const list = Array.from(matches.values()).sort(
        (a, b) => new Date(b.createdAt) - new Date(a.createdAt)
      );
      res.json(list);
    },
  };
}

The routes use an in-memory Map to store matches. In production, you would replace this with a database such as PostgreSQL or MongoDB.

Explanation of the key logic:

publish: A helper that checks if the MQTT client is connected before publishing. If the broker is down, it logs a warning instead of throwing. The retain: false option means the broker doesn't store the last message for new subscribers.
publishMatch: Validates that homeTeam and awayTeam are present. Creates a match object with default values for league, venue, kickoff, status, and events. Stores it in the Map, publishes to the match-specific topic and the scores topic, and returns the match with status 201 (Created).
publishScoreUpdate: Looks up the match by ID. If not found, returns 404. Updates only the fields that are provided (using !== undefined so you can set a score to 0). Publishes the full match and a score_update notification.
publishEvent: Creates an event object with a short unique ID. Pushes it to the match's events array. If the event type is goal, increments the home or away score based on the team. Publishes the updated match and an event notification.
getMatches: Converts the Map to an array, sorts by createdAt descending (newest first), and returns the list as JSON.

MQTT topics used:

sports/football/match/{id}: Full match state. Used when a match is created or updated.
sports/football/scores: Score change notifications. Used for match creation and score updates.
sports/football/events: Match events such as goals and cards.

The publish function sends JavaScript Object Notation (JSON) payloads with QoS 1 (at least once delivery). MQTT defines three QoS levels: 0 (at most once), 1 (at least once), and 2 (exactly once). Level 1 ensures the broker will retry until the subscriber acknowledges the message, which reduces the chance of losing score updates if the connection drops briefly.

How to Bridge MQTT to the Browser with Server-Sent Events

In this step, you'll create the Server-Sent Events (SSE) module that bridges MQTT messages to the browser. MQTT works over TCP and browsers cannot connect to it directly, so we use SSE as a lightweight HTTP-based streaming channel. SSE keeps an open connection and allows the server to push updates to connected browsers in real time. This is what enables viewers to see match updates instantly without refreshing.

Now create the file at server/sse.js:

const clients = new Set();

export function setupSSE(mqttClient) {
  if (!mqttClient) return;

  mqttClient.on('message', (topic, message) => {
    try {
      const payload = JSON.parse(message.toString());
      const data = JSON.stringify({ topic, ...payload });
      clients.forEach((res) => {
        try {
          res.write(`data: ${data}\n\n`);
        } catch (e) {
          clients.delete(res);
        }
      });
    } catch (e) {
      console.error('SSE parse error:', e.message);
    }
  });
}

export function addSSEClient(res) {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');
  res.setHeader('X-Accel-Buffering', 'no');
  res.flushHeaders();

  clients.add(res);

  res.on('close', () => {
    clients.delete(res);
  });
}

Explanation of each part:

clients Set: A Set holds all active Server-Sent Events response objects. Using a Set makes it easy to add and remove clients without duplicates.
setupSSE: Attaches a message listener to the MQTT client. When any message arrives on a subscribed topic, the callback runs. It parses the message payload (which is JSON), merges the topic into the payload with { topic, ...payload }, and sends the result to every client. The Server-Sent Events format requires each message to be data: {content}\n\n (two newlines). The forEach loop catches write errors (for example, if a client disconnected) and removes the client from the set.
addSSEClient: Sets the Content-Type header to text/event-stream so the browser treats the response as an event stream. The Cache-Control: no-cache and Connection: keep-alive headers prevent the browser or proxy from caching or closing the connection. The X-Accel-Buffering: no header disables buffering in Nginx, which can delay or block Server-Sent Events. The flushHeaders call sends the headers immediately so the connection is established. The close event handler removes the client when the client disconnects (closes the tab or navigates away).

Server-Sent Events is one-way (server to client). For this use case, that is enough because viewers only need to receive updates, not send messages back over the same channel.

How to Build the Admin Upload Interface

The admin interface is a single HTML page where match creators can create new matches, update scores, and add events such as goals or cards. It uses standard HTML forms so data can be submitted to the server, and JavaScript will later handle form submissions and dynamic updates. All the markup, styles, and script live in public/admin.html, which the Express server serves as a static page.

Admin HTML Structure and Styles

The document starts with the standard HTML5 boilerplate. The charset and viewport meta tags ensure proper character encoding and responsive layout on mobile devices. The page loads the Outfit font from Google Fonts for a clean, modern look.

The Cascading Style Sheets (CSS) uses custom properties (variables) in the :root block so you can change the color scheme in one place. The --bg variable holds the dark background color, --surface for card backgrounds, --accent for the green accent color, and --text-muted for secondary text. The .grid class creates a two-column layout for form fields that collapses to one column on screens under 600 pixels wide. The .toast class positions the notification at the bottom-right and uses transform and opacity for a slide-in animation when the .show class is added.

Now create the file at public/admin.html:




  
  
  Admin - Football Scores Upload
  
  
  
  


  
    
      ⚽ Football Scores
      Admin
      → Open Viewer
    

    
      Create New Match
      
        
          
            Home Team
            
          
          
            Away Team
            
          
          
            League
            
          
          
            Venue
            
          
          
            Kickoff (ISO)
            
          
        
        
          
        
      
    

    
      Update Score
      
        
          
            Select Match
            
          
          
            Home Score
            
          
          
            Away Score
            
          
          
            Minute
            
          
          
            Status
            
          
        
        
          
        
      
    

    
      Add Match Event (Goal, Card, etc.)
      
        
          
            Select Match
            
          
          
            Event Type
            
          
          
            Team
            
          
          
            Player
            
          
          
            Minute
            
          
          
            Description
            
          
        
        
          
        
      
    

    
      Active Matches

The three forms use id attributes (createMatch, updateScore, addEvent) so the JavaScript can attach submit handlers. The match dropdowns (scoreMatchId and eventMatchId) are populated dynamically when the page loads. The matchList div is the container for the list of active matches. The toast element sits outside the main container so it can be fixed to the viewport.

Admin JavaScript Logic

The script block handles all interaction between the admin page and the server. It defines helper functions for showing notifications, fetching matches, updating the UI, and submitting data. When the page loads or after any action (create, update, or event submission), the UI refreshes so the latest match data is always visible.

Explanation of each part:

showToast: updates the toast text and adds the show class to trigger the CSS animation. The isError parameter switches the toast to a red background for error messages. The setTimeout removes the show class after 3 seconds so the toast slides back out.
fetchMatches: calls the GET /api/matches endpoint and returns the parsed JSON so the UI can display the latest data.
populateSelects: builds option elements from the matches array and injects them into both dropdowns, so the same match list appears in the Update Score and Add Event forms.
renderMatchList: either shows a placeholder when there are no matches or renders each match as a card with team names, scores, league, status, and an Update button.
quickScore: pre-fills the Update Score form when you click the Update button on a match card, so you can adjust the score without re-selecting the match.
loadMatches: fetches matches, populates the dropdowns, and renders the list. It runs on page load and after every successful create, update, or event submission.
onsubmit: calls e.preventDefault() to stop the default form submission, builds a request body from the form values, sends a fetch request to the appropriate endpoint, and on success shows a toast and calls loadMatches to refresh the UI.

How to Build the Live Viewer Interface

The viewer interface displays real-time match updates and connects to the Server-Sent Events endpoint so it can receive data the moment the server pushes it.

Unlike the admin page, the viewer is read-only: it shows live scores, match events, and status updates without requiring user input. The page uses a dark theme and a connection indicator so users can see whether the real-time stream is active.

Now create the file at public/viewer.html:




  
  
  Live Football Scores
  
  
  
  


  
    
      ⚽ Live Football Scores
      
        
        Connecting...
      
    

    

    
      Live Feed

Explanation of each part:

header: displays the page title and a connection indicator so users know whether the real-time stream is active.
status dot: a small circle that pulses while disconnected and turns green with a glow when the SSE connection is established.
matches container: the div with id="matches" is where match cards will be rendered dynamically by JavaScript as data arrives.
feed section: shows a chronological list of live updates so users can see recent events at a glance.
CSS theme: uses dark colors and custom properties so the look can be adjusted in one place. The live badge and border styles highlight matches that are in progress.
Server-Sent Events integration: JavaScript (added in the next step) will connect to /api/events and update this page whenever new data arrives.

The header shows the title and a connection status indicator. The matches div is the container for match cards, populated by JavaScript. The feed div displays the live feed of recent updates.

Viewer JavaScript Logic

The script powers the live viewer interface by maintaining an in-memory collection of matches and a feed of recent updates. It connects to the Server-Sent Events endpoint so data flows from the server to the browser in real time. When messages arrive, the page updates automatically to show the latest scores, events, and match details.

Explanation of each part:

The matches Map: stores match objects keyed by ID so updates can be applied efficiently without searching arrays.
The feed array: keeps a small history of recent events (limited to MAX_FEED) so the live feed remains lightweight.
setStatus: toggles the connected class on the status dot and updates the status text to “Live” or “Reconnecting…” so users know connection status.
renderMatches: converts the Map to a sorted array (newest first). If there are no matches, it displays an empty state. Otherwise it renders cards showing league, venue, teams, scores, status badge, minute, and events.
getEventIcon: returns an emoji for each event type so events are visually identifiable (goal, card, substitution, and so on).
renderFeed: displays the live feed items or a placeholder message when no updates exist.
addFeedItem: appends a timestamped message to the feed, keeps only the latest items, and re-renders the feed.
handleMessage: processes incoming data. It updates the matches Map for full match objects, score updates, and match events. For score updates and goals it adjusts scores and adds feed items so the viewer reflects real-time changes.
handleSSEMessage: parses the Server-Sent Events payload and forwards it to handleMessage. If the message contains a match topic and full match data, it stores it in the Map.
connectSSE: creates an EventSource connection to /api/events. On open it marks the connection as live. On error it closes and retries after three seconds so transient network issues do not break the stream.
loadInitial: fetches existing matches on page load so the viewer displays data even before real-time updates arrive.

How to Build the Home Page

The home page (public/index.html) is a simple landing page that links to the viewer and admin interfaces. It uses a centered card layout with two buttons. The primary button (green) goes to the viewer, and the secondary button (outlined) goes to the admin. The page uses the same dark theme and Outfit font for consistency. There is no JavaScript – it's purely static HTML and CSS.




  
  
  Football Scores - MQTT Real-Time
  
  
  
  


  
    ⚽ Football Scores
    Real-time updates via MQTT & Mosquitto
    
      View Live Scores
      Admin - Upload Scores

The Express server serves index.html when you visit the root URL (http://localhost:3000/) because the express.static middleware serves files from the public folder, and Express automatically serves index.html when the request path is /.

How to Run and Test the System

Start the MQTT broker (Docker or local install).

Then start the Express server:

npm start

Next, open http://localhost:3000/admin.html in the admin panel. Create a new match (for example, Manchester United vs Liverpool).

Open http://localhost:3000/viewer.html in another tab or window. Then update the score or add an event in the admin panel. The viewer should update within a second without refreshing.

How to Extend the System for Production

The current implementation uses in-memory storage. For production, you should:

Add a database: Store matches in PostgreSQL, MongoDB, or another database. Load matches on startup and persist every create, update, and event.
Add authentication: Protect the admin routes with JSON Web Tokens (JWT) or session-based auth so only authorized users can upload scores.
Add validation: Validate request bodies with a library such as Joi or Zod to prevent invalid data.
Enable TLS: Use HTTPS for the Express server and secure WebSockets or MQTTS for the broker in production.
Scale horizontally: If you run multiple server instances, each will have its own MQTT connection and SSE clients. The MQTT broker will deliver messages to all subscribers, so each instance will receive updates and forward them to its connected viewers.

API Reference

For quick reference, here are the endpoints your server exposes:

Method	Endpoint	Description
GET	`/api/matches`	Returns all matches as a JSON array
POST	`/api/matches`	Creates a new match. Body: `{ homeTeam, awayTeam, league?, venue?, kickoff? }`
PATCH	`/api/matches/:id/score`	Updates a match score. Body: `{ homeScore?, awayScore?, minute?, status? }`
POST	`/api/matches/:id/events`	Adds an event. Body: `{ type?, team, player?, minute?, description? }`
GET	`/api/events`	Server-Sent Events stream for real-time updates

The status field can be scheduled, live, halftime, or finished. The type field for events can be goal, yellow_card, red_card, substitution, or penalty.

Troubleshooting

You might come across various issues as you build this. Here are some common ones:

The server cannot connect to the MQTT broker. Check that Mosquitto is running. If you use Docker, run docker ps to verify the container is up. If you use the public broker, ensure you have internet connectivity and that your firewall allows outbound connections on port 1883.

The viewer does not update when you change scores. Open the browser developer tools and check the Network tab. The /api/events request should show a pending state (it stays open). If it fails or closes, check the server logs for errors. Ensure you are not behind a proxy that buffers or closes long-lived connections.

Matches disappear when you restart the server. The current implementation stores matches in memory. Restarting the server clears the data. Add a database as described in the production section to persist matches across restarts.

Conclusion

In this tutorial, you built a real-time football sports update system using MQTT, Mosquitto, and Express. You've learned how to:

Connect an Express server to an MQTT broker
Publish match and score updates to MQTT topics
Subscribe to topics and forward messages to browsers via Server-Sent Events
Build an admin interface for creating matches and updating scores
Build a viewer interface that displays live updates without page refreshes

The same pattern applies to other real-time systems: IoT dashboards, live notifications, collaborative editing, and more. MQTT gives you a reliable, scalable messaging layer, and Server-Sent Events gives you a simple way to push updates to web clients.

The code in this tutorial gives you a solid foundation. Try adding features such as match filtering by league, historical event logs, or push notifications to make the system your own.

How to Choose a Web Application Firewall for Web Security

Manish Shivanandhan — Fri, 20 Jun 2025 17:09:45 +0000

If you run a website or web app, you’ve probably heard about firewalls. But there’s a special kind just for websites called a Web Application Firewall, or WAF.

Think of it like a bouncer at the door of your site, checking every visitor to make sure they’re not trying anything shady before letting them through.

While regular firewalls protect your network, a WAF specifically filters traffic that targets your app. It looks for dangerous requests – like someone trying to inject bad code (SQL injection), trick your browser (XSS), or flood your server with fake users (bots). A good WAF stops these threats in real-time, long before they can cause damage.

Now, there are plenty of WAFs out there. Some are cloud-based and easy to plug in. Others give you more control and run on your own servers.

Let’s look at five great options, each offering different strengths depending on what you need.

Cloudflare WAF

Cloudflare has become almost a default for many small to mid-sized websites – and for good reason. Their WAF is fast to deploy and offers solid protection right out of the gate. It’s built into their global content delivery network (CDN), so not only do you get security, but your site loads faster too.

One big plus is that even the free plan gives you some basic protection. You can upgrade for more advanced features, like custom firewall rules, bot mitigation, and protection against zero-day threats (those new exploits that don’t have patches yet).

From e-commerce stores to popular hosting services, Cloudflare makes it really simple. You just point your domain to them, flip a few switches, and you’re protected. There’s not much to configure unless you want to get deep into the rules.

The only downside? If you need very specific filtering or want total control over how things are blocked, you might find it limiting without moving to their higher-tier plans.

Imperva WAF

If Cloudflare is your plug-and-play option, Imperva is the full-blown enterprise solution.

This WAF is made for organizations that need more than just basic protection. It’s not just looking at requests and saying yes or no – it’s analyzing traffic patterns, understanding what’s normal, and alerting you when something looks off.

Imperva also helps with compliance. So if you’re in a regulated industry like finance, healthcare, or government, it can help you meet data protection rules and audit requirements.

You can use it in the cloud or install it on your own hardware, which is great if your company needs to keep things on-site.

Just know that it’s not as beginner-friendly as Cloudflare. There’s a learning curve, and pricing can get high depending on the features you use.

But if you’re running mission-critical web apps and need deep visibility into traffic and threats, Imperva is a strong contender.

SafeLine WAF

Now let’s talk about something different – SafeLine. Unlike the big-name cloud platforms, SafeLine is a self-hosted WAF. That means you run it yourself, right alongside your web server.

Built on NGINX, one of the fastest and most popular web servers out there, SafeLine is designed to be lightweight but powerful. It has over 300,000 installations and more than 16,000 stars on GitHub. That’s a pretty big community for a security tool.

What makes it special is how it analyzes web traffic. SafeLine uses something called semantic detection. Instead of just looking for known attack signatures, it tries to understand what each request is trying to do.

That helps it block more threats and reduce false alarms. It can detect things like SQL injection, cross-site scripting, directory traversal, and even bad bots.

It also adds cool tricks like rate limiting, identify authentication, challenge pages for suspicious users, and even dynamic encryption of your site’s HTML and JavaScript to confuse attackers.

Of course, because it’s self-hosted, it’s not for everyone. You need to install it, configure it, and keep it updated yourself. But if you’re comfortable working with Linux or you want full control over your WAF, SafeLine is a fantastic choice – especially since it provides a free edition for personal use.

Fortinet FortiWeb

Fortinet is a name that’s been around in network security for a long time. Their WAF, FortiWeb, brings that enterprise-level muscle to web apps.

It combines traditional filtering with machine learning to spot weird behavior. So if someone starts sending strange requests your site’s never seen before, FortiWeb can recognize it and shut it down.

What sets FortiWeb apart is its deep integration with the rest of the Fortinet ecosystem. If you’re already using FortiGate firewalls or FortiAnalyzer tools, adding FortiWeb is a natural next step. Everything works together, giving you a full picture of your network and web security.

It’s powerful, but it’s also complex. Setting it up and maintaining it takes time and expertise. And like Imperva, this is a tool that shines in large organizations with experienced security teams.

If that’s your environment – and you want high-end features like API discovery, anomaly detection, and DDoS protection – it’s worth a close look.

F5 Advanced WAF

Last on our list is F5’s Advanced WAF. This one’s also built for big players.

It’s part of the larger F5 BIG-IP platform, which handles traffic management, load balancing, and more. If you already use BIG-IP, adding the WAF module gives you strong security without needing extra infrastructure.

F5’s WAF offers advanced protection against bots, APIs, and credential stuffing (where attackers try to log in with stolen passwords). One unique feature is its partnership with Shape Security, which gives it extra tools to identify fake users and bot traffic.

You can deploy F5’s WAF in your data center, in the cloud, or at the edge. That flexibility makes it attractive for companies running complex, multi-cloud applications.

But like the other enterprise options here, F5 comes with complexity and cost. If you’re running a big operation and need fine-grained control and integration, it’s a solid choice.

Which One Should You Choose?

There’s no single best WAF for everyone. What works for a solo developer running a WordPress blog might not cut it for a multinational bank. So the best choice comes down to what matters most to you.

If you want something fast and simple, with a free tier and global speed boosts, Cloudflare is hard to beat.
If your team needs compliance support, traffic analytics, and strong API protection, Imperva fits the bill.
For developers who like to build and tinker, SafeLine offers impressive protection and full control – without breaking the bank.
And for enterprises with existing Fortinet or F5 setups, it makes sense to stay in those ecosystems for seamless integration and the highest level of customization.

Summary

No matter what you choose, the important part is having a WAF in place. It’s one of the best defenses against the constant stream of attacks targeting websites today. Whether it’s blocking a SQL injection, filtering out bad bots, or just keeping your error logs clean, a good WAF keeps your site running smoothly and safely.

Hope you enjoyed this article. You can learn more about me or connect with me on LinkedIn.

web application - freeCodeCamp.org

How to Build Real-Time Update Systems with MQTT and Express.js

Table of Contents

What You Will Learn

Prerequisites

Understanding the Architecture

What is MQTT and Why Use It?

MQTT Topic Design

Why Server-Sent Events Instead of WebSockets?

Project Setup

How to Set Up the MQTT Broker

Option 1: Docker (Recommended)

Option 2: Local Install

Option 3: Public Test Broker

How to Build the Express Server

How to Implement the Match Routes

How to Bridge MQTT to the Browser with Server-Sent Events

How to Build the Admin Upload Interface

Admin HTML Structure and Styles

Create New Match

Update Score

Add Match Event (Goal, Card, etc.)

Active Matches

Admin JavaScript Logic

How to Build the Live Viewer Interface

Live Feed

Viewer JavaScript Logic

How to Build the Home Page

⚽ Football Scores

How to Run and Test the System

How to Extend the System for Production

API Reference

Troubleshooting

Conclusion

How to Choose a Web Application Firewall for Web Security

Cloudflare WAF

Imperva WAF

SafeLine WAF

Fortinet FortiWeb

F5 Advanced WAF

Which One Should You Choose?

Summary