Web worker and js api modules

[MichalGasparovic]

Hi, 

I've recently mucked around the webworkers and tried to make that thing up and running. Even though I'd rather use the service workers, our clients don't have the latest browsers so we have to go with web workers. I've found that /support/workers module to be really great, but I've hit the wall once I've started using the modules in it and the problem is the sheer number of requests being pulled for the worker which was insane.

To put this into perspective, the following modules caused ~530 requests ( ! ) and that itself took around 20seconds to finish, which kind of beats the whole purpose of having a worker doing something quick. Once initialized, it worked a treat but that init time is shocking.

        'esri/core/promiseUtils',
        'esri/layers/ElevationLayer',
        'esri/geometry/Extent',
        'dojo/Deferred'

The task I was facing was a processor intensive process of querying a large number of geometries from the elevationSampler and that was blocking the UI. So I went through couple of stages 

1) serialize the elevationSampler and provide it to worker. This didn't work as there was no way I could instantiate the ElevationSampler as its two provided classes cannot be easily instantiated and provided with the basic data.
2) so after step 1 proved to be a no-go, I've decided to provide the URL of the elevation layer to worker, and the worker loaded the ElevationLayer and created the sampler and do the calcs. This worked, but the problem is described above, the number of requests was way too large.

3) I've ended up querying the elevations in the main thread, but offset some further, non-esri calculations into the worker.

Question is:

Is there a way to provide an esri bundle or how could I cut down the number of requests while still maintaining the number of modules I would like to pull?

Thank you

[ReneRubalcava]

If you're using JSAPI modules in the worker, you'll need to a build for them to be used. We haven't really talked about this too much, as it's a bit more advanced and requires more steps if you want to utilize API modules in workers.

You can look how we do this in a dojo build profile in this repo.

jsapi-resources/build.profile.js at master · Esri/jsapi-resources · GitHub 

We create a layer file the FeatureLayer worker and many other files that we use in workers. You can do this for ElevationLayer or maybe your own module that is using the workers and use it that way.

[MichalGasparovic]

Hi Rene, thanks for the response.

That's something I was hoping for but opens the Pandora's box at the same time

First of all, I can't use my webpack as I'm using the latest Angular cli and this would require me to eject the cli to expose the webpack. That's not an option for me. However, what I can do is to spin off another little project (like that demo of yours) and get that one to build the js api I need for the worker.

I do have a question though, how do I tell the worker to pull this library for me? Let's consider the scenario I'm using the esri-loader that loads the js api from the server 4.8 for the main application. Once I spin off the worker, how can I tell the worker to pull this module from this package? 

Do I have to add the packages info for the dojoConfig for the esri-loader and then I'll later on load from that package?

Btw, that build process looks like nightmare so hopefully it will be relatively ok

Thanks!

[ReneRubalcava]

You can configure the workers in the API to pull modules from a different location. We show how to do that with the webpack-plugin.

GitHub - Esri/arcgis-webpack-plugin: Webpack plugin for the ArcGIS API for JavaScript 

Since the workers run in their own little state, they don't need to come from the same location as the rest of your application.