# WASM integration memo

Expected usecases:

- Business logic functions (materializer)
- Incoming requests
- Event handlers
- Policy logic
- Extend platform
- Integrate off-the-shelf components
- Allow users to extend runtime
- Legacy/third-party integration

## Materializers

Materializers, in their design, need only take an input and return an output.
When accessing the outside world, they're currently constrained to the typegraph
that hosts them anything external must be mediated through it.

- Materializers are at a different layer than wherin the component model
operates.
- Component model semi-assume a static set of known interfaces that the
components adhere to.
- I.e. allowing coarser and foriegn peices of software to interoperate.
- Materializers are more aking to sections of a single codebase.
- Typescript works well in this role today and without wasm.
- Especially assisted with "codegen".

Open questions:

- A policy for the lifetime of a single materializer instance.
- Is it recreated for each request? (simpler)
- Can certain usecases (even handlers) benefit from long-lived instances?
- Opt in maybe?

Modeling this simple interface for wasm, there are multiple ways this can be
done.

### 1. Simple

- Old wasmedge approach.
- Users write and expose wasm-core functions.
- Host functionality is exposed through libraries that wrap the wasm-core
bindings.
- Libraries will need to be published for each guest language.

### 2. Component + Typegraph derived WIT world (wit_gen)

- Generate a WIT idl based on the typegraph.
- Contains types from the typegraph.
- Will refer to published WIT for common host functionality.
- `interface exposed {}` (stretch)
- World can import `exposed` to access wrapper functions for typegraph
exposed materializers.
- Eliminates need `gql` crutch.
- Users will author components that adheres to this spec.
- Code-generation falls on the WIT tooling of the language.
- User experience will vary depending on chosen guest launguage.
- Typegate will need to dynamically model and interact with the generated WIT.
- Most tooling today assumes static, compile time WIT but it is doable.

### 3. Component + Wire (wit_wire)

- Guests expose a single `handle` function that takes and returns JSON strings.
- Function will implement command pattern, commonly to respond to incoming
requests.
- Typegate will (de)serialize and validate the type shapes on both side.
- JSON is universally supported.
- Host will expose a single `hostcall` function.
- Implements JSON based command object pattern as well.
- Access to the typegraph exposed mats will take form of GraphQl queries.
- Use code generation to hide command action pattern.
- Users will only be exposed:
- types described in the typegraph
- stubs they implment for their materializers.
- Codegen will do the actual json command action pattern.
- Gql object (partially typed :crossed_fingers:) can function similarly.

Although, on paper, the wire protocol can be built upon wasm-core functions,
using WASI here would be advantageous since:

- When WASI 0.3 lands, it should allow easy async interop.
- Canonical ABI means we can minimize JSON usage.
- Allows for adaptors components that comsume wasi based components.

### VM based languages

VM based languages provide some challenges but also the opportunity to bridge
the gap with the golden standard of the Deno runtime. Since they'll ultimately
be used to implement materializers, their impl ought to be able to utilize the
`wit_wire` interface. SDK generators like `include_lambda` can be supported through
the `init-args` parameter.

### 4. Wasm core + Wire (core_wire)

This is similar to `wit_wire` but relies only on wasm core. Can be a used to add langauges that don't support components yet.

## Platform extension

Runtimes in their implementation today have a semi-standard interfaces.
Authoring a WIT world to model Runtimes seems pretty straight forward and would
end up using standard component model elements.

Now, as to what the usecases here are and on the question of how you'd make it
easy to extend the `sdk`, this document does not bite.

## Legacy integration

Compiling an already existing codebase to WASM is one avenue for legacy
integration. A rough sketch of that would be like:

- Use importers to generate typegraph types for the legacy codebase interface.
- A special runtime that exposes works with `wasi:http/incoming-handler`.
- Makes use of standard wasi component model elements.