15 ms·

WAGI: WebAssembly Gateway Interface

112 points by drocer88 5y ago

fnord77 5y ago
so this is like WSGI? The almost 30 year old design pattern that blocks on requests waiting for a response from the downstream app and really isn't scalabe?
- supermatt 5y ago
  wsgi isnt inherently blocking. it is a protocol and it is up to the implementation on both sides if the interface as to how it is handled. that said, according to the docs this seems to be cgi 1.1 which equates to a process per request, which afaik isnt so scalable.
  - zozbot234 5y ago
    WASM "processes" need not be the same as OS-level processes. So I don't think this would have the scalability issues of plain CGI.
    - supermatt 5y ago
      interesting! i will have to have a look into this
    - Matthias247 5y ago
      Right. And the Wasm runtime could run multiple Wasm processes on one OS thread. If one program blocks on stdin/stdput it gets descheduled and the next one can run. Which basically provides the same M:N scheduling that highly scalable Webservers would use.
- formerly_proven 5y ago
  It’s not, this is a CGI implementation. WSGI is an in-process API and can support multiple requests in flight. Kind of weird to call this a gateway interface instead of something like wasm_cgi. > Wagi is an implementation of CGI for WebAssembly.
- giancarlostoro 5y ago
  ASGI is the replacement for WSGI. Honestly I never noticed insane latency with WSGI.
nynx 5y ago
Why would they put things in environment variables instead of having new imported functions to grab various values?
- the_duke 5y ago
  I think the goal with this one was to be zero-friction and allow any WASI module to serve requests, without requiring language-specific bindings. It's obviously not a great design, and a more serious standardized version would use interface types. But that still seems quite a ways off.
- tyingq 5y ago
  That's what the various CGI specs require, and the project is to implement something very close to CGI in WASM.
  - puppet-master 5y ago
    Reproducing ancient defects from the CGI spec in the process, such as the inability to represent duplicate header names.
    - tyingq 5y ago
      RFC2616 says this: "It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma." So, if the implementation folds the multiple headers into one with the various values as a comma separated list, it should all be compliant. I don't know rust well enough to tell if this one is compliant...it reads like it is not (looks like last header wins): https://github.com/deislabs/wagi/blob/main/src/http_util.rs#L22 https://github.com/deislabs/wagi/blob/main/src/http_util.rs#... Edit: It seems RFC7230 keeps most of that language, but makes one exception for Set-Cookie, but that's outbound in this context so it doesn't apply.
    - guntars 5y ago
      Wonder why they wouldn't pass in the whole request on stdin? That would also mean that instances could be pre-started in anticipation of a request and not just when one is already waiting.
fleetfox 5y ago
Interesting. What about web sockets?
- matei_radu 5y ago
  Hi, one of the maintainers here. We don’t have a WebSockets implementation for WASI yet (the WebAssembly System Interface), and in fact, WASI doesn’t have a networking implementation at all yet. This is why we have been experimenting with the outbound HTTP implementation [1], which is available in WAGI. In theory, you could take the same approach as here, with the difference that a WebSockets connection is persistent and long-running. [1]: https://github.com/deislabs/wasi-experimental-http https://github.com/deislabs/wasi-experimental-http
nerdponx 5y ago
Does WebAssembly even make sense as a standalone runtime, like the JVM? Is "server-side WebAssembly" going to be "a thing", or is it just a compatibility kludge? And what of all these languages that compile to JS, like Typescript, Reason, Kotlin, et al? Is JS a sound "IR" between the frontend and WebAssembly? Or would it be better to compile things directly to WebAssembly?
- gpm 5y ago
  Yes, wasm makes sense as a standalone runtime. It's basically just like any other bytecode. Like any bytecode (including jvm's), it comes at a performance penalty over bare asm. I personally don't anticipate it will replicate jvm's success as being a runtime when there is no reason for a runtime to exist - since it shouldn't be much harder to compile wasm (and languages that compile to wasm) to native asm ahead of time. On the other hand I wouldn't have predicted jvm's success either. In places where you want a runtime though, like in shared computation models where it gives you security/performance advantages, it makes perfect sense. It looks like it's probably going to succeed there to me. Compiling X -> JS -> Wasm doesn't make much sense. Not only is wasm a language with cleaner semantics to compile to, but JS doesn't actually really fit wasm semantics particularly well. In fact, while I could have missed something, I'm not aware of any good JS->wasm compilers. The closest I can think of is https://www.assemblyscript.org/ https://www.assemblyscript.org/ - and it's not 100% JS compatible.
- invokestatic 5y ago
  I think a lot of people, myself included, have been waiting for a low-level, polyglot, and lighter weight runtime than the JVM. WebAssembly currently provides the best tooling for this. That said, I’m not really convinced of the server-side use case except for sandboxing untrusted code. Especially in rust, where the language itself provides safety guarantees that the VM makes redundant.
  - zozbot234 5y ago
    The safety guarantees are not redundant, they're quite complementary. WASM doesn't protect you from violating memory safety within your programs; its sandbox only protects the rest of the system from whatever the WASM program does.
luckystarr 5y ago
This looks like CGI on WebAssembly. Do the wagi scripts have to be spawned upon every request, or can the somehow persist in memory?
- iampims 5y ago
  They are loaded at boot an executed for each matching requests.
gavinray 5y ago
This is awesome to see! I have been working on something like this for a while too. But it uses GraalVM and it's "Polyglot" runtime to provide support for JS/Ruby/Python/WASM/LLVM languages. It's packaged as a single binary using graal-native + Quarkus, or if you don't care about that (faster startup time/lower memory use/no JVM needed) but need maximum performance, you can run it as a regular JVM service as well. It was born out of a need for a polyglot Functions-as-a-Service platform but without the weight of container orchestration -- I needed something I could deploy as a single binary. Essentially OpenFaaS/OpenWhisk, minus containers. It doesn't use CGI as a request/response specification though, it uses Vert.x "RoutingContext" interface which has methods like ".getBodyAsJson()", ".params('something')", ".header('foo')", etc. https://vertx.io/docs/apidocs/io/vertx/ext/web/RoutingContext.html An open standard like CGI probably would have been better, but Graal has marshalling facilities for sharing object types between languages, so the most user-friendly/ergonomic thing to do was to share the underlying web request object itself across language boundaries, including all the methods you can call on it. --- This has given me motivation to finally finish it so I can publish + open-source it!
mbStavola 5y ago
I was working on something similar but I found that without interface types[1] you end up with a platform that's kinda primitive and pretty unergonomic. I honestly expect to see an explosion of projects in this vein once interface types are a real thing. [1]: https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/master/p...
- isaacimagine 5y ago
  Imo, interface types are the only thing standing between Wasm and a Cambrian Explosion of Wasm plugin architectures. Up until now it's been go through JS or roll it yourself. Exciting stuff!
astlouis44 5y ago
WebAssembly gaming is going to be huge.
als0 5y ago
Can anyone recommend a good introduction to WASM and WASI? Something that covers standalone and browser based?
- isaacimagine 5y ago
  1 minute intro: Wasm is a high-level assembly language that has both a textual and binary format. It can be interpreted or compiled to a native representation, and has tight integration with modern JS engines (though JS is not required to run Wasm). WASI (WebAssembly System Interface) is a runtime environment standard for Wasm that allows Wasm applications to integrate with 'standard' Unix APIs. These can be forwarded to the host system or emulated. For more info, honestly just going to the Wasm site, the standard, or one of the runtime implementations and exploring from there is the way to go. It's best to learn by doing, so if you know a language that can compile to Wasm, it's always a fun project to try to write something using it. Rust, D, C, Zig, and AssemblyScript all have pretty good tooling. Hope this helps!

112 points by drocer88 5y ago

so this is like WSGI? The almost 30 year old design pattern that blocks on requests waiting for a response from the downstream app and really isn't scalabe?

supermatt 5y ago
wsgi isnt inherently blocking. it is a protocol and it is up to the implementation on both sides if the interface as to how it is handled. that said, according to the docs this seems to be cgi 1.1 which equates to a process per request, which afaik isnt so scalable.
- zozbot234 5y ago
  WASM "processes" need not be the same as OS-level processes. So I don't think this would have the scalability issues of plain CGI.
  - supermatt 5y ago
    interesting! i will have to have a look into this
  - Matthias247 5y ago
    Right. And the Wasm runtime could run multiple Wasm processes on one OS thread. If one program blocks on stdin/stdput it gets descheduled and the next one can run. Which basically provides the same M:N scheduling that highly scalable Webservers would use.
formerly_proven 5y ago
It’s not, this is a CGI implementation. WSGI is an in-process API and can support multiple requests in flight. Kind of weird to call this a gateway interface instead of something like wasm_cgi. > Wagi is an implementation of CGI for WebAssembly.
giancarlostoro 5y ago
ASGI is the replacement for WSGI. Honestly I never noticed insane latency with WSGI.

nynx 5y ago

Why would they put things in environment variables instead of having new imported functions to grab various values?

the_duke 5y ago
I think the goal with this one was to be zero-friction and allow any WASI module to serve requests, without requiring language-specific bindings. It's obviously not a great design, and a more serious standardized version would use interface types. But that still seems quite a ways off.
tyingq 5y ago
That's what the various CGI specs require, and the project is to implement something very close to CGI in WASM.
- puppet-master 5y ago
  Reproducing ancient defects from the CGI spec in the process, such as the inability to represent duplicate header names.
  - tyingq 5y ago
    RFC2616 says this: "It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma." So, if the implementation folds the multiple headers into one with the various values as a comma separated list, it should all be compliant. I don't know rust well enough to tell if this one is compliant...it reads like it is not (looks like last header wins): https://github.com/deislabs/wagi/blob/main/src/http_util.rs#L22 https://github.com/deislabs/wagi/blob/main/src/http_util.rs#... Edit: It seems RFC7230 keeps most of that language, but makes one exception for Set-Cookie, but that's outbound in this context so it doesn't apply.
  - guntars 5y ago
    Wonder why they wouldn't pass in the whole request on stdin? That would also mean that instances could be pre-started in anticipation of a request and not just when one is already waiting.

fleetfox 5y ago

Interesting. What about web sockets?

matei_radu 5y ago
Hi, one of the maintainers here. We don’t have a WebSockets implementation for WASI yet (the WebAssembly System Interface), and in fact, WASI doesn’t have a networking implementation at all yet. This is why we have been experimenting with the outbound HTTP implementation [1], which is available in WAGI. In theory, you could take the same approach as here, with the difference that a WebSockets connection is persistent and long-running. [1]: https://github.com/deislabs/wasi-experimental-http https://github.com/deislabs/wasi-experimental-http

nerdponx 5y ago

Does WebAssembly even make sense as a standalone runtime, like the JVM? Is "server-side WebAssembly" going to be "a thing", or is it just a compatibility kludge? And what of all these languages that compile to JS, like Typescript, Reason, Kotlin, et al? Is JS a sound "IR" between the frontend and WebAssembly? Or would it be better to compile things directly to WebAssembly?

gpm 5y ago
Yes, wasm makes sense as a standalone runtime. It's basically just like any other bytecode. Like any bytecode (including jvm's), it comes at a performance penalty over bare asm. I personally don't anticipate it will replicate jvm's success as being a runtime when there is no reason for a runtime to exist - since it shouldn't be much harder to compile wasm (and languages that compile to wasm) to native asm ahead of time. On the other hand I wouldn't have predicted jvm's success either. In places where you want a runtime though, like in shared computation models where it gives you security/performance advantages, it makes perfect sense. It looks like it's probably going to succeed there to me. Compiling X -> JS -> Wasm doesn't make much sense. Not only is wasm a language with cleaner semantics to compile to, but JS doesn't actually really fit wasm semantics particularly well. In fact, while I could have missed something, I'm not aware of any good JS->wasm compilers. The closest I can think of is https://www.assemblyscript.org/ https://www.assemblyscript.org/ - and it's not 100% JS compatible.
invokestatic 5y ago
I think a lot of people, myself included, have been waiting for a low-level, polyglot, and lighter weight runtime than the JVM. WebAssembly currently provides the best tooling for this. That said, I’m not really convinced of the server-side use case except for sandboxing untrusted code. Especially in rust, where the language itself provides safety guarantees that the VM makes redundant.
- zozbot234 5y ago
  The safety guarantees are not redundant, they're quite complementary. WASM doesn't protect you from violating memory safety within your programs; its sandbox only protects the rest of the system from whatever the WASM program does.

luckystarr 5y ago

This looks like CGI on WebAssembly. Do the wagi scripts have to be spawned upon every request, or can the somehow persist in memory?

iampims 5y ago
They are loaded at boot an executed for each matching requests.

gavinray 5y ago

This is awesome to see! I have been working on something like this for a while too. But it uses GraalVM and it's "Polyglot" runtime to provide support for JS/Ruby/Python/WASM/LLVM languages. It's packaged as a single binary using graal-native + Quarkus, or if you don't care about that (faster startup time/lower memory use/no JVM needed) but need maximum performance, you can run it as a regular JVM service as well. It was born out of a need for a polyglot Functions-as-a-Service platform but without the weight of container orchestration -- I needed something I could deploy as a single binary. Essentially OpenFaaS/OpenWhisk, minus containers. It doesn't use CGI as a request/response specification though, it uses Vert.x "RoutingContext" interface which has methods like ".getBodyAsJson()", ".params('something')", ".header('foo')", etc. https://vertx.io/docs/apidocs/io/vertx/ext/web/RoutingContext.html An open standard like CGI probably would have been better, but Graal has marshalling facilities for sharing object types between languages, so the most user-friendly/ergonomic thing to do was to share the underlying web request object itself across language boundaries, including all the methods you can call on it. --- This has given me motivation to finally finish it so I can publish + open-source it!

mbStavola 5y ago

I was working on something similar but I found that without interface types[1] you end up with a platform that's kinda primitive and pretty unergonomic. I honestly expect to see an explosion of projects in this vein once interface types are a real thing. [1]: https://github.com/WebAssembly/interface-types/blob/master/proposals/interface-types/Explainer.md https://github.com/WebAssembly/interface-types/blob/master/p...

isaacimagine 5y ago
Imo, interface types are the only thing standing between Wasm and a Cambrian Explosion of Wasm plugin architectures. Up until now it's been go through JS or roll it yourself. Exciting stuff!

astlouis44 5y ago

WebAssembly gaming is going to be huge.

als0 5y ago

Can anyone recommend a good introduction to WASM and WASI? Something that covers standalone and browser based?

isaacimagine 5y ago
1 minute intro: Wasm is a high-level assembly language that has both a textual and binary format. It can be interpreted or compiled to a native representation, and has tight integration with modern JS engines (though JS is not required to run Wasm). WASI (WebAssembly System Interface) is a runtime environment standard for Wasm that allows Wasm applications to integrate with 'standard' Unix APIs. These can be forwarded to the host system or emulated. For more info, honestly just going to the Wasm site, the standard, or one of the runtime implementations and exploring from there is the way to go. It's best to learn by doing, so if you know a language that can compile to Wasm, it's always a fun project to try to write something using it. Rust, D, C, Zig, and AssemblyScript all have pretty good tooling. Hope this helps!