Service Worker

General definition

A Service Worker is defined by the W3C Service Workers specification. It is registered by a page, installed by the browser, and from then on runs in its own thread with no access to the DOM. It is event-driven: the browser wakes it for install, activate, fetch, push and sync events and may stop it when idle. Because it can intercept network requests, it must be served over HTTPS, and it only controls pages within its scope, typically the directory it was served from.

• Offline and caching: the fetch handler can answer from the Cache API, fall back to the network, or combine the two (stale-while-revalidate)
• Web push: the push event fires when the push service delivers a message, and the worker calls showNotification even if no tab is open
• Background sync and periodic sync: defer work until the device has connectivity
• Progressive Web Apps: a registered service worker plus a manifest is what makes a site installable

The lifecycle catches people out. A new version of the worker installs in the background and waits until every tab using the old one has closed, unless it calls skipWaiting. Caches persist across versions and must be cleaned up in activate. Debugging happens in the browser’s Application panel, where workers can be unregistered and caches cleared. Safari supports service workers and, since iOS 16.4, web push for web apps added to the home screen, which closed the last major gap.

For chat, the service worker is the piece that delivers push notifications to the web: the page subscribes through the Push API, the subscription is sent to the chat backend, and the backend uses a push service to reach the worker when a message arrives while the tab is closed. Message data itself normally stays on a real-time connection such as a WebSocket while the app is open; the worker handles the moments it is not.

In the Ethora ecosystem

Ethora’s web push uses Firebase Cloud Messaging delivered through a service worker: the web app registers the worker, obtains a device token, and the Ethora backend sends notifications through FCM when a new message, mention or call arrives and the user is not looking at the page. Android push goes through FCM too, iOS uses direct APNs with a .p8 key, and calls use VoIP push, so one notification pipeline covers every platform.

Push credentials are self-serve in the admin panel, so a team can add its own Firebase project without a support ticket. Shipping the web app as a progressive web app builds on the same worker, and the underlying delivery protocol is covered in the push notifications entry.