WebAssembly for Proxies (Golang host implementation)

WebAssembly for Proxies (GoLang host implementation)

The GoLang implementation for proxy-wasm, enabling developer to run proxy-wasm extensions in Go.

Run Example

  • build and run host
cd example
go run .
  • send http request
curl http://127.0.0.1:2045/
  • host log
receive request /
print header from server host, User-Agent -> [curl/7.64.1]
print header from server host, Accept -> [*/*]
[http_wasm_example.cc:33]::onRequestHeaders() print from wasm, onRequestHeaders, context id: 2
[http_wasm_example.cc:38]::onRequestHeaders() print from wasm, Accept -> */*
[http_wasm_example.cc:38]::onRequestHeaders() print from wasm, User-Agent -> curl/7.64.1

references

Owner
MOSN
The Cloud Native Proxy for Edge or Service Mesh
MOSN
Comments
  • Adds wazero implementation to make this CGO-free

    Adds wazero implementation to make this CGO-free

    This adds a wazero implementation in order to make the project CGO-free. For example, there's no need to load native libraries (as currently exists with wasmer). To achieve this, I added a go.mod file for wasmer.

    Fixes https://github.com/mosn/proxy-wasm-go-host/issues/15

  • Drop ABI v0.1.0

    Drop ABI v0.1.0

    Per #10 the current code doesn't properly implement v0.1.0, and worse that version isn't really used or maintained anymore. I suggest focusing effort on maintained ABI. Notably this should also drop "wasi_unstable" for "wasi_snapshot_preview1" as that's what's in use by current compilers.

    Until this is dropped implementing another host impl is too much low value work, as it is porting for unused and unmaintable ABI.

    @taoyuanyuan @antJack FYI I'm pausing efforts until this is done as I am way over budget already and there's no value proceeding if we have to support an incorrect implementation of an unused ABI version.

  • Updates to latest go and wasmer

    Updates to latest go and wasmer

    Since I was here, I figured I'd bump the libraries. Nice that the example works!

    ## Build it
    $ (cd example; go build .)
    
    ## Ensure the linked libraries are there
    $ otool -L example/example
    example/example:
    	@rpath/libwasmer.dylib (compatibility version 0.0.0, current version 0.0.0)
    	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
    	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60158.100.133)
    	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
    
    $ du -k example/example 
    10512	example/example
    
    $ du -k vendor/github.com/wasmerio/wasmer-go/wasmer/packaged/lib/darwin-amd64/libwasmer.dylib 
    10404	vendor/github.com/wasmerio/wasmer-go/wasmer/packaged/lib/darwin-amd64/libwasmer.dylib
    
    ## try it
    $ (cd example; ./example)
    receive request /
    print header from server host, User-Agent -> [curl/7.79.1]
    print header from server host, Accept -> [*/*]
    [http_wasm_example.cc:33]::onRequestHeaders() print from wasm, onRequestHeaders, context id: 2
    [http_wasm_example.cc:38]::onRequestHeaders() print from wasm, Accept -> */*
    [http_wasm_example.cc:38]::onRequestHeaders() print from wasm, User-Agent -> curl/7.79.1
    

    PS if the intention is to keep floor go 1.14, definitely wazero won't work as we follow Go's support policy, and even if we didn't 1.14 is too far back.

  • Consolidates wasmer functionality with mosn/mosn and hides import impl

    Consolidates wasmer functionality with mosn/mosn and hides import impl

    This migrates in functionality in mosn/mosn that drifted due to copy/paste. The result is better quality here instead of having the wasmer tests delayed until integrated into mosn.

    This also hides the implementation of host functions, as they should never be invoked directly. Host functions should only be invoked by the wasm runtime, ex wasmer or wazero. In doing this, I also started contextualizing them, even though wasmer doesn't support that invocation style. This will help in trace logging in wazero.

  • Tidies code and adds basic tests

    Tidies code and adds basic tests

    When trying wazero I came to the incorrect conclusion that things work, because nothing was tested and errors were ignored.

    This adds tests. It also fixes a go convention problem where the name wasmer is repeated both in package and function names.

    Here are the initial benchmark results on my laptop:

    BenchmarkStartInstanceV1
    BenchmarkStartInstanceV1-16    	      25	  48623804 ns/op
    BenchmarkCallGuestV1
    BenchmarkCallGuestV1-16        	   81004	     14533 ns/op
    
  • go get mosn.io/proxy-wasm-go-host/proxywasm/common is failing

    go get mosn.io/proxy-wasm-go-host/proxywasm/common is failing

    I am trying to use this module in my proxy code, while I am running go get I get the following error - #go get mosn.io/proxy-wasm-go-host/proxywasm/common
    #go get: module mosn.io/proxy-wasm-go-host@upgrade found (v0.1.0), but does not contain package mosn.io/proxy-wasm-go-host/proxywasm/common

  • Not able to add header element.

    Not able to add header element.

    I am trying to add a header element to the request OnHttpRequestHeaders. It's not working or an error. Sample call - proxywasm.AddHttpRequestHeader("Debug", "1"), After this call context return back to the caller no instruction are executed.

  • deps: updates wazero to 1.0.0-pre.4

    deps: updates wazero to 1.0.0-pre.4

    This updates wazero to 1.0.0-pre.4.

    Notably, v1.0.0-pre.4:

    • improves module initialization speed
    • supports listeners in the compiler engine
    • supports WASI fd_pread, fd_readdir and path_filestat_get
  • Adds wazero implementation and makes wasmer gated by build flag

    Adds wazero implementation and makes wasmer gated by build flag

    This makes wasmer use the same wasmer build flag as mosn does, to prevent it from being built-in by default.

    This enables wazero by default, using a non-tagged version until the end of the month when using wasi_unstable is configurable in the next version.

    BenchmarkStartABIContextV1_wazero
    BenchmarkStartABIContextV1_wazero-16     	      73	  13924962 ns/op
    BenchmarkAddRequestHeaderV1_wazero
    BenchmarkAddRequestHeaderV1_wazero-16    	  145736	      7260 ns/op
    BenchmarkStartABIContextV2_wazero
    BenchmarkStartABIContextV2_wazero-16     	      88	  13720664 ns/op
    BenchmarkAddRequestHeaderV2_wazero
    BenchmarkAddRequestHeaderV2_wazero-16    	  164587	      7250 ns/op
    BenchmarkStartABIContextV1_wasmer
    BenchmarkStartABIContextV1_wasmer-16     	     225	   8061989 ns/op
    BenchmarkAddRequestHeaderV1_wasmer
    BenchmarkAddRequestHeaderV1_wasmer-16    	   75734	     15168 ns/op
    BenchmarkStartABIContextV2_wasmer
    BenchmarkStartABIContextV2_wasmer-16     	      79	  13223690 ns/op
    BenchmarkAddRequestHeaderV2_wasmer
    BenchmarkAddRequestHeaderV2_wasmer-16    	   77937	     16036 ns/op
    

    Fixes #15

  • Change example to use currently maintained ABI (0.2)

    Change example to use currently maintained ABI (0.2)

    Currently, the example points users the wrong way as no SDK is maintaining 0.1 anymore. Is it ok if I change it to something maintained? Ex tinygo with 0.2?

    cc @taoyuanyuan @antJack

    Ex. here's the current plugin used in tests ported to a currently maintained SDK in go

    package main
    
    import (
    	"github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm"
    	"github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm/types"
    )
    
    // build main with `tinygo build -o main.wasm -scheduler=none -target=wasi ./main.go`
    func main() {
    	proxywasm.SetVMContext(&vmContext{})
    }
    
    type vmContext struct {
    	// Embed the default VM context here,
    	// so that we don't need to reimplement all the methods.
    	types.DefaultVMContext
    }
    
    // NewPluginContext overrides types.DefaultVMContext.
    func (*vmContext) NewPluginContext(contextID uint32) types.PluginContext {
    	return &pluginContext{}
    }
    
    type pluginContext struct {
    	// Embed the default plugin context here,
    	// so that we don't need to reimplement all the methods.
    	types.DefaultPluginContext
    }
    
    // NewHttpContext overrides types.DefaultPluginContext.
    func (*pluginContext) NewHttpContext(contextID uint32) types.HttpContext {
    	return &httpHeaders{contextID: contextID}
    }
    
    type httpHeaders struct {
    	// Embed the default http context here,
    	// so that we don't need to reimplement all the methods.
    	types.DefaultHttpContext
    	contextID uint32
    }
    
    // OnHttpRequestHeaders overrides types.DefaultHttpContext.
    func (ctx *httpHeaders) OnHttpRequestHeaders(numHeaders int, endOfStream bool) types.Action {
    	proxywasm.LogDebugf("print from wasm, onRequestHeaders, context id: %d", ctx.contextID)
    
    	hs, err := proxywasm.GetHttpRequestHeaders()
    	if err != nil {
    		proxywasm.LogCriticalf("failed to get request headers: %v", err)
    	}
    
    	for _, h := range hs {
    		proxywasm.LogInfof("print from wasm, %s -> %s", h[0], h[1])
    	}
    	return types.ActionContinue
    }
    
  • change foreign call param type from string to byte[]

    change foreign call param type from string to byte[]

    for function call, []byte is more generic than string

    reference: https://github.com/tetratelabs/proxy-wasm-go-sdk/blob/98ee1a9ebc5e1d32a8c044611acab87b4340393f/proxywasm/hostcall.go#L85

  • deps: updates wazero to 1.0.0-pre.6

    deps: updates wazero to 1.0.0-pre.6

    This updates wazero to 1.0.0-pre.6.

    Notably, v1.0.0-pre.6:

    • improves module compilation and initialization performance

    The following features aren't used here, but could be in the future.

    • adds writefs.NewDirFS which lets you add new files.
      • path_open O_CREAT flags, path_remove_directory path_rename path_unlink_file
    • adds NewFilesystemLoggingListenerFactory with dramatically improved logging.

    This also includes changes described in 1.0.0-pre.5. Notably, context param was removed from memory functions as it was never used due to the scope being very narrow, and adds overhead to propagate.

  • When call ProxyOnRequestHeaders get wrong action

    When call ProxyOnRequestHeaders get wrong action

    action

    cd example and replace the wasm file to new file which handles HTTP headers like this. Then go run . run the example.

    expected behaviour

    If the header hit, Action::Pause will be returned from wasm side. ActionPause will be returned by the function ProxyOnRequestHeaders.

    actual behaviour

    Regardless of whether the expected header appears. ActionContinue will be returned by the function ProxyOnRequestHeaders

    about the code

    I noticed that the action ProxyOnRequestHeaders returned is actually from CallWasmFunction, and res is ignored.

    Whether action should be ignored, the value of res should be converted into action format and returned. And what is a.Imports.Wait() actually do, is there any example for it?

  • Imports/exports don't match expected Proxy-Wasm ABI versions.

    Imports/exports don't match expected Proxy-Wasm ABI versions.

    Hello!

    It was pointed out to me (see: https://github.com/proxy-wasm/proxy-wasm-rust-sdk/issues/104) that Proxy-Wasm Go Host doesn't expose all Proxy-Wasm ABI v0.1.0 hostcalls.

    Looking at the code, neither imports nor exports match the specification, e.g. host exports proxy_dispatch_http_call and imports proxy_on_plugin_start, but those don't exists in any of the existing versions (ABI v0.1.0, v0.2.0 or v0.2.1).

    I believe that the source of the confusion might be the work-in-progress specification for vNEXT in proxy-wasm/spec, although even that doesn't define proxy_on_plugin_start, so it's unclear to me what's the source for your v1 and v2.

    Note that there is no documention for either ABI v0.1.0, v0.2.0 or v0.2.1, so the code in Envoy and Proxy-Wasm SDKs is effectively the specification for those versions.

Go compiler for small places. Microcontrollers, WebAssembly, and command-line tools. Based on LLVM.

TinyGo - Go compiler for small places TinyGo is a Go compiler intended for use in small places such as microcontrollers, WebAssembly (Wasm), and comma

Dec 30, 2022
WebAssembly interop between Go and JS values.

vert Package vert provides WebAssembly interop between Go and JS values. Install GOOS=js GOARCH=wasm go get github.com/norunners/vert Examples Hello W

Dec 28, 2022
🐹🕸️ WebAssembly runtime for Go
🐹🕸️ WebAssembly runtime for Go

Wasmer Go Website • Docs • Slack Channel A complete and mature WebAssembly runtime for Go based on Wasmer. Features Easy to use: The wasmer API mimics

Jan 2, 2023
🐹🕸️ WebAssembly runtime for Go
🐹🕸️ WebAssembly runtime for Go

Wasmer Go Website • Docs • Slack Channel A complete and mature WebAssembly runtime for Go based on Wasmer. Features Easy to use: The wasmer API mimics

Dec 29, 2022
A package to build progressive web apps with Go programming language and WebAssembly.
A package to build progressive web apps with Go programming language and WebAssembly.

Go-app is a package for building progressive web apps (PWA) with the Go programming language (Golang) and WebAssembly (Wasm). Shaping a UI is done by

Dec 30, 2022
A package to build progressive web apps with Go programming language and WebAssembly.
A package to build progressive web apps with Go programming language and WebAssembly.

Go-app is a package for building progressive web apps (PWA) with the Go programming language (Golang) and WebAssembly (Wasm). Shaping a UI is done by

Jan 2, 2023
Vugu: A modern UI library for Go+WebAssembly (experimental)

Vugu: A modern UI library for Go+WebAssembly (experimental)

Jan 3, 2023
WebAssembly runtime for wasmer-go
WebAssembly runtime for wasmer-go

gowasmer When compiling Go to WebAssembly, the Go compiler assumes the WebAssembly is going to run in a JavaScript environment. Hence a wasm_exec.js f

Dec 28, 2022
A template project to demonstrate how to run WebAssembly functions as sidecar microservices in dapr
A template project to demonstrate how to run WebAssembly functions as sidecar microservices in dapr

Live Demo 1. Introduction DAPR is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless and stateful app

Jan 3, 2023
Tiny, blazing fast WebAssembly compute

Sat, the tiny WebAssembly compute module Sat (as in satellite) is an experiment, and isn't ready for production use. Please try it out and give feedba

Jan 5, 2023
WebAssembly Lightweight Javascript Framework in Go (AngularJS Inspired)

Tango Lightweight WASM HTML / Javascript Framework Intro WebAssembly is nice, Go on the web is nice, so I ported Tangu to Go and WebAssembly. Tangu is

Dec 20, 2022
Running a Command line tool written in Go on browser with WebAssembly

Running a command line tool written in Go on browser with WebAssembly This repo contains code/assets from the article Files: . ├── article.md

Dec 30, 2022
This library provides WebAssembly capability for goja Javascript engine

This module provides WebAssembly functions into goja javascript engine.

Jan 10, 2022
A Brainfuck to WebAssembly compiler written in Go.

brainfuck2wasm A Brainfuck to WebAssembly compiler written in Go. I am writing this compiler for a Medium article. When I complete the compiler, I'll

Jun 6, 2022
Dom - A Go API for different Web APIs for WebAssembly target

Go DOM binding (and more) for WebAssembly This library provides a Go API for dif

Jan 7, 2023
wazero: the zero dependency WebAssembly runtime for Go developers

wazero: the zero dependency WebAssembly runtime for Go developers WebAssembly is a way to safely run code compiled in other languages. Runtimes execut

Jan 2, 2023
⚙️ Concept of Golang HTML render engine with frontend components and dynamic behavior
⚙️ Concept of Golang HTML render engine with frontend components and dynamic behavior

An HTML render engine concept that brings frontend-like components experience to the server side with native html/template on steroids. Supports any s

Nov 25, 2022
Live views and components for golang

live Real-time user experiences with server-rendered HTML in Go. Inspired by and borrowing from Phoenix LiveViews. Live is intended as a replacement f

Dec 29, 2022
A WASM Filter for Envoy Proxy written in Golang

envoy-proxy-wasm-filter-golang A WASM Filter for Envoy Proxy written in Golang Build tinygo build -o optimized.wasm -scheduler=none -target=wasi ./mai

Nov 6, 2022