The WRAP Standard
version 1.0
At the core of Polywrap is The WRAP Standard. This standard enables SDK developers to create highly-composable modules and application developers to integrate them with a single line of code.
WRAP stands for WebAssembly Random Access Protocol.
WebAssembly - A secure-by-default, portable, lightweight, bytecode standard.
Random Access - Any WRAP module is accessible on-demand via its URI.
Protocol - A set of rules and procedures for loading & executing WRAP modules.
You can think of WRAP as an interoperability/abstraction standard on top of WebAssembly.
Why Another Standard?
With "vanilla" WebAssembly, a few shortcomings limit its adoption.
Composability - There is no easy way to create inter-module dependencies, drastically limiting the wasm community's ability to re-use code.
Interfaces - There is no standard for defining typed interfaces for your wasm modules. This means that vanilla wasm modules are opaque blobs of bytecode, making it hard to integrate them into applications.
Complex Data Passing - By default, vanilla wasm only supports the passing of integers between the host <> wasm boundary, making it difficult to pass complex data structures (ex: struct, array, etc.) into / out of / between wasm modules.
Naming & Addressing - Just as any other resource on the web, there needs to be a way to address a wasm module using a tailored URI format.
How Does WRAP Work?
Building Wrappers
Building WRAP compatible WebAssembly modules can be broken down into the following steps:
-
Define an Interface
All WRAP modules have semantic interfaces that describe the module's: methods, custom types, and dependencies.Related Standards: Interfaces
-
Generate Bindings
WRAP interfaces are "bound" automatically through codegen to the implementation language of the wrappers. These bindings are used to support the easy development of wrappers by providing:- Type Safety
- Data Marshalling
- Client Interactions
Related Standards: Serialization
-
Compile Wasm
Once all methods have been implemented, wasm-based wrappers must expose all necessary exports (invoke, asyncify, etc.), and require imports supported by the client (subinvoke, get implementations, etc.).Related Standards: WebAssembly Runtime
-
Build Wrapper
All wrapper build artifacts are aggregated into a single build folder.Related Standards: Wrapper Artifacts
Deploying & Embedding Wrappers
The wrapper build artifacts generated by the build pipeline can be deployed to a network or filesystem, or embedded directly inside of applications so that integrators can access them by their URI.
Related Standards: URI, URI Resolution
Invoking Wrappers
Integrating wrappers into applications can be done by using any WRAP client. Invocations are made to wrappers by providing the wrapper's URI and method to be executed.
Related Standards: Invocation
Exposing Application Capabilities
Application developers can choose what host capabilities the wrappers have access to through the use of "plugins". These plugins are written in the language of the application, and run natively within your application memory (unlike WebAssembly which is sandboxed).
Related Standards: Plugins
Extending Wrapper Interfaces
Wrapper interfaces can become standardized, enabling multiple implementations to be used within the same application dynamically. Wrappers can be registered as "implementations" ahead of time or discovered on-demand at runtime.
Related Standards: Standard Interfaces
What Does WRAP Enable?
We like to refer to wrappers as "next-gen SDKs". This is because they are better than traditional SDKs in the following ways:
Multi-Platform - Write your SDK once, use it anywhere. Simply add a WRAP client to your application.
Secure - Sandboxing keeps users safe by isolating wrappers from application memory.
Scalable - Keep apps lightweight and efficient. Only download what you need when you need it.
Composable - Endlessly compose and extend wrappers with imports and standard interfaces.
Upgradable - Ditch the rebuilds with configurable runtime updates.