Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wasmer Edge: WebAssembly on the Edge

wasmer.io

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Wasmer Edge: WebAssembly on the Edge

#51

Post by preseinger »

ignoramous wrote: post #36
ofrzeta wrote: post #31

I don't get what "the edge" is here. I understand what the edge is with Cloudflare and how it makes sense to run certain applications there but Wasmer doesn't have this kind of infrastructure, does it? Is there any difference to a very small CDN (or APN - application delivery network)? Now when I read about the architecture and the locations it just seems like ordinary cloud hosting, albeit serverless, to me. I can't…

I asked bard and this is what it conjured up: > You're a master at communicating technical concepts to developers by being concise, removing fluff, and speaking plainly without any marketing speak. Please explain what the following means... Sure. Here is my explanation of the quote you provided: 1. Distributed monolith: A distributed monolith is a software architecture that combines the benefits of both monolithic an…

this is 100% not what a distributed monolith is

a distributed monolith is an antipattern that's common to badly executed microservices -- it's essentially an epithet, in no sense a design goal

what's being described here is an _elegant_ monolith, which is entirely different, and definitely does not provide the property that independent libraries can be deployed and scaled independently

Re: Wasmer Edge: WebAssembly on the Edge

#52

Post by PhilippGille »

v7n wrote: post #16

Just today I was hacking together something to enable spawning gRPC endpoints on remote host that would run as WASI modules. Didn't get far with wasmer-go bindings so I went with Wazero for now, but I hope to see the former getting some love.

Did you come across any good documentation around this? Last time I checked it all still felt very early, with Go itself not supporting WASI as compile target yet (this will change soon) and TinyGo not fully suporting `net/http`, and not many examples of how to pass structs between a Go wasm host and Go wasm module, with even strings requiring unsafe pointers IIRC.

Re: Wasmer Edge: WebAssembly on the Edge

#53

Post by v7n »

PhilippGille wrote: post #52
v7n wrote: post #16

Just today I was hacking together something to enable spawning gRPC endpoints on remote host that would run as WASI modules. Didn't get far with wasmer-go bindings so I went with Wazero for now, but I hope to see the former getting some love.

Did you come across any good documentation around this? Last time I checked it all still felt very early, with Go itself not supporting WASI as compile target yet (this will change soon) and TinyGo not fully suporting `net/http`, and not many examples of how to pass structs between a Go wasm host and Go wasm module, with even strings requiring unsafe pointers IIRC.

You can compile for GOOS="wasip1" with Go 1.21, check out the builtin "gotip" command to use the master branch. Unfortunately exporting functions back to Go seems to be a work in progress, since "//go:wasmexport" directive is not yet implemented. Maybe for 1.22?

In addition to that, I added some constants to "..sdk\gotip\src\syscall\syscall_wasip1.go" by hand that were throwing errors about being undefined, just by copying the values from the default unix syscall package. They were about OS files and I figured I shouldn't need them for the WASI module.

But the documentation is lacking and sometimes out of date as you perhaps found out. I'm currently stuck at having the gRPC server object in Go, and the service implementation on the WASM side, and in need of a way to register that service on the server. This means for server.RegisterService(pb ServiceDesc, &server{}) I would need to smuggle out pb and a pointer to the implementation, or for server.RegisterService(pb ServiceDesc, &server{}) smuggle in a grpc.Server pointer...

Re: Wasmer Edge: WebAssembly on the Edge

#54

Post by gedw99 »

v7n wrote: post #53
PhilippGille wrote: post #52

Earlier quoted context omitted.

Did you come across any good documentation around this? Last time I checked it all still felt very early, with Go itself not supporting WASI as compile target yet (this will change soon) and TinyGo not fully suporting `net/http`, and not many examples of how to pass structs between a Go wasm host and Go wasm module, with even strings requiring unsafe pointers IIRC.

You can compile for GOOS="wasip1" with Go 1.21, check out the builtin "gotip" command to use the master branch. Unfortunately exporting functions back to Go seems to be a work in progress, since "//go:wasmexport" directive is not yet implemented. Maybe for 1.22? In addition to that, I added some constants to "..sdk\gotip\src\syscall\syscall_wasip1.go" by hand that were throwing errors about being undefined, just by c…

To server the WASM and WASI19 and WASI2P, i use https://github.com/stealthrocket/wasi-go/tree/main/cmd/wasir... to wrap the wasi with a host runner. This currently requires GoTip.

Re: Wasmer Edge: WebAssembly on the Edge

#55

Post by gedw99 »

v7n wrote: post #53
PhilippGille wrote: post #52

Earlier quoted context omitted.

Did you come across any good documentation around this? Last time I checked it all still felt very early, with Go itself not supporting WASI as compile target yet (this will change soon) and TinyGo not fully suporting `net/http`, and not many examples of how to pass structs between a Go wasm host and Go wasm module, with even strings requiring unsafe pointers IIRC.

You can compile for GOOS="wasip1" with Go 1.21, check out the builtin "gotip" command to use the master branch. Unfortunately exporting functions back to Go seems to be a work in progress, since "//go:wasmexport" directive is not yet implemented. Maybe for 1.22? In addition to that, I added some constants to "..sdk\gotip\src\syscall\syscall_wasip1.go" by hand that were throwing errors about being undefined, just by c…

To run the wasi, I use NATS.

It avoids all the GPRC mess You can instead use Proto and let NATS be be Transport.

Post reply on HN