-
|
Hi, I'm exploring crux as a potential mind shift. Is there any relationship between crux core/shell and the web workers in web/wasm deployment? Consider that the app does some heavy lifting. The main/UI thread should not be burdened by that to remain snappy. The logical resolution is to put the heavy lifting into a web worker. Would the crux app core then run in a web worker? Or would the heavy lifting have to become part of the shell (which should be thin). Any examples of using web workers with crux? Thank you |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
Hi @jocutajar Not a core team member here, but I'm currently working on a project that is fully based on Crux. With our use case, I have created a package (see crux-wrapper ) that allows wrapping your core for a React app and gives some extra features on top of it (like the ability to On top of that it also helps with running the core in a worker (documented here https://github.com/atomrc/crux-wrapper/tree/main/lib/crux-wrapper#running-your-crux-app-in-a-web-worker). Even without using the wrapper I wrote, it's still pretty easy to run your core in a worker and leave the main thread free to do other operations. // webworker.ts
import type { Endpoint } from "comlink";
import { expose } from "comlink";
import init, { handle_response, process_event, view } from "core";
import wasmPath from "core/core_bg.wasm?url";
const api = {
// The worker just has to define a function that will trigger the loading of the wasm module
init: async () => {
await init({ module_or_path: wasmPath });
},
process_event,
handle_response,
view,
};
export type CoreWorkerApi = typeof api;
expose(api, self as Endpoint);and then from your source file, you can do const worker = wrap<CoreWorkerApi>(
new Worker(new URL("./webworker.ts", import.meta.url), {
type: "module",
}),
);
const effects = worker.process_event(new YourCruxEvent());So it should be very lightweight to implement :) Hope this helped |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot @atomrc , meanwhile I explored and figured out a way to run the crux app in a worker with gloo_worker. Leptos for the UI means rust on both sides, so trivial integration. I will benefit from a React example tough. Not everyone is comfy with rust frontend development. In conclusion, thanks for the confirmation: Yes, put the crux app in a worker. UI on main with some message passing translation. We've had a comlink RPC for a web worker, but I found the RPC too noisy to debug. Since crux is just message passing and worker is message passing, it is best to map the crux messages directly to worker messages - iow, no RPC on top of message passing. |
Beta Was this translation helpful? Give feedback.
Hi @jocutajar
Not a core team member here, but I'm currently working on a project that is fully based on Crux.
We currently run our entire core in a web worker, and that works fantastically well :)
With our use case, I have created a package (see crux-wrapper ) that allows wrapping your core for a React app and gives some extra features on top of it (like the ability to
awaitevents and a logger that allows tracking of all the event => effects and the timing for each).On top of that it also helps with running the core in a worker (documented here https://github.com/atomrc/crux-wrapper/tree/main/lib/crux-wrapper#running-your-crux-app-in-a-web-worker).
Even without using the wrapper I wrot…