Ratio Reactor

Queueing job shop reactors for use with Rust web frameworks such as Yew. It is based on the gloo-worker 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 gloo-worker'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.

Contributions

Contributions are welcome! By submitting a contribution, you agree to license your work under the terms of the Mozilla Public License 2.0. Please ensure that your contributions adhere to the existing code style and include appropriate tests and documentation where applicable.

To get started:

1. Fork the repo
2. Create a new branch
3. Make your changes
4. Make sure you run just fix to adhere to the project's formatting
5. Submit a merge request with a clear description of the changes

Licensing

This project is licensed under the Mozilla Public License 2.0. You are free to use, modify, and distribute this code, provided that any files you modify or create that are based on MPL-licensed files also remain under the MPL. You must include a copy of the license with the source and make the source code available when distributing binaries.

See the LICENSE file for the full license text.

Code examples both in the docstrings and rendered documentation thereof are free to use!

At Ratio, we are huge supporters of open-source code and the open-source community. In our Python projects we usually strive to use one of the (L)GPL flavors. These are difficult to pair with compiled codebases, however, which is where we see the MPL-2.0 as a great fit for our open-source Rust efforts. It's a weak copyleft license that just protects the source as it is written and encourages changes to the crate's source to be published accordingly. It's sort of "automagically" implied and done right when cargo would pull in the source files to build with, as (the mentioning of) the license is included in the header of each file, and any binaries you generate with them are not of our concern from a distribution perspective.

Enjoy the code!