How Web Push Notifications Work Internally: Implementing with React + Golang

I understand how browser push infrastructure works and designed it properly.
Push notifications have become a core part of modern applications.
Whenever you receive:

a new message alert
an order status update
a deployment notification
a payment reminder there is usually a notification system working behind the scenes.

At first glance, sending a notification looks simple:

Backend sends message → User receives notification

But internally, it involves multiple systems working together:

Browser APIs
Service Workers
Push Services
Encryption
Authentication
Backend workers

In this blog, we will understand how Web Push Notifications work internally and implement a complete push notification system using React.js and Golang.

What are Web Push Notifications?

Web Push allows servers to send messages to browsers even when the website is not open.

The browser displays notifications using a background process called a Service Worker.

Backend → Push Service → Browser → Service Worker → Notification

The important idea: Your backend never directly communicates with the browser.

Instead, every browser provides a Push Service that acts as a delivery system. for example; Chrome: Google Firebase Cloud Messaging, Firefox: Mozilla Push Service

High Level Architecture

Our system contains five major components.

Subscription Flow:

React Application → Service Worker Registration → Push Subscription → Golang Backend → Database

Notification Delivery Flow:

Golang Backend → Browser Push Service → Service Worker → User Notification

Generating VAPID Keys

Before creating subscriptions, our application needs public/private keys.

Generate them using:

package main

import (
    "fmt"
    webpush "github.com/SherClockHolmes/webpush-go"
)

func main(){
    privateKey, publicKey, _ := webpush.GenerateVAPIDKeys()
    fmt.Println("Public:",publicKey)
    fmt.Println("Private:",privateKey)
}

The generated keys:

Public Key:

sent to React application
used while subscribing

Private Key:

stored securely in backend environment variables
used while sending notifications

React Application

The frontend handles:

requesting notification permission
registering service worker
generating push subscription
sending subscription details to backend

Service Worker

A Service Worker is a JavaScript file that runs separately from your React application.
It works even when:

tab is closed
application is inactive
browser is running in background

Responsibilities:

listen for push events
display notifications
handle notification clicks

Browser Push Service

This is managed by browsers.

maintain device connections
receive push messages
wake service workers

Golang Backend

Backend responsibilities:

store subscriptions
authenticate push requests
encrypt notification payloads
send notifications

Subscription Flow

Before sending notifications, the browser needs to register itself.

User Opens Website → Allow Notification Permission → Register Service Worker → Generate Push Subscription → Send Subscription To Backend → Store In Database

React Implementation

First, check browser support.

if ( "serviceWorker" in navigator && "PushManager" in window ) { console.log("Push supported"); }

Request Notification Permission

Browsers require user approval.

async function requestPermission() {
   const permission = await Notification.requestPermission();
   if(permission !== "granted"){
      return;
   }
   console.log( "Notifications enabled" );
}

Register Service Worker

React cannot listen for background events. We register a worker:

const registration = await navigator.serviceWorker.register("/worker.js" );
console.log( "Worker registered", registration );

Creating Push Subscription

Now we create a browser subscription.

const subscription = await registration.pushManager.subscribe({ userVisibleOnly:true, applicationServerKey: VAPID_PUBLIC_KEY });
await fetch( "/api/subscriptions", { method:"POST", body: JSON.stringify(subscription) });

The generated subscription contains:

{ "endpoint":"https://push-service.com/xxx", "keys":{ "p256dh":"public-key", "auth":"secret-key" } }

This is the browser address where notifications will be delivered.

Understanding Service Worker

Create: public/worker.js
A Service Worker listens for push events.

self.addEventListener( "push", event => { 
    const data = event.data.json();
    event.waitUntil(self.registration.showNotification(data.title, 
    { body:data.message, icon:"/icon.png" }));
});

Important: The notification is created outside React. React does not even need to be running.

Sending Notifications Using Go

For implementing Web Push Protocol in Golang, we use:

go get github.com/SherClockHolmes/webpush-go

Import the package:

import (
    webpush "github.com/SherClockHolmes/webpush-go"
)

This package handles:

payload encryption
VAPID authentication
communication with browser push services

Example implementation:

func SendNotification(subscription Subscription, message string) error { 
    _,err := webpush.SendNotification([]byte(message), 
        &webpush.Subscription{Endpoint: subscription.Endpoint,
            Keys:webpush.Keys{Auth: subscription.AuthKey, P256dh: subscription.P256dhKey}},
        &webpush.Options{VAPIDPublicKey: PUBLIC_KEY, VAPIDPrivateKey: PRIVATE_KEY}) 
    return err
}

The Go server:

Reads subscription from database
Encrypts the payload
Signs request using VAPID
Sends message to browser push service

Understanding VAPID Authentication

VAPID stands for: Voluntary Application Server Identification
It proves that:

This notification came from an authorized backend.

It uses two keys:
Public Key : Shared with Browser
Private Key : Stored only on Backend
Never expose VAPID_PRIVATE_KEY in frontend code.

Production Challenges

A demo notification system is easy. A production notification system requires handling edge cases.

Multiple Devices

A single user may have: Chrome Desktop, Android Device, Firefox
Each browser creates a different subscription.

Bad design: One user = One subscription

Better: One user = Many subscriptions

Expired Subscriptions

Push subscriptions can expire.
Reasons:

browser reset
permission removed
device change Push services return: 404 or 410

Remove invalid subscriptions.

Scaling Notification Delivery

Sending notifications directly from APIs works for small systems.
But imagine: 1 Million users
Better architecture:

Application Event → Kafka → Notification Workers → Browser Push Services → Users

Benefits:

asynchronous processing
retries
better reliability
horizontal scaling

Retry Handling

Failures happen because of:

network errors
push service issues
temporary outages

A production system should have:

retry queues
exponential backoff
dead letter queues

Example:

Notification Failed → Retry Queue → Try Again → Dead Letter Queue

Why not WebSockets?

WebSockets are great when users are actively using the application.

Examples:

live chats
multiplayer games
collaborative editing

But WebSockets require an active connection.

When:

the browser tab is closed
device is locked
application process stops

your React application cannot receive messages.
Web Push solves this using Service Workers that can wake up independently from the application.

Security Notes

A few things to remember:

Always use HTTPS in production
Never expose VAPID private keys
Validate users before storing subscriptions
Remove expired subscriptions
Avoid sending sensitive information directly inside notification payloads

推荐订阅源

DEV Community