Service workers are JavaScript assets that work as proxies between web browsers and web applications. Since it runs on a different thread, running it in the background without affecting the main JavaScript is easy. You can also have offline network experiences with service worker JavaScript and cache any request/response pair with a service worker and cache API. Once complete, you can access the offline content whenever you want. Service worker JS works best when you use it to send notifications and track network traffic.
The lifecycle of a JS service worker has three steps:
- Registration
- Installation
- Activation
While registering the service worker JS with the “register” function, you can decide the scope or the path from which it can intercept network calls. It will be activated when the user tries to access the page that falls under its scope. It is an event-driven worker. So events dispatched to the worker at different stages of its lifecycle triggering specific actions.
Service worker is compatible with all modern web browsers like Chrome, Opera, Firefox, Edge, and Android. It is mainly used in caching and background sync-related use cases but it can be equally effective in edge computing use cases. With just a piece of code in the service worker, you can bring the execution of functionality from the server side to the client side.
Let me share some edge computing use cases where service workers can be potentially useful.
Edge computing use cases with JS service worker
Edge computing processes the data near where it is generated. It has some unique advantages like improving how companies manage and use physical assets and creating new interactive experiences. Edge computing reduces end users’ latency: some of its top use cases are self-driving cars, smart equipment data, autonomous robots, etc.
Here are two edge computing use cases where you will be able to understand how JS service worker functions in detail.
- Service worker JS in AI/ML:
Applications that involve AI/ML inferencing can be a good use case as service worker JS API can help you there. Loading the ML model and using it in the browser (closed to the user) rather than on a centralized server can improve AI/ML application performance. Also, by using it, you can keep the inferencing in the service worker and execute it in the browser. It will reduce the application server load.
Let’s take the example of a barcode scanner. It involves initializing the barcode scanner, adding the required scan settings, and then using the barcode data to get the results. Once you register the service worker in the browser, every time you get the barcode data, you can use the “message” event (part of the service worker API) to send the scan settings and barcode data to the service worker. There, you can write the logic to extract the barcode results. The service worker JS performs post-inferencing logic like filtering or sending the data to a server.
The service worker API JS also has a few more events like installing, activating, and fetching to perform operations.
- Service worker JS in data reporting applications:
You may have come across applications where you send the data from the browser to the server for analysis. In such cases, reporting in the browser instead of a centralized server can significantly improve the app’s performance.
Browser event processing, like CSP violation events and NavigateEvent processing, can also be implemented in the service worker JS. In CSP violation reporting, you can send the report to the server to analyze the violation on the web page. Then, you can extract the violation data from the CSP violation event and send it to the service worker using the “message” event.
You can register a service worker JS in the browser while loading the web page for the first time and wait till it get activated. Then, every time a violation event occurs on the web page, a message event is sent to the service worker with the violation data, which can be assembled in the required format and sent to the server using the fetch API.
When you do CSP violation reporting, sometimes you need to filter out noise (violations caused by browser extensions and not related to the web page) to reduce load on the server. Service worker can filter it easily without affecting the page’s performance.
What to know before using/dealing with the service worker JS?
Before you decide to add service worker JS to the application, just keep few things in mind.
- A bugged service worker in the browser can stop you from updating both new and old instance. Uninstalling it is the only way out. To avoid this, do plenty of unit tests to verify your service worker is functioning properly.
- When the service worker is in the background, the browser will ask for the service worker code many times. Keep the large code out of the worker to let it function without glitches. You can keep the code in separate files, which you can import later using importScripts into the main service worker file.
- As developers, you must be aware of the abuse of service worker and exercise caution when developing applications. The service worker can modify the response and use the service worker API in phishing or defacement attacks in the application. An attacker can modify the response to navigate the user to a malicious server by changing the URL or deny the service by sending a 404 error.
- Also, applications that use the sandboxed domains to store data like images, audio, videos, scripts, etc., are easy targets of service worker abuse. Such applications store the data in sandboxed domains to isolate user-uploaded content from the main application.
As sandboxed domains are usually designed to hold uploaded content, a malicious service worker can easily be uploaded. Then, by using XSS (cross-site scripting), the attacker can register the service worker. When the user attempts to preview content from the sandboxed domain, he unknowingly activates the service worker and it modifies the response.
To mitigate such attacks, the scope of the service worker JS plays a crucial role here. Service worker JS only intercepts requests originating within the scope of the current directory where the service worker script is located. If the maliciously uploaded service worker resides deeper in the file hierarchy then the page which attacker wants to inspect, won’t be impacted.
By picking a unique path hierarchy for every file in the sandboxed domain and trying to include timestamps or random strings in the filename, you can reduce the impact of attacks on the application.
Conclusion
Service worker JS in edge computing use cases can improve performance by executing functionality in the browser. It’s better in this way than a centralized server.
But when it comes to offline experience, it doesn’t help much with caching or background sync-related applications. Among other drawbacks, you must be careful while writing scripts as responses can easily be modified using the service worker, which hackers can leverage to create ruckus for application developers. These drawbacks make it imperative for you to consider functionalities in mainstream applications before finalizing your move to service worker JS to optimize performance.
You May Also Interested in: Applications of Edge Computing
References
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
https://web.dev/learn/pwa/service-workers/
https://medium.com/bliblidotcom-techblog/introduction-to-the-service-worker-3c986d9a996d
https://www.akamai.com/blog/security/abusing-the-service-workers-api
