← 목록

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

devto 2026-06-25 원문 보기 ↗

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

At first glance, sending a notification looks simple:

Backend sends message → User receives notification

But internally, it involves multiple systems working together:

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:

Private Key:

React Application

The frontend handles:

Service Worker

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

Responsibilities:

Browser Push Service

This is managed by browsers.

Golang Backend

Backend responsibilities:

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:

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:

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:

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:

Retry Handling

Failures happen because of:

A production system should have:

Example:

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

Why not WebSockets?

WebSockets are great when users are actively using the application.

Examples:

But WebSockets require an active connection.

When:

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: