Defining Golem Components in TypeScript
Creating a project
Using Golem's command line interface provides a set of predefined, Golem-specific examples to choose from as a starting point.
To see the available examples for TypeScript, run:
$ golem-cli list-examples --language ts
The set of examples provided by Golem CLI is defined in the open-source repository golem-examples (opens in a new tab).
Then to create a new project based on the default TypeScript example, run:
$ golem-cli new --language ts --package-name 'golem:demo' ts-example
The command will create a new Golem project in the ts-example
directory, and print short, language-specific instructions on how to build the project.
Specification-first approach
Golem and the TypeScript toolchain currently requires defining the component's interface using the WebAssembly Interface Type (WIT) format. See the official documentation of this format (opens in a new tab) for reference.
Each new project generated with golem-cli
contains a wit
directory with at least one .wit
file defining a world
. This world can contain exports (exported functions and interfaces) and these exports will be the compiled Golem component's public API.
The first time a component is compiled (see the Building Components page for details), a couple of files get generated in a subdirectory named src/generated
. The generated sources contain the definitions of all the data types and interfaces defined in the WIT
file(s) as TypeScript types and interfaces.
To implement the specification written in WIT, the TypeScript code must implement some of these generated interfaces and export them in main.ts
.
Exporting top-level functions
WIT allows exporting one or more top-level functions in the world
section, for example:
package golem:demo;
world example {
export hello-world: func() -> string;
}
To implement this function in TypeScript we simply have to export a function with matching names and types in main.ts
:
export function helloWorld(): string {
return "hello"
}
Note that in WIT, identifiers are using the kebab-case
naming convention, while TypeScript uses
the PascalCase
and camelCase
convention. The generated bindings map between these are handled
automatically.
Exporting interfaces
WIT supports defining and exporting whole interfaces, coupling together multiple functions and possibly custom data types.
Take the following example:
package golem:demo;
interface api {
add: func(value: u64);
get: func() -> u64;
}
world example {
export api;
}
This is similar to having the two exported functions directly exported from the world
section, but there is a corresponding TypeScript interface generated that needs to be separately implemented and exported:
import { Api } from "./generated/example.js"
let state = BigInt(0)
export const api: Api = {
add(value: bigint) {
console.log(`Adding ${value} to the counter`)
state += value
},
get(): bigint {
return state
},
}
Using the generated interfaces also helps during development, as it can guide IDEs and the TypeScript compiler to create the expected exports.
See the Managing state section below to learn the recommended way of managing state in Golem components, which is required to implement these two functions.
Exporting resources
The WIT
format supports defining and exporting resources - entities defined by their constructor function and the available methods on them.
Golem supports exporting these resources as part of the worker's API.
The following example modifies the previously seen counter example to define it as a resource, getting the counter's name as a constructor parameter:
package golem:demo;
interface api {
resource counter {
constructor(name: string);
add: func(value: u64);
get: func() -> u64;
}
}
world example {
export api;
}
Resources can have multiple instances within a worker. Their constructor returns a handle which is then used to call the methods on the resource. Learn more about how resources can be implicitly created and invoked through Golem's APIs in the Invocations page.
To implement the above defined WIT resource in TypeScript a few new steps must be taken:
- define a class representing the resource - it can contain data!
- implement the interface generated as the resource's interface for this class named
CounterInstance
- implement the constructor on the component class as defined by the interface
CounterStatic
The CounterStatic
interface cannot be implemented by the Counter
class, but the constructor
in Counter
will be checked against the new
method defined in CounterStatic
.
Let's see in code:
import { Api, CounterInstance, CounterStatic } from "./generated/example.js"
class Counter implements CounterInstance {
name: string
state = BigInt(0)
constructor(name: string) {
this.name = name
}
add(value: bigint): void {
this.state += value
}
get(): bigint {
return this.state
}
}
export const api: Api = {
Counter: Counter,
}
Data types defined in WIT
The WIT
specifications contains some primitive and higher level data types and also allows defining custom data types which can be used as function parameters and return values on the exported functions, interfaces and resources.
The following table shows an example of each WIT
data type and its corresponding TypeScript type:
WIT Type | Typescript Type | Notes |
---|---|---|
bool | boolean | |
u8, s8, u16, s16, u32, s32, f32, f64 | number | |
u64, s64 | bigint | |
char | string | Represents a single Unicode character |
string | string | |
list<T> | T[] | For most types |
list<u8> | Uint8Array | Special case for byte arrays |
tuple<T1, T2, ...> | [T1, T2, ...] | |
record | interface | Fields become properties |
variant | union of interfaces | Each case becomes an interface with a tag and optional val |
enum | union of string literals | |
option<T> | T | null | If T can be represented as null |
option<T> | Option<T> | If T cannot be represented as null |
result<T, E> | Result<T, E> | |
result<_, string> | Result<void, string> | |
flags | interface | Each flag becomes an optional boolean property |
resource | class | Methods become class methods |
Note: The Option
and Result
types are automatically included in the generated TypeScript if they are detected in the WIT interface.
They are defined as follows:
export type Option<T> = { tag: "none" } | { tag: "some"; val: T }
export type Result<T, E> = { tag: "ok"; val: T } | { tag: "err"; val: E }
WIT records
The following WIT record type:
package golem:demo;
interface api {
record user {
id: u64,
name: string,
}
}
Will generate the following TypeScript interface:
export interface User {
id: bigint
name: string
}
WIT variants
The following WIT variant type:
package golem:demo;
interface api {
variant color {
red,
green,
blue,
rgb(u32),
hex-color(string),
}
}
Will generate the following TypeScript discriminated union:
export type Color = ColorRed | ColorGreen | ColorBlue | ColorRgb;
export interface ColorRed {
tag: 'red',
}
export interface ColorGreen {
tag: 'green',
}
export interface ColorBlue {
tag: 'blue',
}
export interface ColorRgb {
tag: 'rgb',
val: number,
}
export interface ColorHexColor {
tag: 'hex-color',
val: string,
}
WIT enums
The following WIT enum type:
package golem:demo;
interface api {
enum color {
red,
green,
blue
}
}
Will generate the following Typescript union:
export type Color = 'red' | 'green' | 'blue';
and a set of helper functions.
WIT flags
The following WIT flags type:
package golem:demo;
interface api {
flags access {
read,
write,
lst
}
}
Will generate the following TypeScript interface:
export interface Access {
read?: boolean
write?: boolean
lst?: boolean
}
Worker configuration
It is often required to pass configuration values to workers when they are started.
In general Golem supports three different ways of doing this:
- Defining a list of string arguments passed to the worker, available as command line arguments
- Defining a list of key-value pairs passed to the worker, available as environment variables.
- Using resource constructors to pass configuration values to the worker.
Command line arguments and environment variables
Command line arguments and environment variables are accessible through the generated bindings:
import { getArguments, getEnvironment } from "wasi:cli/environment@0.2.0"
const args: string[] = getArguments()
const env: [string, string][] = getEnvironment()
Environment variables can be specified when a worker is explicitly created, but there are some environment variables that are always set by Golem:
GOLEM_WORKER_NAME
- the name of the workerGOLEM_COMPONENT_ID
- the ID of the worker's componentGOLEM_COMPONENT_VERSION
- the version of the component used for this worker
In addition to these, when using Worker to Worker communication, workers created by remote calls inherit the environment variables of the caller.
This feature makes environment variables a good fit for passing configuration such as hostnames, ports, or access tokens to trees of workers.
Resource constructors
As explained earlier, Golem workers can export resources and these resources can have constructor parameters.
Although resources can be used in many ways, one pattern for Golem is only create a single instance of the exported resource in each worker, and use it to pass configuration values to the worker. This is supported by Golem's worker invocation syntax directly, allowing to implicitly create workers and the corresponding resource by a single invocation as described on the Invocations page.
Managing state
Golem workers are stateful. There are two major techniques to store and manipulate state in a Golem worker implemented in TypeScript:
- Using a global variable
- Using resources and storing state in the resource's class
All techniques were demonstrated above in the code examples.