Sharing logic between desktop and web based applications through WASM
an invention by IGonzalezSosa
Updated over 4 years ago. 8 hacker ♥️. 7 followers.

Project Description

A few months ago, the YaST team released cockpit-wicked. Compared to YaST, this module contains a pretty simple data model, but there is still some duplication with YaST logic.

The idea of this project is to write some simple logic and try to reuse the same code from a YaST-like application and a web-based one (like Cockpit). Here is the (over-simplified) plan:

  • Write a simple model that represents the network configuration (most probably, in Rust).
  • Compile the model to WASM and try to use it from cockpit-wicked.
  • Build a desktop/console UI that relies on this model too.

Goal for this Hackweek

To be honest, we do not plan to finish this project in a single week. However, we would like to achieve these goals:

  • Find out how realistic is the overall approach (reusing logic in WASM and desktop apps). Try to identify threats and missing pieces.
  • Learn the basics about WASM.
  • Explore a GUI/TUI toolkit different from libyui that allows us to write some async code. We are not limited to Rust for this part.

Resources

Runtimes

Review

You can find the outcome of this project in the y3network repository.

Looking for hackers with the skills:

yast cockpit wasm web systemsmanagement networking rust

This project is part of:

Hack Week 20

Activity

  • over 4 years ago: joseivanlopez joined this project.
  • over 4 years ago: mvidner liked this project.
  • over 4 years ago: mkoutny liked this project.
  • over 4 years ago: locilka liked this project.
  • over 4 years ago: mbrugger liked this project.
  • almost 5 years ago: aplanas liked this project.
  • almost 5 years ago: ancorgs liked this project.
  • almost 5 years ago: teclator joined this project.
  • almost 5 years ago: dgdavid joined this project.
  • almost 5 years ago: cfconrad liked this project.
  • almost 5 years ago: IGonzalezSosa added keyword "rust" to this project.
  • almost 5 years ago: teclator liked this project.
  • almost 5 years ago: ancorgs joined this project.
  • almost 5 years ago: IGonzalezSosa added keyword "web" to this project.
  • almost 5 years ago: IGonzalezSosa added keyword "systemsmanagement" to this project.
  • almost 5 years ago: IGonzalezSosa added keyword "networking" to this project.
  • almost 5 years ago: IGonzalezSosa added keyword "yast" to this project.
  • almost 5 years ago: IGonzalezSosa added keyword "cockpit" to this project.
  • almost 5 years ago: IGonzalezSosa added keyword "wasm" to this project.
  • almost 5 years ago: IGonzalezSosa started this project.
  • almost 5 years ago: IGonzalezSosa originated this project.


    • Comments

    • bmwiedemann
      almost 5 years ago by bmwiedemann | Reply

      On the topic of WASM and shared code: https://webperl.zero-g.net/

    • ancorgs
      almost 5 years ago by ancorgs | Reply

      Regarding the "explore a GUI/TUI toolkit different from libyui" and thinking about how to make this project useful for the YaST mid-term, I would like to explore https://github.com/AndyObtiva/glimmer-dsl-tk

    • ancorgs
      over 4 years ago by ancorgs | Reply

      I have focused my experiments in two areas:

      1) Developing a really interactive GUI with Ruby (intentionally avoiding libyui).

      In that regard, I found the Observer and data-binding implementations of Glimmer to be really convenient and straightforward to use. See my experiments at ancorgs/y3network-ruby-ui.

      2) Interfacing WASM with Ruby and/or Python (no browser involved)

      The results in this area were discouraging. In theory WASM should be able to communicate back and forward with Javascript when running in a browser and with any "host" language (let's call it that way) when running out of the browser, inside a "native" WASM runtime. But that communication is limited to passing integers and floats. Anything more advanced (like a string or any structured data) needs extra mechanisms on top that are understood by both the code running in WASM (Rust in our case) and its caller (Ruby/Python/Javascript).

      For the browser, we used wasm-bindgen to interface the WASM code written in Rust with Javascript. That works pretty well, but is useless (even counterproductive) to connect the resulting WASM to any other "host" language. See below.

      In Ruby I tried to use both Wasmer and Wasmtime as runtimes. But wasmer-ruby is in the middle of a major rewrite and is basically unusable with recent versions of Wasmer and/or Ruby. On the other hand, wasmtime-ruby is very basic, lacking basically all features that would be useful for a good integration.

      Integration of Python with both Wasmer and Wastime is much better and more mature. But still the current limits of WASM regarding interfacing with the outer world are a huge limiting factor. These are the three solutions I explored:

      2.1) Using WASM Interface Types, which is expected to become the standard multi-language mechanism to do what we wanted. But it's currently far from being a real option. In the Rust=>WASM side, wasm-bindgen could be used to generate the corresponding specification... but it only worked with an old version. Even that was useless because we couldn't use the Interface Types from the Python or Ruby side. Wasmer has never supported it. Wasmtime supported it for some time but now they dropped the support.

      2.2) Reusing what wasm-bingen generated for the communication with Javascript by writing some connectors in Python that are equivalent to the Javascript ones auto-generated by wasm-bingen. It's not trivial and there is absolutely no guarantee it will keep working. wasm-bingen is a pure Rust<-WASM->Javascript solution with no interest in making it easy (or even possible) to reuse their mechanisms for/from other languages.

      2.3) Handcrafting a mechanism to pass a string in which we could even serialize more complex data. That would be similar to this example that uses C++ in the WASM side and Javascript outside. Valid as a proof of concept, but definitely not a real solution in the mid-term.

    • ancorgs
      over 4 years ago by ancorgs | Reply

      > wasm-bindgen could be used to generate the corresponding specification

      I meant wasm-pack

    Similar Projects

    openSUSE on ZoL from OpenZFS project by jkohoutek

    Idea is to have SUSE system with OpenZFS as root FS.

    Why ZFS

    Ways in which ZFS is better than BTRFS

    Main goal

    Have OpenZFS as install option in the installer and utilize zedenv Boot Environment Manager for SUSE updates install

    Goals

    • synergy of ZFS with dracut, so snapshots are correctly added to the grub
    • synergy of zedenv with zypper
      • before every update snapshot is created
      • when new kernel or other package which requires reboot is about to be installed, the update will be processed to the new boot environment snapshot and grub configuration changed to boot to this new one
    • integrate Root on ZFS as install option to the YaST
    • configure Kiwi for the ZFS install images

    Completed goals

    • prepare ZFS pool compatible with openSUSE installation ✓
    • install openSUSE with root on ZFS ✓
    • boot to the prepared and installed system ✓

    Current progress

    Resources:

    Bring to Cockpit + System Roles capabilities from YAST by miguelpc

    Bring to Cockpit + System Roles features from YAST

    Cockpit and System Roles have been added to SLES 16 There are several capabilities in YAST that are not yet present in Cockpit and System Roles We will follow the principle of "automate first, UI later" being System Roles the automation component and Cockpit the UI one.

    Goals

    The idea is to implement service configuration in System Roles and then add an UI to manage these in Cockpit. For some capabilities it will be required to have an specific Cockpit Module as they will interact with a reasource already configured.

    Resources

    A plan on capabilities missing and suggested implementation is available here: https://docs.google.com/spreadsheets/d/1ZhX-Ip9MKJNeKSYV3bSZG4Qc5giuY7XSV0U61Ecu9lo/edit

    Linux System Roles:

    First meeting Hackweek catchup

    Updatecli Autodiscovery supporting WASM plugins by olblak

    Description

    Updatecli is a Golang Update policy engine that allow to write Update policies in YAML manifest. Updatecli already has a plugin ecosystem for common update strategies such as automating Dockerfile or Kubernetes manifest from Git repositories.

    This is what we call autodiscovery where Updatecli generate manifest and apply them dynamically based on some context.

    Obviously, the Updatecli project doesn't accept plugins specific to an organization.

    I saw project using different languages such as python, C#, or JS to generate those manifest.

    It would be great to be able to share and reuse those specific plugins

    During the HackWeek, I'll hang on the Updatecli matrix channel

    https://matrix.to/#/#Updatecli_community:gitter.im

    Goals

    Implement autodiscovery plugins using WASM. I am planning to experiment with https://github.com/extism/extism

    To build a simple WASM autodiscovery plugin and run it from Updatecli

    Resources

    • https://github.com/extism/extism
    • https://github.com/updatecli/updatecli
    • https://www.updatecli.io/docs/core/autodiscovery/
    • https://matrix.to/#/#Updatecli_community:gitter.im

    OpenRC in openSUSE by jimedrand

    Description

    I have been using openSUSE for 3 years and I am just seen the systemd as init system. Actually, I want to make openSUSE with supports to another init such as OpenRC init that I'm always using it in another distros, and I was think, "what about if I'm including OpenRC init in openSUSE and give anyone as second way for them who don't want to use systemd?", and I'm curious about that. That's why I'm opening these.

    Goals

    Giving OpenRC support for Tumbleweed first, then going in Leap in future if possible.

    Exploring Rust's potential: from basics to security by sferracci

    Description

    This project aims to conduct a focused investigation and practical application of the Rust programming language, with a specific emphasis on its security model. A key component will be identifying and understanding the most common vulnerabilities that can be found in Rust code.

    Goals

    Achieve a beginner/intermediate level of proficiency in writing Rust code. This will be measured by trying to solve LeetCode problems focusing on common data structures and algorithms. Study Rust vulnerabilities and learning best practices to avoid them.

    Resources

    Rust book: https://doc.rust-lang.org/book/

    RMT.rs: High-Performance Registration Path for RMT using Rust by gbasso

    Description

    The SUSE Repository Mirroring Tool (RMT) is a critical component for managing software updates and subscriptions, especially for our Public Cloud Team (PCT). In a cloud environment, hundreds or even thousands of new SUSE instances (VPS/EC2) can be provisioned simultaneously. Each new instance attempts to register against an RMT server, creating a "thundering herd" scenario.

    We have observed that the current RMT server, written in Ruby, faces performance issues under this high-concurrency registration load. This can lead to request overhead, slow registration times, and outright registration failures, delaying the readiness of new cloud instances.

    This Hackweek project aims to explore a solution by re-implementing the performance-critical registration path in Rust. The goal is to leverage Rust's high performance, memory safety, and first-class concurrency handling to create an alternative registration endpoint that is fast, reliable, and can gracefully manage massive, simultaneous request spikes.

    The new Rust module will be integrated into the existing RMT Ruby application, allowing us to directly compare the performance of both implementations.

    Goals

    The primary objective is to build and benchmark a high-performance Rust-based alternative for the RMT server registration endpoint.

    Key goals for the week:

    1. Analyze & Identify: Dive into the SUSE/rmt Ruby codebase to identify and map out the exact critical path for server registration (e.g., controllers, services, database interactions).
    2. Develop in Rust: Implement a functionally equivalent version of this registration logic in Rust.
    3. Integrate: Explore and implement a method for Ruby/Rust integration to "hot-wire" the new Rust module into the RMT application. This may involve using FFI, or libraries like rb-sys or magnus.
    4. Benchmark: Create a benchmarking script (e.g., using k6, ab, or a custom tool) that simulates the high-concurrency registration load from thousands of clients.
    5. Compare & Present: Conduct a comparative performance analysis (requests per second, latency, success/error rates, CPU/memory usage) between the original Ruby path and the new Rust path. The deliverable will be this data and a summary of the findings.

    Resources

    • RMT Source Code (Ruby):
      • https://github.com/SUSE/rmt
    • RMT Documentation:
      • https://documentation.suse.com/sles/15-SP7/html/SLES-all/book-rmt.html
    • Tooling & Stacks:
      • RMT/Ruby development environment (for running the base RMT)
      • Rust development environment (rustup, cargo)
    • Potential Integration Libraries:
      • rb-sys: https://github.com/oxidize-rb/rb-sys
      • Magnus: https://github.com/matsadler/magnus
    • Benchmarking Tools:
      • k6 (https://k6.io/)
      • ab (ApacheBench)

    Mail client with mailing list workflow support in Rust by acervesato

    Description

    To create a mail user interface using Rust programming language, supporting mailing list patches workflow. I know, aerc is already there, but I would like to create something simpler, without integrated protocols. Just a plain user interface that is using some crates to read and create emails which are fetched and sent via external tools.

    I already know Rust, but not the async support, which is needed in this case in order to handle events inside the mail folder and to send notifications.

    Goals

    • simple user interface in the style of aerc, with some vim keybindings for motions and search
    • automatic run of external tools (like mbsync) for checking emails
    • automatic run commands for notifications
    • apply patch set from ML
    • tree-sitter support with styles

    Resources

    • ratatui: user interface (https://ratatui.rs/)
    • notify: folder watcher (https://docs.rs/notify/latest/notify/)
    • mail-parser: parser for emails (https://crates.io/crates/mail-parser)
    • mail-builder: create emails in proper format (https://docs.rs/mail-builder/latest/mail_builder/)
    • gitpatch: ML support (https://crates.io/crates/gitpatch)
    • tree-sitter-rust: support for mail format (https://crates.io/crates/tree-sitter)

    OpenPlatform Self-Service Portal by tmuntan1

    Description

    In SUSE IT, we developed an internal developer platform for our engineers using SUSE technologies such as RKE2, SUSE Virtualization, and Rancher. While it works well for our existing users, the onboarding process could be better.

    To improve our customer experience, I would like to build a self-service portal to make it easy for people to accomplish common actions. To get started, I would have the portal create Jira SD tickets for our customers to have better information in our tickets, but eventually I want to add automation to reduce our workload.

    Goals

    • Build a frontend website (Angular) that helps customers create Jira SD tickets.
    • Build a backend (Rust with Axum) for the backend, which would do all the hard work for the frontend.

    Resources

    Learn a bit of embedded programming with Rust in a micro:bit v2 by aplanas

    Description

    micro:bit is a small single board computer with a ARM Cortex-M4 with the FPU extension, with a very constrain amount of memory and a bunch of sensors and leds.

    The board is very well documented, with schematics and code for all the features available, so is an excellent platform for learning embedded programming.

    Rust is a system programming language that can generate ARM code, and has crates (libraries) to access the micro:bit hardware. There is plenty documentation about how to make small programs that will run in the micro:bit.

    Goals

    Start learning about embedded programming in Rust, and maybe make some code to the small KS4036F Robot car from keyestudio.

    Resources

    Diary

    Day 1

    • Start reading https://mb2.implrust.com/abstraction-layers.html
    • Prepare the dev environment (cross compiler, probe-rs)
    • Flash first code in the board (blinky led)
    • Checking differences between BSP and HAL
    • Compile and install a more complex example, with stack protection
    • Reading about the simplicity of xtask, as alias for workspace execution
    • Reading the CPP code of the official micro:bit libraries. They have a font!

    Day 2

    • There are multiple BSP for the microbit. One is using async code for non-blocking operations
    • Download and study a bit the API for microbit-v2, the nRF official crate
    • Take a look of the KS4036F programming, seems that the communication is multiplexed via I2C
    • The motor speed can be selected via PWM (pulse with modulation): power it longer (high frequency), and it will increase the speed
    • Scrolling some text
    • Debug by printing! defmt is a crate that can be used with probe-rs to emit logs
    • Start reading input from the board: buttons
    • The logo can be touched and detected as a floating point value

    Day 3

    • A bit confused how to read the float value from a pin