azure-sdk-for-js/samples/web-workers
Maor Leger 6b40ae5560
[samples] Update web-workers sample (#31060)
Resolves #31049 

A few changes were needed here:

1. Upgrade jsdom to >= 19 in the JS sample, similar to
https://github.com/Azure/azure-sdk-for-js/issues/20934 which fixed the
TS sample
2. Update the sample to use a SAS URL so that it can be runnable
3. Remove usage of env vars, instead using the string directly and
recommending passing a SAS URL from the server in production
2024-09-10 11:08:18 -07:00
..
js
ts
.gitignore
README.md
arm-template.json

README.md

Using the Azure SDK for JS in Web Workers

Using the Azure SDK in Node or a browser's main process is supported out of the box; however, when using the Azure SDK in other runtimes a polyfill may be necessary.

In this sample we demonstrate how to polyfill the necessary APIs for using our libraries in web workers.

Web Workers are a simple means for web content to run scripts in background threads. Please see the Web Workers MDN page for more information on Web Workers.

Known required polyfills

XML Parsing

When used in the browser, our XML parsing library relies on DOM APIs to support parsing and stringifying XML. Since the DOM APIs are generally available this reduces bundle size and minimizes our dependencies. When running from a Web Worker, however, DOM APIs are not available. This is a browser limitation and requires a polyfill before importing our client libraries in web workers.

Note: Not all client libraries use XML. When running in a web worker, our library will emit a useful error explaining what APIs are required if they are missing so that you can add them as needed.

In these samples we use JSDOM but you can use any library that provides a DOM implementation.

Prerequisites

The samples are compatible with LTS versions of Node.js.

Before running the TypeScript samples, they must be compiled to JavaScript using the TypeScript compiler. For more information on TypeScript, see the TypeScript documentation.

You need an Azure subscription and an Azure Storage Blob container to run this sample. Please refer to the Storage Blob documentation for additional information on Azure Storage Blob.

To avoid complexity in this sample, we will be using a SAS URL to authenticate our client. The ARM template we include will output a SAS URL valid for 2 hours.

To quickly create the needed resources in Azure and to receive the necessary environment variables for them, you can deploy our sample template by clicking:

Once the deployment completes, head over to the "outputs" tab and copy the outputs to a local file - you'll need them in the next step.

Running the sample

Once the above resources are created you'll want to ensure our application has the necessary values. To do this, open workers.ts (or workers.js if you are using the JavaScript sample) and set containerSasUrl to the generated SAS URL from the deployment. You can get that value from the output tab of the deployment.

Remember: we are using a connection string to keep this sample simple; however, parcel will embed the connection string into your published bundle which is not suitable for production as it may leak secrets. For production client side applications, you may be interested in the @azure/identity package which provides a set of credential implementations for both NodeJS and the browser. Alternatively, you may generate a SAS URL from your server-side component and provide it to your client at runtime.

Install the various packages as well as the TypeScript compiler using:

npm install

Run the sample app:

npm start

Parcel will bundle your application code and launch a server running at http://localhost:1234. If you navigate to that URL you'll notice that the web worker has uploaded a sample file to Azure Storage Blob and posted a message back to the main process, displayed in the development tools console tab.