Project Architecture

The wasmer-pack project is split across several crates depending on the various ways it might be used.

The main crates are:

  • crates/wasmer-pack - this is the meat and potatoes of wasmer-pack. It contains all the code for generating bindings to WebAssembly modules, plus templates for any glue code that will be needed along the way
  • crates/cli - this is a CLI tool that lets wasmer-pack generate bindings using the commands and libraries inside a Pirita file
  • crates/wasm - this is a wrapper that makes wasmer-pack available as a WebAssembly module. The functions and data types that are exposed are defined in crates/wasm/wasmer-pack.exports.wai (see WIT.md for the syntax)

Architecture Decision Records

An architectural decision record (ADR) is a document that describes a choice the team makes about a significant aspect of the software architecture they’re planning to build. Each ADR describes the architectural decision, its context, and its consequences.

The goal is to get knowledge about a decision out of a developer's head so it doesn't get lost to time.

ADRs aren't big documents - if you are writing more than a couple paragraphs, you are probably doing it wrong!

(click to see the template)
# (short title of solved problem and solution) | Metadata | Value | | -------- | ----------------------------------------------------------------------------------- | | Status | *proposed, rejected, accepted, deprecated, superseded by [ADR-123](123-example.md)* | ## Context and Problem Statement *(Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.)* ## Decision Drivers <!-- optional --> 1. *(driver 1, e.g., a force, facing concern, …)* 2.<!-- numbers of drivers can vary --> ## Considered Options 1. option 1 2. option 2 4.<!-- numbers of options can vary --> ## Decision Outcome Chosen option: "option 1", because (justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best). ### Positive Consequences <!-- optional --> - (e.g., improvement of quality attribute satisfaction, follow-up decisions required, …) -### Negative Consequences <!-- optional --> - (e.g., compromising quality attribute, follow-up decisions required, …) -## Pros and Cons of the Options <!-- optional --> ### option 1 *(example | description | pointer to more information | …)* <!-- optional --> - Good, because X - Good, because Y - Bad, because Z -<!-- numbers of pros and cons can vary --> ## Links <!-- optional --> - []()