feat: add lightweight AssemblyScript SDK for Wagi HTTP components #338
Conversation
This commit starts the work for a lightweight Spin SDK
for AssemblyScript.
Particularly, it starts the work on defining the HTTP
objects needed, and adds a work-in-progress for reading
request data from the environment (for Wagi components).
This is just a work-in-progress, as reading the request
body and writing the response body are currently not implented.
With this SDK, writing an HTTP component in AssemblyScript:
```typescript
export function _start(): void {
handleRequest((request: Request): Response => {
for (var i = 0; i < request.headers.size; i++) {
Console.error("Key: " + request.headers.keys()[i]);
Console.error("Value: " + request.headers.values()[i] + "\n");
}
return new ResponseBuilder(StatusCode.FORBIDDEN)
.header("content-type", "text/plain")
.header("foo", "bar")
.body(String.UTF8.encode("Hello, Fermyon!\n"));
});
}
```
Note that this still follows the existing convention for
calling the `_start` function in the module for a Wagi
component.
(We are currently experimenting with going through the C bindings
for writing components in other languages, currently for CGO.
If that experiment is successful, it would allow us, for the list
of languages supported with an SDK, to stop relying on the Wagi
compatibility layer and fully implement all types of components.
That work is still early. Depending on its outcome, we will decide
how to approach the AssemblyScript SDK.)
Signed-off-by: Radu Matei <[email protected]>
sdk/as/http/cgi.ts
Outdated
|
|
||
| export function sendResponse(response: Response): void { | ||
| printHeaders(response); | ||
| // wasi.Descriptor.Stdout.write(changetype<u8[]>(response.body)); |
There was a problem hiding this comment.
Writing the response body is currently not working.
sdk/as/http/cgi.ts
Outdated
| let uri = requestUriFromEnv(); | ||
| let method = requestMethodFromEnv(); | ||
| let headers = requestHeadersFromEnv(); | ||
| // let body = requestBodyFromEnv(); |
There was a problem hiding this comment.
Reading the request body is currently not working.
sdk/as/http/http.ts
Outdated
| } | ||
|
|
||
| /** Convert an HTTP method into a string. */ | ||
| export function from(m: Method): string { |
There was a problem hiding this comment.
Terrible function name.
sdk/as/http/http.ts
Outdated
|
|
||
| export namespace Method { | ||
| /** Parse a string into an HTTP method. */ | ||
| export function parse(m: string): Method { |
There was a problem hiding this comment.
Terrible function name.
|
TODO:
|
|
I know |
Signed-off-by: Radu Matei <[email protected]>
|
As a heads up, one thing to test for in this is handling of the special (And this may be on us. WAGI doesn't really treat the module as a reactor, but instead kinda treats it as two commands in a trenchcoat, which works okay with Rust but might be a bit ambiguous in terms of the WASI spec, I'm not sure.) |
|
Oh, this brings up an excellent point that we (read I) should have documented and/or implemented — see #342 |
|
AssemblyScript recently removed WASI support from the core project, and we no longer support the old WASI experimental HTTP library, so defering this SDK for now. Happy to revisit if people are interested. ref #699 |
ref #298
This commit starts the work for a lightweight Spin SDK
for AssemblyScript.
Particularly, it starts the work on defining the HTTP
objects needed, and adds a work-in-progress for reading
request data from the environment (for Wagi components).
This is just a work-in-progress, as reading the request
body and writing the response body are currently not implented.
With this SDK, writing an HTTP component in AssemblyScript:
Note that this still follows the existing convention for
calling the
_startfunction in the module for a Wagicomponent.
(We are currently experimenting with going through the C bindings
for writing components in other languages, currently for CGO.
If that experiment is successful, it would allow us, for the list
of languages supported with an SDK, to stop relying on the Wagi
compatibility layer and fully implement all types of components.
That work is still early. Depending on its outcome, we will decide
how to approach the AssemblyScript SDK.)
Signed-off-by: Radu Matei [email protected]