SpiderLightning defines a set of WebAssembly Interface Types (i.e., WIT) files that abstract distributed application capabilities, such as state management, pub/sub, event driven programming, and more.
In simple terms, SpiderLightning allows you to go:
| From this: | To this: |
|---|---|
 |
 |
/wit: the SpiderLightning specification written in*.witformat (see WIT)/src: the SpiderLightning host cli (i.e., Slight)/crates: service implementations/examples: guest examples/tests: guest tests
Do you want to contribute to SpiderLightning's growth?
Start with our CONTRIBUTING.md
$ git clone https://github.com/deislabs/spiderlightning.git && cd spiderlightning/ # clone our repo locally and go into it
$ make install-deps # installs the WASI-SDK
$ make build # builds SpiderLightning/Slight
$ make build-c # builds our c example
$ make run-c # runs our c exampleNote: There are also Rust examples that can be built (
build-rust) and ran (run-rust). However, some of these examples have some dependencies on environment variables or local programs (e.g.,etcd), so it probably won't work right off the gate like the C one did.
Spiderlightning is a collection of common application interfaces exposed through WebAssembly intended to make cloud-native application development simpler. These interfaces are available to WebAssembly applications through the slight Command Line Interface (CLI) and host runtime that implements these interfaces using a backend of choice. For example, for the "message queue" interface, SpiderLightning may provide backends implemented by Azure Storage Bus, Apache Kafka, and more.
Spiderlightning's interfaces offer developers a set of provider-agnostic APIs which enable developers to write portable applications without having to take direct dependencies on vendor specific APIs and SDKs.
Applications targeting Spiderlightning can leverage these interfaces to reduce the amount of code written to achieve tasks such as persisting key/values, participating in pub/sub, handling messages from a message queue, and much more. By reducing the code footprint, Spiderlightning also enables application binaries to be much smaller, often an order of magnitude smaller than similar container-based applications. This feature further increases the portability of applications to target constrained runtime environments like edge devices.
WASI's primary goal is to provide operating system abstractions for Wasm applications running outside of browser environments. SpiderLightning interfaces extend WASI to provide application capabilities, such as state management, event-driven pattern, or distributed locking. In the future, we hope that SpiderLightning's interfaces or interfaces that provide similar capabilities become part of WASI specification.
SpiderLightning and Dapr share the same goal of providing capabilities to distributed applications, but each project's approach to achieving this goal is very different. For example, while Dapr runs as a sidecar container and provides an HTTP/gRPC interface for applications, SpiderLightning's chooses not take a dependency on network transport protocols. Instead, slight links applications directly to generated WASM bindings, then executes them directly.