WASM Bindings

[donaldcampbelljr]

A discussion thread regarding the implementation of WASM bindings for our gtars crate. Given our success with python bindings for gtars, we naturally looked at other languages where bindings would offer a benefit for user experience.

Pros and Potential Wins:

• Web browser workflows may appear more accessible to the end user (this is, of course, subjective).

• Undoubtedly, there is a "cool" factor to having some of our tools running in a browser.

Will the two items above lead to more tool adoption, especially if they are featured in future publication?

Cons and Challenges:

• In my very limited testing, it appears that the WASM code executing is a bit slower than when just using rust (I have zero evidence to back this up, just pure anecdote).

• Depending on the code we are trying to wrap with bindings, there may be a need to rewrite some of the original Rust code such that it is compatible with WASM. I recently had to do this in pilot work when creating bindings for the GlobalRefgetStore as some of the digest functions seemed incompatible with a web browser workflow.

• More feature gate-keeping will need to be implemented as a result of WASM compatibility.

Current Tools and will they benefit from WASM (WIP, please fill in)

bbcache

fragsplit

igd

• � searching an IGD struct by uploading a query bedfile in the browser could be nice for small workflows.

overlap

refget

• ✓ creating sequence collections in a browser and exporting them to a JSON as opposed to running a CLI command line, so user drops in fasta file and can save a level 2 json to disk. That could be a little more palatable for the end user for one-offs and smaller workflows.
• ❌ GlobalRefgetStore - creating one of these by ingesting multiple sequence collections into a store and saving that to disk. We also discussed hosting these stores somewhere in a DB. However this would potentially require lots of bandwidth to access seq collecitons via API which already exists in Refget and the problem the global refget store is attempting to solve is to cache these locally instead of using a lot of bandwidth calling the API. Essentially we might be replicating an existing problem instead of offering a solution.

tokenizers

uniwig

• ❌ No.

Related issues and PRs

#144
#150
#161
#162 and #148 (because we will probably need to create a workspace for proper feature gate keeping to implement WASM bindings)