#reactor #web-worker #yew #send-receive #action #front-end #queuing

ratio-reactor

Setup WebWorkers as queueing job shop reactors in Yew WASM applications with different strategies

6 releases (3 breaking)

new 0.4.0 May 24, 2024
0.3.0 Jan 8, 2024
0.2.1 Jan 8, 2024
0.2.0 Dec 26, 2023
0.1.1 Dec 23, 2023

#458 in WebAssembly

Download history 56/week @ 2024-02-23 11/week @ 2024-03-01

344 downloads per month

MIT/Apache

34KB
730 lines

Ratio Reactor

Queueing job shop reactors for use with Yew based and on the official yew-agent crate. Different reactors are included for different queuing strategies, because both waiting and data races suck!

What is a Reactor?

What does a reactor do? A reactor is a bi-directional WebWorker implementation that can send and receive messages and perform actions off of the main thread in your browser. Or in yew-agent's terms:

A kind of agent that can send many inputs and receive many outputs over a single bridge.

Which means you can depend on the outputs of such a worker in your frontend, too!

Why queueing strategies?

A typical workflow would be to write your Yew app as usual, but implement certain heavy tasks in a WebWorker. You might want to just do "calculate-thing" as a "oneshot" that updates your state, but what happens when you fire many such messages shortly after each other? Which call or result is "the boss"? What is returned and should you update the UI for every call?

And what if you would like to know what your worker's status is display that in your app? Is the worker busy? How busy? Many jobs waiting or just a single one? Can you categorize jobs, too?

Queueing strategies

The following strategies are supported as of now:

  • FIFO queue
    • All jobs are executed in the order of arrival
  • Skip waiting
    • New jobs that arrive while executing replace any waiting job
  • Immediate switching
    • Quit current job on new arrival and work on that

Categorized keys

Both the FIFO and skip queue support "categorized keys", meaning that you can apply these strategies "in-parallel" for different jobs and priorities. Code execution won't be truly parallel per-se, but the reactor will keep a record of the strategy for each unique key such that all jobs tagged with a certain key follow the proposed strategy independent from each other.

Examples!

The examples directory contains several rudimentary examples that showcase the context of the different reactor strategies.

Dependencies

~12–16MB
~289K SLoC