WAGI: WebAssembly Gateway Interface

Overview

WAGI: WebAssembly Gateway Interface

WAGI is the easiest way to get started writing WebAssembly microservices and web apps.

WARNING: This is experimental code. It is not considered production-grade by its developers, neither is it "supported" software.

DeisLabs is experimenting with many WASM technologies right now. This is one of a multitude of projects (including Krustlet) designed to test the limits of WebAssembly as a cloud-based runtime.

tl;dr

WAGI allows you to run WebAssembly WASI binaries as HTTP handlers. Write a "command line" application that prints a few headers, and compile it to WASM32-WASI. Add an entry to the modules.toml matching URL to WASM module. That's it.

You can use any programming language that can compile to WASM32-WASI.

Quickstart

Here's the fastest way to try out WAGI. For details, checkout out the documentation.

  1. Get the latest binary release
  2. Unpack it tar -zxf wagi-VERSION-OS.tar.gz
  3. Run the wagi --help command

If you would like to try out a few simple configurations, we recommend cloning this repository and then using the examples directory:

$ wagi -c examples/modules.toml
No log_dir specified, using temporary directory /var/folders/hk/l1mlxz1x01x9yl33ll9vh9980000gp/T/.tmpx55XkJ for logs

This will start WAGI on http://localhost:3000. Use a browser or a tool like curl to test:

$ curl -v http://localhost:3000/hello/world
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 3000 (#0)
> GET /hello/world HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< content-type: text/html; charset=UTF-8
< content-length: 12
< date: Wed, 14 Oct 2020 22:00:59 GMT
<
hello world
* Connection #0 to host localhost left intact
* Closing connection 0

To add your own modules, compile your code to wasm32-wasi format and add them to the modules.toml file. Check out our Yo-Wasm project for a quick way to build Wasm modules in a variety of languages.

Examples and Demos

Wagi is an implementation of CGI for WebAssembly. That means that writing a Wagi module is as easy as sending properly formatted content to standard output. If you want to understand the details, read the Common Gateway Interface 1.1 specification.

Take a look at the Wagi Examples Repository for examples in various languages.

For a "production grade" (whatever that means for a pre-release project) module, checkout out the Wagi Fileserver: A fileserver written in Grain, compiled to Wasm, and ready to run in Wagi.

Contributing

Want to chat? We hang out in the #krustlet channel of the Kubernetes Slack.

WAGI is experimental, and we welcome contributions to improve the project. In fact, we're delighted that you're even reading this section of the docs!

For bug fixes:

  • Please, pretty please, file issues for anything you find. This is a new project, and we are SURE there are some bugs to work out.
  • If you want to write some code, feel free to open PRs to fix issues. You may want to drop a comment on the issue to let us know you're working on it (so we don't duplicate effort).

For refactors and tests:

  • We welcome any changes to improve performance, clean up code, add tests, etc.
  • For style/idiom guidelines, we follow the same conventions as Krustlet

For features:

  • If there is already an issue for that feature, please let us know in the comments if you plan on working on it.
  • If you have a new idea, file an issue describing it, and we will happily discuss it.

Since this is an experimental repository, we might be a little slow to answer.

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct.

For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Comments
  • Credentials for authenticating to private registries

    Credentials for authenticating to private registries

    The current OCI support added in #39 only allows pulling anonymously from OCI registries. There should be a way to pass credentials to authenticate to a private registry.

    opened by radu-matei 11
  • Registering routes with Go and AssemblyScript

    Registering routes with Go and AssemblyScript

    I'm following the guide here, regarding route registration https://github.com/deislabs/wagi/blob/main/docs/writing_modules.md#advanced-declaring-sub-routes-in-the-module

    However I'm trying to use either Go or AssemblyScript and not having much luck with the routing feature

    My Go code is very simple

    package main
    
    import "fmt"
    
    func main() {
    	fmt.Println("Content-Type: text/plain")
    	fmt.Println("")
    	fmt.Println("this is route main")
    }
    
    //export test
    func test() {
    	fmt.Println("Content-Type: text/plain")
    	fmt.Println("")
    	fmt.Println("this is route test")
    }
    
    //export _routes
    func _routes() {
    	fmt.Println("/test test")
    }
    

    My modules config is simply

    [[module]]
    route = "/"
    module = "server.wasm"
    

    When I run this I can hit the root URL and get this is route main returned but hitting /test results in nothing. I don't think the exported _routes() function is even being called


    So tried again, but this time using AssemblyScript

    import "wasi";
    import { Console, Environ, CommandLine } from "as-wasi";
    
    Console.log("content-type: text/plain");
    Console.log("");
    Console.log("Hello!");
    
    export function test(): void {
      Console.log("content-type: text/plain");
      Console.log("");
      Console.log("Test!");
    }
    
    export function _routes(): void {
      Console.log("/test test");
    }
    

    This time when I run WAGI (directed at the build/untouched.wasm file) I get

    Error: Not all routes could be built: exit with invalid exit status outside of [0..126)
    wasm backtrace:
        0:  0x600 - <unknown>!~lib/wasi/index/abort
        1:  0x679 - <unknown>!~lib/rt/itcms/visitRoots
        2:  0xf42 - <unknown>!~lib/rt/itcms/step
        3: 0x1081 - <unknown>!~lib/rt/itcms/interrupt
        4: 0x160f - <unknown>!~lib/rt/itcms/__new
        5: 0x1959 - <unknown>!~lib/string/String.UTF8.encode
        6: 0x1675 - <unknown>!~lib/string/String.UTF8.encode@varargs
        7: 0x16ac - <unknown>!~lib/as-wasi/as-wasi/Descriptor#writeStringLn
        8: 0x1727 - <unknown>!~lib/as-wasi/as-wasi/Descriptor#writeString
        9: 0x1794 - <unknown>!~lib/as-wasi/as-wasi/Console.write
       10: 0x179d - <unknown>!~lib/as-wasi/as-wasi/Console.log
       11: 0x1925 - <unknown>!assembly/index/_routes
    

    I don't know what I'm doing wrong!

    opened by benc-uk 10
  • Review host matching behaviour

    Review host matching behaviour

    I had a modules.toml that I assumed would not care about where it was served from - it specified routes and handlers but no hosting.

    I ran my WAGI server on localhost:32768 and pointed it at this modules.toml. The routes failed to load, as far as I can tell because they did not match the default_host of localhost:3000.

    Am I misunderstanding? Is this expected behaviour? It surprised the heck out of me.

    On the plus side, it did give us much better tracing of the handler mapping logic.

    opened by itowlson 6
  • ci(release.yaml): add cross-compiled aarch64 config

    ci(release.yaml): add cross-compiled aarch64 config

    • Adds a cross-compiled linux aarch64 entry (and add'l logic) into the GH release workflow

    Approach derived from the Krustlet project.

    Ref https://github.com/deislabs/wagi/issues/141

    Question: Do we want to update the rust.yaml action to add build/compile of this target as well? Changes would be more impactful to that file, so I wanted to ask first.

    Tested release job on fork via https://github.com/vdice/wagi/actions/runs/1752378468 and resulting aarch64 binary on arm64 linux VM:

    ubuntu@ip-172-31-95-42:~$ uname -a
    Linux ip-172-31-95-42 #30~20.04.1-Ubuntu SMP Thu Jan 13 11:49:06 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
    ubuntu@ip-172-31-95-42:~$ ./wagi --version
    WAGI Server 0.4.0
    
    opened by vdice 5
  • SCRIPT_NAME  data format is not correct

    SCRIPT_NAME data format is not correct

    Now value f SCRIPT_NAME does not start with '/', such as 'wagi-deploy/rust-wasi.wasm' , but from https://datatracker.ietf.org/doc/html/rfc3875#section-4.1.13 the SCRIPT_NAME should start with '/' if not NULL

    The syntax is the same as for PATH_INFO (section 4.1.5)
    
          SCRIPT_NAME = "" | ( "/" path )
    
       The leading "/" is not part of the path.  It is optional if the path
       is NULL; however, the variable MUST still be set in that case.
    
    opened by linux-china 5
  • Speed up the output

    Speed up the output

    Right now, a module is entirely buffered, and then its contents are length-checked and sent back to the client. This is fine for small files, but would be both slow and resource intensive for larger responses. We can probably figure out a way to stream that content back.

    This will break from the CGI spec, but that is okay since the spec was pre-HTTP/2

    opened by technosophos 5
  • This caches the modules once, and then uses the cached version

    This caches the modules once, and then uses the cached version

    This changes the way Wagi caches modules.

    In this version, Wagi compiles the modules once and then caches them in memory. Each subsequent request for that module uses the cached module instead of regenerating the module.

    In testing, this dropped the average page load time of Bartholomew from 560ms to 36ms. Tested with siege, too, and saw similar performance gains across both Bartholomew and Fileserver.gr

    Note that what we give up here is file-based caching. So if we want to keep that, we might need to rework this a bit.

    Signed-off-by: Matt Butcher [email protected]

    opened by technosophos 4
  • Do we want to add arm64 binaries to the release job?

    Do we want to add arm64 binaries to the release job?

    Wondering if we want to add arm64 binaries to the release job? I'm personally interested in a linux arm64 binary, but I'd think we could also add darwin and win at the same time if we wanted.

    Does anyone have experience using arm64-based GH action agents? Last I checked, there didn't appear to be any 'stock' arm64 agent flavors available... anyone have experience with https://github.com/marketplace/actions/run-on-architecture (Linux only)?

    opened by vdice 4
  • WebSocket Support

    WebSocket Support

    As the title suggests, it would be nice if WAGI's implementation of the CGI standard were extended to support WebSockets, even if the handshake would have to be performed by the executed module.

    opened by Ronsor 4
  • Remove Virtual Hosting

    Remove Virtual Hosting

    Early on, we write Wagi to do multi-tenant hosting. So we had a number of features like virtual hosting that were designed to be strict and to reduce the possibility of accidentally loading the wrong site (information disclosure).

    But our use case is rapidly evolving toward using a single Wagi instance per app. And in this case, it makes more sense to delegate the host mapping to Nomad or other services, and not have to explicitly configure a Wagi app. Rather, only Wagi itself would know about the host name, and that information would be supplied once for all endpoints hosted on that Wagi instance.

    Should we remove virtual hosting, disallowing modules from declaring their own host name?

    ๐Ÿ‘ = Yes ๐Ÿ‘Ž = No

    opened by technosophos 4
  • Feature: Static file serving

    Feature: Static file serving

    The goal of this feature is to take some files from a bindle and serve them via a Wasm module in the bindle. The target should be a wasm module that handles static file serving in a predictable and configurable way.

    General overview:

    • One bindle can have more than one Wasm module
    • One module may serve out static assets
      • Ideally, we would be able to write a pretty good static file serving module and re-use it all over the place
    • Assets can be clearly identified as static assets that should be served at an understood path.

    A Bindle with Static Assets and Multiple Modules

    Here is an example invoice.toml with two modules and some files that should be served statically, along with another file that should never be served statically. I have omitted a bunch of boilerplate for brevity.

    bindleVersion = "1.0.0"
    
    # The top-level data
    [bindle]
    name = "example.com/static"
    version = "1.0.0"
    
    [[group]]
    name = "static-files"
    satisfiedBy = "allOf"
    
    [[group]]
    name = "private-files"
    satisfiedBy = "allOf"
    
    # An example of a custom app
    [[parcel]]
    label.name = "myapp.wasm"
    label.mediaType = "application/wasm"
    conditions.requires = ["private-files"]
    features.wagi.path = "/app"   # From the hippofacts
    
    # An example module that just serves static files
    [[parcel]]
    label.name = "static.wasm"
    label.mediaType = "application/wasm"
    conditions.requires = ["static-files"]
    features.wagi.path = "/static/..."  # Note the wildcard /..., which matches all subpaths
    
    # These three parcels are static files to be served by static.wasm
    [[parcel]]
    label.name = "img/penguin.jpg"
    label.mediaType = "image/jpeg"
    conditions.memberOf = ["static-files"]
    features.wagi.file = true   # Generated from hippofacts, designates this as a member of the `files = []` array in hippofacts
    
    [[parcel]]
    label.name = "img/cassowary.jpg"
    label.mediaType = "image/jpeg"
    conditions.memberOf = ["static-files"]
    features.wagi.file = true
    
    [[parcel]]
    label.name = "css/style.css"
    label.mediaType = "text/css"
    conditions.memberOf = ["static-files"]
    features.wagi.file = true
    
    # This asset is private, is mounted to myapp.wasm, and can't be served via static.wasm
    [[parcel]]
    label.name = "super/secret/data.txt"
    label.mediaType = "text/plain"
    conditions.memberOf = ["private-files"]
    features.wagi.file = true
    

    (See comments on https://github.com/deislabs/hippofactory/pull/15 for how this would be generated from hippofacts)

    Serving the Files

    The bindle above is mounted to some URI paths:

    • http://example.com/app/ is mapped to myapp.wasm
    • http://example.com/static/ and all subpaths are sent to static.wasm

    When WAGI encounters the features.wagi.file = true flag, the parcel is considered a file and is mounted as a file, attached to any modules that require this parcel.

    In the bindle above, the mayapp.wasm module would have one file available to it, effectively mounted to the path /super/secret/data.txt. It would be able to access that data however it saw fit.

    The static.wasm module has the following paths available, mounted by Wagi:

    • /img/cassowary.jpg
    • /img/penguin.jpg
    • /css/style.css

    The static.wasm module effectively can translate HTTP paths to static file paths. Here's basic pseudocode:

    
    var path_info = env.PATH_INFO            // Example: /static/img/penguin.jpg
    var prefix = env.X_MATCHED_ROUTE  // Example: /static
    
    var file = path_info.trim_prefix(prefix)  // Gives us /img/penguin.jpg
    var mime = guess_mime_by_extension(file) // gives us image/jpeg
    
    // Obviously, we'd want to do something more memory-efficient
    var data = fs.read_file(file)
    
    // Print a content-type header, an empty line, then the data
    stdout.println("Content-Type: " + mime)
    stdout.println("")
    stdout.print(data)
    
    
    opened by technosophos 4
  • prepare_wasm_instance consuming too much CPU

    prepare_wasm_instance consuming too much CPU

    In src/wasm_runner.rs the prepare_wasm_instance() will create and instantiated linker for every request, it will consume about 80% CPU time during stress testing.

    pub fn prepare_wasm_instance(
        ctx: WasiCtx,
        wasm_module: &WasmModuleSource,
        link_options: WasmLinkOptions,
    ) -> Result<(Store<WasiCtx>, Instance), Error> {
        debug!("Cloning module object");
        let (module, engine) = wasm_module.get_compiled_module()?;
        let mut store = new_store(ctx, &engine)?;
    
        debug!("Configuring linker");
        let mut linker = Linker::new(&engine);
        wasmtime_wasi::add_to_linker(&mut linker, |cx| cx)?;
        link_options.apply_to(&mut linker)?;
    
        debug!("instantiating module in linker");
        let instance = linker.instantiate(&mut store, &module)?;
        Ok((store, instance))
    }
    

    The profiling result is enclosed

    flamegraph-before

    I create a quick prototype to cache the linker for each compiled wasm module, the cold start time is reduced a lot. The profiling result after optimization is enclosed. it will only consume about 18% CPU time.

    flamegraph-after

    Just want to know your suggestion for that. Thanks

    opened by denverdino 1
  • Handle SIGTERM properly

    Handle SIGTERM properly

    Signed-off-by: Li Yi [email protected]

    Fix #182

    Tested in Mac/Linux

    $ cargo run -- -c examples/modules.toml
        Finished dev [unoptimized + debuginfo] target(s) in 1.03s
         Running `target/debug/wagi -c examples/modules.toml`
    No log_dir specified, using temporary directory /var/folders/jh/x0hxxwzn7j7fhmlh3q3k17x40000gp/T/.tmp9evE6D for logs
    Ready: serving on http://127.0.0.1:3000
    
    

    In the separated terminal

    $ kill -15 PROCESS_ID
    
    opened by denverdino 2
  • Support SIGTERM for graceful shutdown in containers

    Support SIGTERM for graceful shutdown in containers

    Currently, WAGI only support SIGINT/Ctrl - C. It doesn't works well in containers, e.g. Docker or Kubernetes.

    I suggest to support SIGTERM in wagi_server.rs

    opened by denverdino 0
Releases(v0.8.1)
  • v0.8.1(Mar 10, 2022)

    This release contains a bug fix for an issue introduced in v0.8.0. The bug prevented binary files from being appropriately served. It is strongly recommended that all users upgrade.

    $ shasum -a 256 wagi-v0.8.1-*
    5e813b102dcc46ea0be1ae6aaaa84fb73fd4793e8830c6b91dbf67c31f15ae32  wagi-v0.8.1-linux-aarch64.tar.gz
    fd1fae6dfdbff26cb077e46bff55d8a744d566a8d5932019366ac6f260a1351f  wagi-v0.8.1-linux-amd64.tar.gz
    29d45fb6b0e35b692f4b5775090a8b54e13181c038e1f1e529249be7d53094a4  wagi-v0.8.1-macos-amd64.tar.gz
    a6d296f776b51ea47d15d0d40a27e31c3b1ef2fb7be72add221090ce49bce3cc  wagi-v0.8.1-windows-amd64.tar.gz
    

    Changelog

    • release 0.8.1 12fffc72557e6c955621aba06ca88c3066c86717 (Matt Butcher)
    • Add unit test for CRLF and WAT 9809f880e1f31329a331a7cb810830c98d263583 (Matt Butcher)
    • Remove CRs only in headers 65dd4587e58c80cb9fa61408221c1de6f6ccad7b (Matt Butcher)
    Source code(tar.gz)
    Source code(zip)
    wagi-v0.8.1-linux-aarch64.tar.gz(8.83 MB)
    wagi-v0.8.1-linux-amd64.tar.gz(9.13 MB)
    wagi-v0.8.1-macos-amd64.tar.gz(7.35 MB)
    wagi-v0.8.1-windows-amd64.tar.gz(6.23 MB)
  • v0.8.0(Mar 9, 2022)

    This release fixes two bugs:

    1. When parsing headers returned from a module, Wagi was assuming carriage returns were not included before newlines
    2. A unit test was hitting an endpoint whose behavior has changed, causing tests to fail

    The first fix also fixes a bug with (Tiny)Go's net/http/cgi library (which inserts carriage returns).

    shasum -a 256 wagi-v0.8.0-*
    2d8fbb7478cba8990c4a042cdabe94067e9beb0b9239b2d7a3f939a7fa8f9ca9  wagi-v0.8.0-linux-aarch64.tar.gz
    5ab2c8666b0a05e2d9ddc44676df63bd4f8002b997289ae1c6e3f3f31c14ddff  wagi-v0.8.0-linux-amd64.tar.gz
    6ca2673b5eac617f79c0093bb5a4afb1358eb161412e76c8669a9c07741eec8a  wagi-v0.8.0-macos-amd64.tar.gz
    7c5b5d0d87a49f88dae335198828b731a00c7371f630b0f4dd2760af9cbc89fc  wagi-v0.8.0-windows-amd64.tar.gz
    

    Changelog

    • Release 0.8.0 54bb5c9a42e89771c9df8c8bbf956b0b857a0a63 (Matt Butcher)
    • Ignore carriage returns in headers 2501e485c25366361c457ce9a56103d3dcee1cbe (Matt Butcher)
    • Fixed test that is failing because of an expired SSL cert dd131e6ae1034c4f9d10858093d3ac62e3e25830 (Matt Butcher)
    Source code(tar.gz)
    Source code(zip)
    wagi-v0.8.0-linux-aarch64.tar.gz(8.83 MB)
    wagi-v0.8.0-linux-amd64.tar.gz(9.13 MB)
    wagi-v0.8.0-macos-amd64.tar.gz(7.35 MB)
    wagi-v0.8.0-windows-amd64.tar.gz(6.22 MB)
  • v0.7.0(Mar 7, 2022)

    This release includes adding HTTP Basic-auth support for Bindle, adding an argv configuration parameter (for custom arguments), improving logging, internal refactoring, and making it possible to use Wagi as a library.

    Security: This also updates Wasmtime to 0.34. Earlier versions of Wasmtime had a security issue, but not one exploitable via Wagi. Still, it is suggested that all users upgrade.

    $ shasum -a 256 wagi-v0.7.0-*.tar.gz
    903d946e9023696616ebfa48f8f8d3c9955d2931e34c453bc0b55e75edcb9a62  wagi-v0.7.0-linux-aarch64.tar.gz
    8fe1976508e34c6cbac5b1a20c81702ca59d0e9e0e1b4d1fb32c7457d791cdfb  wagi-v0.7.0-linux-amd64.tar.gz
    20a91819424833533eb26d667c58d23a09971a9a9199404f79d130624a38e051  wagi-v0.7.0-macos-amd64.tar.gz
    2a0647929d84a773d9bfe13633e75b7e6251047ddd89d03fe58a58ca8362965c  wagi-v0.7.0-windows-amd64.tar.gz
    

    Changelog

    • undo rustfmt to match current style c156fa1f581820fd4dce2ce7cb1843c15a9b22f4 (Brian Ketelsen)
    • feat: :sparkles: Add protocol to console output when server starts b063fd2bf19a564d6e055e6d79753d6c7ff79d2a (Brian Ketelsen)
    • Prepare for release v0.7.0 0c37ad606bd2c573380e8047b7d42804d1706ffc (Matt Butcher)
    • feat(*): add support for http basic auth to bindle server (#165) b3d17810d777ca586d62404ebbd5dc7af04570e8 (Vaughn Dice)
    • add 'argv' argument to modules.toml and bindle c5b0385f3404fb24c313b4c898e04530b122d7a8 (Matt Butcher)
    • chore(handlers): Log the body of the response on parsing error 899ad669f5cd6f812245b12aa6684ed2bf502c0a (Adam Reese)
    • chore: update Wasmtime to v0.34 4c8785d46c4ec6841034dd8e439197feee236816 (Radu Matei)
    • Export the handlers and http_util modules b9c8192295aea138039a0716c98a2e68b0805adb (Radu Matei)
    • Format cide changes fea18357f0d9f881ce61f77e903f15b81522b505 (itowlson)
    • We can make the remote module resolver private to the loader pipeline too 2dcbb3a0630a052ae1193e525a68bc7fac881fe7 (itowlson)
    • Tidy and unpublic some bits f5893260e553108e552e90f753b858adb7b92bd7 (itowlson)
    • Slim down surface of loader system 2d42e58c68a329e85572fa1d0b641b568e67b29b (itowlson)
    • Checkpoint of encapsulating the loading stuff 4a83813b5daa36db445242c70389f6007b595fdb (itowlson)
    • Start to encapsulate the whole handler loading workflow aa5699815d222098f5719b1d0d4b9b4e86ec762c (itowlson)
    • Split metadata for easier mapping 83dec7886cdc9e1934cbb388dc67dcf30d366ea6 (itowlson)
    • Identify failed module in compile errors dbf39e677d29e6b1afe7b452f82686c87859fe1d (itowlson)
    • Move compilation out of the routing table e5060e28927128bc51c86c8ce7913ff1f15e5ee7 (itowlson)
    • Move destructuring into the module wrapper type c9ca306c809b5f217904dfe08cebf4dd5f81a5a4 (itowlson)
    • Cleans grunkibles with fire abd4a843fd0674cee8a4f8054351092097396c2b (itowlson)
    • Unify config methods before we get to the dispatcher 079781f25eab89b3ab82a8e5f56a8de54f104f1f (itowlson)
    Source code(tar.gz)
    Source code(zip)
    wagi-v0.7.0-linux-aarch64.tar.gz(8.83 MB)
    wagi-v0.7.0-linux-amd64.tar.gz(9.13 MB)
    wagi-v0.7.0-macos-amd64.tar.gz(7.35 MB)
    wagi-v0.7.0-windows-amd64.tar.gz(6.22 MB)
  • v0.6.2(Feb 2, 2022)

    After doing load analysis, we discovered a performance bottleneck. Version 0.6 fixes this bottleneck. See the release notes for 0.5 to catch up on other recent changes.

    Acting as release manager, I (@technosophos ) have been having a little difficulty getting the release cut properly. 0.6.2 is the same as 0.6.1 and 0.6.0 except that it has the correct version number set in all the places.

    Checksums

    Generated on macOS with shasum:

    shasum -a 256 *.tar.gz
    1b8f53ee43b33cd3c3a79234c1a236f90c91f892bca1f267c86cf9b14da0fbc4  wagi-v0.6.2-linux-aarch64.tar.gz
    232d623e8cd9c5b72e2b76d0668eda0049edbe18f7bb5d6d5f979da2e69d1738  wagi-v0.6.2-linux-amd64.tar.gz
    8f594180205a13e31340942f116cf144f3a1d972c868f0426b3668cbc4239947  wagi-v0.6.2-macos-amd64.tar.gz
    7605e21c970b8679ee3d16775129611dcc2297b937af33b041f9bd75fc2d7fd8  wagi-v0.6.2-windows-amd64.tar.gz
    

    Change Log

    • Bump versions to 0.6.2 a9092690a008e5927050fa75ef419b69b89370d6 (Matt Butcher)
    • Release 0.6.1 88b2376934fdb161213f3eefc04a551b8ab076f5 (Matt Butcher)
    • Load modules at startup, and clone per request cb1b8307878f3625528a5ec3aaff60843c0e24bf (Matt Butcher)
    • ref(*): update bindle dependency and usage fa138320ff3de89ad37433cfe617246ed3c57209 (Vaughn Dice)
    • Add debugging to surface bottlenecks and performance issues 1a0e17ffbfde49f027aa5178a40c57216cec5c93 (Matt Butcher)
    • fix(CI): update git ref to check for main bc7c2495dfeafe8dc281ef73a724dfc1511ed778 (Radu Matei)
    Source code(tar.gz)
    Source code(zip)
    wagi-v0.6.2-linux-aarch64.tar.gz(9.18 MB)
    wagi-v0.6.2-linux-amd64.tar.gz(9.50 MB)
    wagi-v0.6.2-macos-amd64.tar.gz(7.67 MB)
    wagi-v0.6.2-windows-amd64.tar.gz(6.46 MB)
  • v0.6.1(Feb 2, 2022)

    After doing load analysis, we discovered a performance bottleneck. Version 0.6 fixes this bottleneck. See the release notes for 0.5 to catch up on other recent changes.

    This is a corrected release of 0.6.0, whose assets were still incorrectly versioned 0.5.0.

    Checksums

    Generated on macOS with shasum:

    shasum -a 256 *.tar.gz
    7e6ef9078d96539ea5314b75d64325dfee2aa1c306579533a19fa329af1e0cb4  wagi-v0.6.1-linux-aarch64.tar.gz
    dd8200b9269798d07496761536c0111d15425b08a8d89e49ddac8c926fcebda2  wagi-v0.6.1-linux-amd64.tar.gz
    a7f98dc116dbce43dda00a690b9743924671904d9d282359dfbb877b0fb74afd  wagi-v0.6.1-macos-amd64.tar.gz
    c9898d1015fac70781444a320a04b7f34be66ee4cf972cbb84daeaf5b21bda20  wagi-v0.6.1-windows-amd64.tar.gz
    

    Change Log

    • Release 0.6.1 88b2376934fdb161213f3eefc04a551b8ab076f5 (Matt Butcher)
    • Load modules at startup, and clone per request cb1b8307878f3625528a5ec3aaff60843c0e24bf (Matt Butcher)
    • ref(*): update bindle dependency and usage fa138320ff3de89ad37433cfe617246ed3c57209 (Vaughn Dice)
    • Add debugging to surface bottlenecks and performance issues 1a0e17ffbfde49f027aa5178a40c57216cec5c93 (Matt Butcher)
    • fix(CI): update git ref to check for main bc7c2495dfeafe8dc281ef73a724dfc1511ed778 (Radu Matei)
    Source code(tar.gz)
    Source code(zip)
    wagi-v0.6.1-linux-aarch64.tar.gz(9.18 MB)
    wagi-v0.6.1-linux-amd64.tar.gz(9.50 MB)
    wagi-v0.6.1-macos-amd64.tar.gz(7.67 MB)
    wagi-v0.6.1-windows-amd64.tar.gz(6.46 MB)
  • v0.5.0(Jan 31, 2022)

    Wagi v0.5.0

    This release brings a handful of bug fixes and dependency updates, as well as some refactors.

    In addition, some new wasm functionality has been enabled, such as multi-memory and module linking.

    Lastly, we are now including Linux ARM64/aarch64 binaries in our release assets. Enjoy!

    Checksums

    $ shasum -a 256 *.tar.gz
    6103566ec5f34e0e004e52d78b68fd308aa5ba02c74372d59c1e329987d387d6  wagi-v0.5.0-linux-aarch64.tar.gz
    2cd7450e6e628467ba5f972048fe3b4c27baa0fcadda76f4891aec423a7ae1c2  wagi-v0.5.0-linux-amd64.tar.gz
    ce26eddaf8852053c950b998c608289001b5e36ddf0cf880f83b7a209ef6ef33  wagi-v0.5.0-macos-amd64.tar.gz
    c13fbc0263175a55c031b9cd6704f739600cd09a4ddc01a5b01b336a517deb12  wagi-v0.5.0-windows-amd64.tar.gz
    

    Changelog

    • chore(*): bump version to 0.5.0 caf7b46ac3e7c473f8a1aa427dea92425da24ce7
    • remove unused target field in matrix 4fb7dfde9d01fd8f55903a621e8dfced75daa968
    • ci(release.yaml): add cross-compiled aarch64 config 0b1dc24a022028189c2938625326821a77eccf4f
    • upgrade wasmtime 0.33 and experimental HTTP 0.8 271fc455e8753672957f7c6c595750f28b010cc0
    • Include source code for HTTP example (#145) 7c0f6d3e4f99761445eea8e23948ee5a7a335ab5
    • Docs for new flag behaviour 8d7d511cdc955bd8f5268792dcd3dd6b55f6b404
    • Rationalise Wasm module source options cc7005ac0f659f32cd804138942cd94f4e623589 (itowlson)
    • Centralise Wasm linking and instantiation (#143) c51263b42515560e868cccdf2352caf147ffd6e0 (itowlson)
    • Fix dispatcher not linking the HTTP library (#142) f941887757584e6134a2ead3c8b4ac299e005957 (Radu Matei)
    • Change use Bindle ID in help text 8cd7a59006ea99b0b139309de8e5d470517c9341 (Adam Reese)
    • Fix spurious log on no assets (#133) d69ffd3762ed8bcacb76f5afd0698803e5f1fe9d (itowlson)
    • feat: enable multi memory and module linking 045194ae8b72277db4bdd3af7c120a28e7458d02 (Radu Matei)
    • fix(docs): fix spelling bath -> path ... bath is better tho a987858b7979189aa5849ad25f536edcd2782593 (Michelle Noorali)
    • chore: update wasi-experimental-http-wasmtime c33accdc38ac99b41bd9520b5794ef28196d0a54 (Radu Matei)
    • fix(docs): fix typo Fo -> For ec14e4567e12e639eaab9728652ed29f643937c3 (Michelle Noorali)
    • Update Wasmtime to v0.31 fb9d1606940c62fd5435288caae3ae18e84670ca (Radu Matei)
    • Fixed failed match when parent and dynamic both had slashes. Fixed /foo/... matching /foobar (blush) (#129) 3486d995e41979dbf7193d6e252d278f243ae991 (itowlson)
    • Placate Clippy (#126) abecd21f5da10dbf03b5e5d7fbac9f974af9bc61 (itowlson)
    • Major refactoring (#125) c48bdd6a205920cf90878c558b60fc667289431a (itowlson)
    Source code(tar.gz)
    Source code(zip)
    wagi-v0.5.0-windows-amd64.tar.gz(6.32 MB)
    wagi-v0.5.0-macos-amd64.tar.gz(7.51 MB)
    wagi-v0.5.0-linux-amd64.tar.gz(9.29 MB)
    wagi-v0.5.0-linux-aarch64.tar.gz(8.97 MB)
  • v0.4.0(Sep 20, 2021)

    This release updates to Wasmtime 0.3 and updates other Wasmtime-dependent dependencies.

    Wasmtime 0.3 released a security patch (CVE 2021-39218). Wagi depends on Wasmtime, and is thus impacted by the issue. This release updates to the recently patched Wasmtime, and also updates additional dependencies.

    All uses should update to Wagi 0.4.0.

    shasum wagi-v0.4.0-*
    91767bc21d6f9c9b5d8a9bd109b106775975c414  wagi-v0.4.0-linux-amd64.tar.gz
    10bbcd1f7f1d369d2b3cf9b387cb71f84e9a9912  wagi-v0.4.0-macos-amd64.tar.gz
    3752a10812585f31ced8e97fea9843d368def602  wagi-v0.4.0-windows-amd64.tar.gz
    

    NOTE

    The License for Wagi has been changed from MIT to Apache 2. This reflects our recent position that all code targeted for organizational donation (e.g. to Bytecode Alliance, Linux Foundation, or CNCF) should be licensed under Apache 2.

    Changelog

    • Change version to 0.4.0 23efb4bccfd877a23f557f8c78fde6c188a0c257 (Radu M)
    • Update wasi-experimental-http-wasmtime crate to latest published version cdf4acca2829839734ea4e4ad406b3dd1a181a89 (Radu M)
    • Update wasi-experimental-http crate 1ea8d9d2b63c570cfdcd1b910e335d863c838e9e (Radu M)
    • Update Wasmtime to v0.30 db2fcf43ac4c0bd8a37f36bc4a4c49db90cd34e2 (Radu M)
    • Update license to Apache v2 4800e06844f48a1bf54e9ad7545b3ef6ae15b71a (Radu M)
    • Fetch credentials for priv registry if exists 6050e7ed7fe7c97e0979c59edf27bf68d85a552c (Nitish Malhotra)
    Source code(tar.gz)
    Source code(zip)
    wagi-v0.4.0-linux-amd64.tar.gz(9.49 MB)
    wagi-v0.4.0-macos-amd64.tar.gz(7.73 MB)
  • v0.3.0(Aug 26, 2021)

    This release fixes a number of bugs in the CGI implementation, and also refactors some of the internals to be more manageable.

    It is recommended that all Wagi users upgrade.

    Checksums

    $ shasum *.tar.gz
    6a79d8e1c34295e367a85b263ed63c2259197a8b  wagi-v0.3.0-linux-amd64.tar.gz
    c516bfd79d29c0ef14d52dc017c12e75460327ee  wagi-v0.3.0-macos-amd64.tar.gz
    72e15a43f5d4eeec9fc345a439a65dd5977c44e2  wagi-v0.3.0-windows-amd64.tar.gz
    

    Changelog

    • Fixe PATH_TRANSLATED and PATH_INFO 47b368d174af9afc35456cbe225144713d8794cd (Matt Butcher)
    • in the fray, I forgot to fix the initial bug with SCRIPT_NAME. 88e80537d27703d1b50e2fb233cb88aa82a58009 (Matt Butcher)
    • fixes to bring this up to CGI/1.1 specification beaf6e281194155ff282128200345102acd8b623 (Matt Butcher)
    • fix SCRIPT_NAME to not disclose location on disk cca9620636a261ad23a3adf2c45ffdcb49c11c52 (Matt Butcher)
    • Fixed SERVER_PROTOCOL to return HTTP version 4904f77033b09296e64f860e0b7c703b12127105 (Matt Butcher)
    • Nitishm/enhancement/42/module config concurrency param (#107) b0e340242f0a8cb04105918eccbf981db700cc10 (Nitish Malhotra)
    • Address review comments 10301fa62260fb9570b818f0e571133192c9d2d7 (Nitish Malhotra)
    • fix(examples): Fixes example bindle invoice dece80cc62599164548c17e584132306174b0bcf (Taylor Thomas)
    • Add .vscode config dirs to gitignore 6a2547f63af7512c1b2fe662f909e5f7c6b507a8 (Nitish Malhotra)
    • Cleanup comments based on review 82cdd26e75570a34da1ba9d3d25cbecd8965c7f5 (Nitish Malhotra)
    • Switch from ctor to inline instantiation 788a3e0c255f3261f4c8305d23ccb5150a589e48 (Nitish Malhotra)
    • Rename ModuleInfo to RouterInfo b3765f879c4f9ff5cc59eeab1f61f28acab77951 (Nitish Malhotra)
    • Created a moduleinfo struct to shorten execute signature/params 65bd2753abf0017c0e68d0ed4377494dad36c0f8 (Nitish Malhotra)
    • Fix typo in --bindle-path help text (#105) f97c804dc9b5657c11138dcb44f2b289918431b9 (itowlson)
    • revert PR 97 and add some inline docs b64cbcf002f44544e3fe57912533fc45b9c2c605 (Matt Butcher)
    • Updated a bunch of things related to WAGI releases 2f3c199cfd231571113fbb1a1326d014451c0513 (Matt Butcher)
    • Bumped version to 0.2.0 346e674c3e2d904a9a90b0aa2460d53b204b8ad0 (Matt Butcher)
    Source code(tar.gz)
    Source code(zip)
    wagi-v0.3.0-windows-amd64.tar.gz(6.35 MB)
    wagi-v0.3.0-macos-amd64.tar.gz(7.50 MB)
    wagi-v0.3.0-linux-amd64.tar.gz(9.30 MB)
  • v0.2.0(Jul 8, 2021)

    This release is the first binary release of Wagi.

    Installing

    The binary releases for Wagi are located at the bottom of this page. For installation instructions, see the installation guide

    All checksums were generated on macOS with the command shasum *.tar.gz

    ad4114b2ed9e510a8c24348d5ea544da55c685f5  wagi-v0.2.0-linux-amd64.tar.gz
    463a60c5056b20eb8c82263560e05261e360e1d1  wagi-v0.2.0-macos-amd64.tar.gz
    c8711f2c9464f6acc8a2175b2c0c219f0dee3ef2  wagi-v0.2.0-windows-amd64.tar.gz
    

    Using as a Crate

    This release does not support crate-based usage of Wagi.

    Caveats

    Wagi is considered pre-production, and should not be used in a production environment. Likewise, APIs, file formats, and protocols are subject to change between now and 1.0.0-beta.1.

    Major Features

    • CGI/1.1 support
    • Bindle support
    • OCI registry support
    • Custom environment variables and hostname
    • Wasm caching

    Bug Fixes

    Bug fixes are not reported for this first version

    Known Issues/Missing Features

    • The binary client may report itself to be 0.1.0
    • There is a known but un-diagnosed issue in which starting many Wagi instances on Windows can cause some instances to hang, contending for a port.

    Breaking Changes

    • Many features from the unreleased 0.1.0, including virtual hosting, were removed or refactored out
    • modules.toml is different from the unreleased 0.1.0 version
    • Environment variables can no longer be specified in modules.toml

    What's Next?

    Wagi is rapidly evolving. Our next milestone is for cleanup and bugfixing.

    Source code(tar.gz)
    Source code(zip)
    wagi-v0.2.0-windows-amd64.tar.gz(6.40 MB)
    wagi-v0.2.0-macos-amd64.tar.gz(7.53 MB)
    wagi-v0.2.0-linux-amd64.tar.gz(9.33 MB)
Owner
null
Sealed boxes implementation for Rust/WebAssembly.

Sealed boxes for Rust/WebAssembly This Rust crate provides libsodium sealed boxes for WebAssembly. Usage: // Recipient: create a new key pair let reci

Frank Denis 16 Aug 28, 2022
WebAssembly on Rust is a bright future in making application runs at the Edge or on the Serverless technologies.

WebAssembly Tour WebAssembly on Rust is a bright future in making application runs at the Edge or on the Serverless technologies. We spend a lot of ti

Thang Chung 129 Dec 28, 2022
WebAssembly modules that use Azure services

This is an experimental repository containing WebAssembly modules running on top of WAGI (WebAssembly Gateway Interface, which allows you to run WebAssembly WASI binaries as HTTP handlers) and using Azure services.

null 7 Apr 18, 2022
WebAssembly Service Porter

WebAssembly Service Porter.

henrylee2cn 12 Dec 12, 2022
๐Ÿš€Wasmer is a fast and secure WebAssembly runtime that enables super lightweight containers to run anywhere

Wasmer is a fast and secure WebAssembly runtime that enables super lightweight containers to run anywhere: from Desktop to the Cloud, Edge and IoT devices.

Wasmer 14.1k Jan 8, 2023
A console and web-based Gomoku written in Rust and WebAssembly

?? rust-gomoku A console and web-based Gomoku written in Rust and WebAssembly Getting started with cargo & npm Install required program, run # install

namkyu1999 2 Jan 4, 2022
WebAssembly development with Trunk & Vite.js

Trunk & Vite.js Demo Trunk is a WASM web application bundler for Rust, and Vite.js is next Generation Frontend Tooling. Ok, they are together now for

Libing Chen 6 Nov 24, 2021
darkforest is a console and web-based Roguelike written in Rust and WebAssembly.

darkforest darkforest is a console and web-based Roguelike written in Rust and WebAssembly. Key Features TBA Quick Start TBA How To Contribute Contrib

Chris Ohk 5 Oct 5, 2021
WebAssembly to Lua translator, with runtime

This is a WIP (read: absolutely not ready for serious work) tool for translating WebAssembly into Lua. Support is specifically for LuaJIT, with the se

null 43 Dec 31, 2022
A Rust ESP stack trace decoder that can also runs in your browser thanks to WebAssembly

ESP Stack Trace Decoder A Rust ESP stack trace decoder that can also runs in your browser thanks to WebAssembly. It is composed of a โŒจ๏ธ Rust library,

Maxime BORGES 20 Oct 5, 2022
Simple file sharing with client-side encryption, powered by Rust and WebAssembly

Hako Simple file sharing with client-side encryption, powered by Rust and WebAssembly Not feature-packed, but basic functionalities are just working.

Jaehyeon Park 30 Nov 25, 2022
bn.js bindings for Rust & WebAssembly with primitive-types support

bn.rs bn.js bindings for Rust & WebAssembly with primitive-types support Write Rust code that uses BN use std::str::FromStr; use primitive_types::{H1

Alexey Shekhirin 23 Nov 22, 2022
A handy calculator, based on Rust and WebAssembly.

qubit ?? Visit Website To Use Calculator Example ?? Visit Website To Use Calculator 2 + 2

Abhimanyu Sharma 55 Dec 26, 2022
A simple compile-to-WebAssembly language rewritten in Rust

chasm A very simple compile-to-WebAssembly language You can play with chasm online. This is a rewrite in Rust of the compiler for the language chasm.

null 11 Nov 27, 2022
Webassembly binding for Hora Approximate Nearest Neighbor Search Library

hora-wasm [Homepage] [Document] [Examples] [Hora] Javascript bidding for the Hora Approximate Nearest Neighbor Search, in WebAssembly way. Features Pe

Hora-Search 26 Sep 23, 2022
Stylist is a CSS-in-Rust styling solution for WebAssembly Applications.

Stylist Stylist is a CSS-in-Rust styling solution for WebAssembly Applications. This is a fork of css-in-rust. Install Add the following to your Cargo

Kaede Hoshikawa 190 Dec 30, 2022
A template project to demonstrate how to run WebAssembly functions as sidecar microservices in dapr

Demo and tutorials Live Demo | Tutorial article | Tutorial video 1. Introduction DAPR is a portable, event-driven runtime that makes it easy for any d

Second State 184 Dec 29, 2022
A curly-braces infix language that compiles to WebAssembly

CurlyWas CurlyWas is a (still WIP) curly-braces, infix synatx for WebAssembly. The goal is to have as to a 1:1 mapping to the resulting wasm instructi

null 22 Dec 24, 2022
WebAssembly wrapper for JohnnyMorganz's StyLua

WebAssembly wrapper for JohnnyMorganz's StyLua

null 1 Dec 15, 2022