WebForms Core provides a server-controlled Service Worker architecture, allowing developers to fully manage caching, routing, and offline behavior directly from the server-side code.
Unlike traditional Service Worker implementations—where logic is hardcoded on the client—WebForms Core introduces a Commander/Executor model. In this model, the server dynamically issues commands that are executed by the Service Worker in the browser.
This approach enables centralized control, easier maintenance, and dynamic runtime configuration without redeploying client-side code.
Note: To use the Service Worker, the Elanat Dedicated Service Worker Module ("service-worker.js") must be included on the client side.
A Service Worker is a background script that runs independently of the web page and acts as a programmable network proxy between the browser, the application, and the network. Its primary role is to intercept network requests, manage caching strategies, enable offline access, improve performance, and support advanced features such as background synchronization and push notifications. By operating outside the page lifecycle, a Service Worker allows web applications to remain fast, reliable, and responsive—even in unstable or offline network conditions.
The Service Worker in WebForms Core supports:
- Static and Dynamic caching
- Cache TTL (Time-To-Live) management
- Route-based cache strategies
- Wildcard and Regular Expression routing
- Route aliases
- IndexedDB-backed persistence for routes and metadata
- Full cache lifecycle management from the server
All Service Worker operations are exposed through methods on the "WebForms" class.
Registers and activates the Service Worker in the client browser.
ParametersPath: Optional custom path to the Service Worker script
ScobePath: Optional scope path for the Service Worker
Example
Adds files or paths to the Static Cache during Service Worker installation.
ParametersPathList: Array of paths to be pre-cached
Example
Adds a path to the Dynamic Cache, with optional TTL support.
ParametersPath: Target path
Seconds: Cache TTL in seconds (0 = no expiration)
Example
Removes all entries from the Dynamic Cache.
ExampleDeletes a specific path from the Dynamic Cache.
ExampleUpdates the TTL of a cached dynamic route.
ExampleDefines a route and assigns a cache strategy.
ParametersPath: Route pattern (supports wildcard and regex)
Type: Cache strategy
CacheDynamic: Store successful network responses in Dynamic Cache
Supported Path Formats
- Wildcard /images/*
- Regex: Prefix with re:
cachefirst: Cache → Network fallback
networkfirst: Network → Cache fallback
cacheonly: Cache only
networkonly: Network only
stalerevalidate: Fast cache + background update
Example (Wildcard)
Example (Regex)
Creates an alias between two routes.
ExampleDeletes a specific route alias or all aliases.
Example (Delete All Aliases) Example (Delete One Alias)Deletes all routes and aliases.
ExampleDeletes a specific route definition.
ExampleIn WebForms Core, all Service Worker operations are controlled from the server using the WebForms class. The client-side library WebFormsJS automatically executes these commands and communicates with the Service Worker through an internal RPC mechanism.
In normal scenarios, developers do not need to interact with WebFormsJS directly.
However, for initial setup and environment-specific behavior, several Service Worker–related options can be configured.
These options are defined globally using the WebFormsOptions object and are mainly responsible for registration, lifecycle handling, and optional Push Notification support.
Enables or disables automatic Service Worker registration when the page loads.
If set to false, the Service Worker will only be registered when explicitly instructed by the server.
false
RegisterServicePath
Specifies the URL path of the Service Worker script. This file must exist on the client and is typically provided by the Elanat Service Worker module.
Default:/service-worker.js
RegisterServiceScopePath
Defines the scope under which the Service Worker controls pages. Only URLs under this scope will be intercepted by the Service Worker.
Default:/
ReloadServiceWorkerIfNeed
If enabled, the page will automatically reload when a new Service Worker is installed but not yet controlling the page. This behavior is required by some browsers to activate the new Service Worker immediately.
Default:true
ServiceWorkerWaitForControl
Specifies the delay (in milliseconds) to wait after Service Worker installation before checking whether it has taken control of the page. This helps prevent race conditions during first-time registration.
Default:100
Push Notifications are optional and disabled by default. When enabled, WebFormsJS will request notification permission and register the user for push messages using the Service Worker.
UseServiceWorkerPushEnables Service Worker–based Push Notifications.
Default:false
UseServiceWorkerPushSubscribe
Specifies the server endpoint used to send the Push Subscription object. The subscription data is sent as JSON using an HTTP POST request.
Default:/subscribe
ServiceWorkerPushVapidPublicKey
Defines the VAPID public key required for Web Push authentication. This key must match the private key used on the server to send push messages.
- WebFormsJS automatically converts server-side Service Worker commands into RPC calls.
- Developers should avoid directly calling browser Service Worker APIs.
- All cache, routing, and lifecycle logic must be handled on the server using the WebForms class.
- Client-side configuration exists only for initialization and environment control.
WebForms Core introduces a server-driven Service Worker architecture that fundamentally changes how offline behavior, caching, and routing are managed in web applications.
- The Service Worker is fully controlled by the server through explicit commands, not hardcoded client logic.
- Routes, cache strategies, and aliases are persisted in IndexedDB, ensuring consistency across reloads and updates.
- Dynamic Cache entries can be assigned a Time-To-Live (TTL), managed via a dedicated Meta Cache.
- Routing supports exact paths, wildcards, and regular expressions, enabling advanced request interception.
- Alias routing allows paths to be remapped dynamically without modifying client code.
- Successful network responses can be optionally stored in the Dynamic Cache based on route configuration.
- All communication between the page and the Service Worker is handled through a secure RPC channel.
- The client-side library (WebFormsJS) acts only as an executor, while the server remains the single source of truth.
- No external frameworks (such as Workbox) are required, keeping the Service Worker lightweight and transparent.
This design allows WebForms Core to deliver PWA-grade functionality—including offline support, intelligent caching, and push notifications—while preserving the clarity, scalability, and maintainability of a true server-centric architecture.
