On the magic box concern, Wasm is pretty different from the other serverless approaches (isolates, BEAM, JVM-based, etc) that can be a bit more “magical”. A Wasm component can be inspected prior to compilation, the binary itself is a declarative definition of the capabilities needed to run as function imports. Those imports are standardized via WASI. This is one of several reasons why a Wasm binary is more portable than a container where it can run on any CPU architecture, operating system, and environment with different capabilities.
From a local development perspective, it’s so much easier to use a Wasm component that uses interfaces like the blobstore. For development I can use implementations I have in my local dev environment, e.g. a local FS, but in production I can use the same abstraction to connect to S3. This gives you serverless without requiring the entire services stack.
From a local development perspective, it’s so much easier to use a Wasm component that uses interfaces like the blobstore. For development I can use implementations I have in my local dev environment, e.g. a local FS, but in production I can use the same abstraction to connect to S3. This gives you serverless without requiring the entire services stack.