Releases: Starcounter/StarcounterClientFiles
Service Workers
This release adds a built-in Service Worker to the Starcounter app shell. The service worker is used for client-side caching of the static resources. Every static file will be cached in the web browser after it is fetched for the first time. This results in performance benefits for the consecutive page loads. The development of this feature was tracked in the issue: #111
Caching strategy
The service worker stores all resources that meet the criteria (see below) in a browser cache. The browser cache is identified by a cache key that is assigned by the Starcounter middleware which serves the App Shell.
Our strategy of storing resources in the cache is lazy-loading. When a resource is requested, and it is not present in the cache, the request goes to the network and the response is cached. The next request for the same resource is responded from the cache.
When the Starcounter static file server detects a change of a static resource, it invalidates the cache key. On a next page load, the client will detect the new cache key in place ofthe old one, upgrade the service worker with the new key (browser deletes the old cache at that time) and reload that page for a fresh start.
This strategy was inspired by the one used in Create React App, though Starcounter does not use React.
The size of the cache is not limited by the spec. Each web browser has their own cache size limit, but it might be assumed to be 50 MB, sometimes with prompts for exceeding 5 MB. See this Stack Overflow question for details.
The current implementation uses a single cache for all resources, so it is possible that this quota will be reached if an app serves many static files. We have a plan to use multiple caches to prevent that.
Client (web browser) compatibility
Service workers work with any modern web browser, including Chrome, Firefox, Safari, and Edge. Check out the compatibility table for details: https://caniuse.com/#feat=serviceworkers
If a web browser does not support service worker, the client will fall back to requesting static resources based on the caching rules expressed in the HTTP headers.
Server (web host) compatibility
If you are using HTTP, service workers only work under localhost hostname.
To support any other hostnames, using HTTPS via reverse proxy is required.
If the above conditions are not met, the service worker is not installed by the browser and the client will fall back to requesting static resources based on the caching rules expressed in the HTTP headers.
If a Starcounter solution of apps is configured to serve multiple web sites under different hostnames from the same database, each hostname is regarded by the web browser as a separate cache scope. The hostnames are isolated from each other and will have their caches populated independently. You will recognize that the same cache key is used by every hostname, however, this is purely cosmetic.
Caching criteria
An HTTP response is cached in the service worker if:
- The URL appears to end with a file extension that is 2 to 5 characters long. Eg.
file.mp3. - The resource is a merged HTML view template, i.e. the URL pathname equals
/sc/htmlmerger. Eg.http://localhost/sc/htmlmerger?someparams.
The criteria for deciding whether a URI response will be cached can be seen in JavaScript code here.
Any file that doesn't meet the criteria above is not cached. Such as http://localhost/my-file-that-does-not-have-extension or http://localhost/mydatagenerator?name=John.
Opt-out from the service worker
As an app developer, the only way to opt-out for a resource being cached in the service worker is to change the URL to not match the criteria listed above.
As a solution owner, it is possible to opt-out from using service worker entirely by following the instruction below.
Disable service worker
If you need to disable service worker permanently for all clients in your Starcounter installation, replace the file %StarcounterBin%\ClientFiles\StaticFiles\sys\app-shell\app-shell.html with the contents from app-shell-without-service-worker.html file that can be found in the same folder. It is recommended to back up the original app-shell.html file before doing this.
For users who already installed your now-removed service worker, the code in app-shell-without-service-worker.html will actively remove any service worker registrations they might have in their browsers and the cache will be invalidated.
Console messages
The service worker logs a message in the browser's dev console at every page load, informing about the interesting events that have occurred. This helps the developers to debug any service-worker-related problems if they occur. All the messages are formatted in a dimmed warm distinctive color, so you can easily dismiss those messages when you're looking for the console messages of your code and not the service worker's.
Service Worker release candidate 1
See https://github.com/Starcounter/StarcounterClientFiles/releases/tag/3.26.0 for final release notes
Service Worker release candidate 0
See https://github.com/Starcounter/StarcounterClientFiles/releases/tag/3.26.0 for final release notes
Palindrom network API improvements and MyGet
Library updates:
- Palindrom/Palindrom@v6.0.0 (from 5.2.0)
- Palindrom/Palindrom@v6.0.1 (from 5.2.0)
In this release, we have moved StarcounterClientFiles from MyGet to NuGet.
Palindrom improvement for handling 4xx error pages
Update components for the new simple composition editor
Update starcounter-include to 5.3.0
Bower updates
3.20.0
3.19.0
- palindrom-client#7.1.1 to palindrom-client#7.2.0
- Reset state behavior changed
- uniform.css#0.5.5 to uniform.css#0.8.0
- New sizing behavior of
uni-form-item, - Ability to make anchors look like buttons,
- Removed support for .uni-label-control,
- Use relative path to uniform.css in uni-data-table,
- Fix uniform.css path in uni-data-table
- New sizing behavior of
- vaadin-grid#5.10.0 to vaadin-grid#5.2.1
- Fix data-binding problem vaadin/vaadin-grid#1468
- vaadin-checkbox#2.2.2 to vaadin-checkbox#2.2.3
- vaadin-lumo-styles#1.2.0 to vaadin-lumo-styles#1.3.1