Accessing Worker URL

I created a worker to be used as a websocket server. How do I get the url from this componnent to connect since it doesnt give me one? PS: Both Webservice and worker are in the same APP.


Submit an answer
You can type!ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

You can run whatever code you like inside the worker thread, with some exceptions. For example, you can’t directly manipulate the DOM from inside a worker, or use some default methods and properties of the window object. But you can use a large number of items available under window, including WebSockets, and data storage mechanisms like IndexedDB. See Functions and classes available to workers for more details.

Data is sent between workers and the main thread via a system of messages — both sides send their messages using the postMessage() method, and respond to messages via the onmessage event handler (the message is contained within the Message event’s data attribute.) The data is copied rather than shared.

Workers may, in turn, spawn new workers, as long as those workers are hosted within the same origin as the parent page. In addition, workers may use XMLHttpRequest for network I/O, with the exception that the responseXML and channel attributes on XMLHttpRequest always return null.

The worker component does not express a URL for inbound connections. It is designed to connect outwardly to other services in the app, or to external sources (like a queue or database).

For your websocket server it seems like you’re probably best served by adding a second service. You can connect to that service from other services, jobs, and workers using its component name as a url (ex. http://websocket-service/ or ws://websocket-service:80/ for websockets). We have work in progress to add internal services which don’t require a public route path and can listen on arbitrary ports. Unless we discover any quality or usability concerns, we expect that internal-service functionality to be released very soon.