fermyon / spin-js-sdk Goto Github PK

Building and preparing a JS component for Spin needs a CLI binary that prepares and pre-initialises runtime. This additional binary needs to be on the user's system at spin build time, so there needs to be a way to fetch it.

Currently, there are two ways of fetching this that I can think of:

• Spin plugin
• JS dev dependency

Any thoughts on the two, @dicej?

A usual pattern when writing HTTP handlers in JavaScript is having a function that takes both the request and response, and constructing the response using a builder-like pattern, by chaining the desired status, headers, or body.

An example using Express:

app.get('/', (req, res) => {
	res.status(500).send('Something broke!')
})

This is similar to how other JS frameworks construct HTTP handlers — is this something we'd consider implementing into this SDK?

It is a departure from other Spin SDKs and from the current implementation of this SDK, which takes in the request as a parameter, and returns the response as the result.

Ideally, we should have both TypeScript and JavaScript test cases which are webpacked, converted to Wasm, and run using Spin's executor. We can also add JS/TS tests to https://github.com/fermyon/spin-language-support-matrix to verify all Spin functionality works.

Headers with '-' becomes formatted as an underscore '_' i.e., content-type become content_type

Could we create issues for the things we know are broken or we plan on implementing?

Shopify and Igalia are making good progress adding SpiderMonkey AOT-to-Wasm support and expect to have it ready in the first half of 2023. Shopify expects to switch Javy over to it at that point, and we should consider doing the same for our SDK.

Hello,

The TS/JS templates are missing .gitignore for node_modeules, dist, and target.

Noticed after pushing everything to GitHub :)

I'm trying to use an external library that needs a TextDecoder, and I had the imports in the following order:

import <some library that needs TextEncoder and TextDecoder>;
import { TextEncoder, TextDecoder } from "fast-text-encoding";

Building this results in TextDecoder not defined:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Uncaught ReferenceError: 'TextDecoder' is not defined
    at <anonymous> (script.js:1645)
    at <anonymous> (script.js:1882)
    at <eval> (script.js:1885)
', crates/spin-js-engine/src/lib.rs:193:15
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: the `wizer.initialize` function trapped

Caused by:
    wasm trap: wasm `unreachable` instruction executed
    wasm backtrace:
        0: 0x188002 - <unknown>!__rust_start_panic
    note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable to may show more debugging information

Swapping the imports order works around this issue. However, it would be great if TextEncoder, TextDecoder and others would be available without having to 1) care about the import order, and 2) manually add it as a dependency.

As a side note, I am bumping into a similar issue for new URL, but so far haven't been able to import a package that works around the issue.

Running make on the example results in the following warning — although the build succeeds.

$ make
...
mkdir -p target
crates/spin-js-cli/target/release/spinjs -o target/spin-http-js.wasm spin-http.js
warning: unknown name subsection with id 9 at 4807649

Do we want to consider aliasing spinSdk.http.send to fetch (or rather adapting it to the same signature)?

Does that set an expectation that certain functions are available, or is it helpful to have familiar constructs?

The package.json is defaulting name to "hello_world" the description to "". These should be templated based off spin new or spin add.

Hi folks! Loving spin so far, but I'm doing my development on a Linux ARM64 machine: is it possible to support this architecture in coming releases, please?

These functions are extremely useful for computing signatures for payloads.

Trying to send a response from TypeScript without headers:

Property 'headers' is missing in type '{ status: number; body: ArrayBufferLike; }' but required in type 'HttpResponse'.

However, this is not required in JavaScript.

I am trying to use an external package and the build fails with: Uncaught ReferenceError: 'process' is not defined

It would be nice if we could add the following methods to the HttpRequest interface to allow for easier handling of requests.

• json
• text
• formdata

The convention we are going for with new Spin SDK repositories is spin-<language>-sdk — would it make sense to rename this repository as well?

Scenario: I am trying to build a single component that can handle multiple paths.
How should one handle routing inside a component?

Here is what I currently have:

export const handleRequest: HandleRequest = async function(
  request: HttpRequest
): Promise<HttpResponse> {
  switch (request.headers["spin-path-info"]) {
    case "/list": {
      return await list(...);
    }
    case "/remove": {
      return await remove(...);
    }
    case "/add": {
      return await add(...);
    }

    default: {
      return { status: 500, headers: {} };
    }
  }

Do we want to consider a lightweight router? How would it look like?

When a user runs spin templates install --git https://github.com/fermyon/spin-js-sdk, Spin looks in the repo for a Git tag of the form spin/templates/vX.Y matching the major-minor version of Spin.

If that tag is found, Spin installs the version of the template at that tag. This means that if a SDK makes potentially breaking changes (for example, referring to new host components), old Spin versions still install templates with compatible SDK versions.

If no tag is found, Spin 'falls forward' and installs from main. This could cause Spin to pick up a template that references a SDK version that imports host services that aren't in the user's version of Spin, which would result in errors at runtime.

It would be good to start tagging the JS SDK repo with template version compatibility tags. We probably don't need to do older versions of Spin but maybe v0.7 and v0.8 tags so that users of those versions get stable versions of the templates?

Here is an example from the Spin repo itself:

The fetch function in the SDK takes an optional parameter options, which is defined as object in the TypeScript SDK:

    function fetch(uri: string, options?: object): Promise<FetchResult>;

This means there is no type checking for the options parameter, which makes fetch requests quite error prone.

In trying to use the SDK, I encountered the missing timeout function:

 ReferenceError: 'setTimeout' is not defined

Having the request URI already parsed using the URL object would make parsing query parameters and other usual operations easier.

This way, when importing, it would go from

import { HandleRequest, HttpResponse} from "@fermyon/spin-sdk-types"

to

import { HandleRequest, HttpResponse} from "@fermyon/spin-sdk"

Additionally, we might want to extend the SDK to include other things, not just types.

• Filesystem directory listing API (Node-style)

(TODO: add more as we think of them)

Ideally, we'd like spinjs to be a published NPM package that developers can npm add to their project to make Spin apps.

I've never done this, myself, so I don't know the best way to do it. A quick search turned up https://www.woubuc.be/blog/post/publishing-rust-binary-on-npm/, which might be a good place to start.

Ideally, this would be built and published via a GitHub action, but it could be just a bash script to start with.

Let's package spinjs as a spin plugin, and publish the TS type declarations separately as an NPM package.

A proper JS/TS binding generator would eliminate the boilerplate we're currently maintaining (and must update each time we expand or change the Spin WIT files).

However, we should probably not tackle this until #17 has been addressed and wit-bindgen has stabilized.

Steps to reproduce

• use the steps from here to init and build a new ts component
  i.e.

> spin new http-ts ts-hello-test --accept-defaults
> npm install
> spin build

• run spin build again

Result: When running spin build for the 2nd time you get the following error

Workaround

In order to build your app for the 2nd time, you need to manually delete the following folders: -p, dist and target

Other info:

OS: Windows 11 Pro, Version 10.0.22621 Build 22621
Spin: 0.7.1 (6cf7447 2022-12-19)
Spin plugin: js2wasm 0.1.0

In be913b9, we had to disable binaryen optimization for the Windows build because it was generating corrupt Wasm files. We should try with the latest release of binaryen to see if it's still an issue. If not, then lets upgrade. If so, then let's report the issue upstream.

Also, https://github.com/brson/wasm-opt-rs seems to be getting more attention than https://github.com/pepyakin/binaryen-rs, so we might want to switch.