Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix broken links #338

Merged
merged 1 commit into from Mar 20, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 2 additions & 2 deletions blog/caps_are_effects.md
Expand Up @@ -49,7 +49,7 @@ A lot of us are used to patterns like (micro)services, abstractions, anti-corrup

In a traditional object-oriented language or framework, we might treat each of these "effect providers" as an interface and then use something like dependency injection to shunt in an implementation for the effect at runtime (and presumably shunt in a mock during test time).

In wasmCloud, we manage algebraic effects through <u>[capability providers](https://wasmcloud.dev/reference/host-runtime/capabilities/)</u>. Here the capability provider, as seen by the WebAssembly module (<u>[actor](https://wasmcloud.dev/reference/host-runtime/actors/)</u>), is just an abstraction. It's a versioned contract through which the WebAssembly function gets its effects.
In wasmCloud, we manage algebraic effects through <u>[capability providers](https://wasmcloud.com/docs/concepts/capabilities)</u>. Here the capability provider, as seen by the WebAssembly module (<u>[actor](https://wasmcloud.com/docs/concepts/actors)</u>), is just an abstraction. It's a versioned contract through which the WebAssembly function gets its effects.

The host runtime is responsible for providing an implementation for those effects or effect providers. This implementation is hot-swappable and dynamically configurable. This means that in our preceding international withdrawal example, we could provide a "test market" at unit test time and then a real connection to the market service when running in production. We could also configure the market connection so it could be "real", but point to a different service in staging than in production.

Expand All @@ -59,7 +59,7 @@ Algebraic effects don't need to be big, high-level concepts like database or net
Logger.debug("Performing international withdrawal")
```

wasmCloud takes these algebraic effects even further by requiring each of our WebAssembly modules to be <u>[cryptographically signed](https://wasmcloud.dev/reference/host-runtime/security/)</u> with the explicit list of capabilities it can use (effects it can produce).
wasmCloud takes these algebraic effects even further by requiring each of our WebAssembly modules to be <u>[cryptographically signed](https://wasmcloud.com/docs/hosts/security)</u> with the explicit list of capabilities it can use (effects it can produce).

Ultimately what we've done is provided a means to maintain portable function purity in WebAssembly modules while allowing for all algebraic effects to not only be testable, but distributed, hot-swappable, and dynamically scalable across a flat topology system comprised of multiple disparate environments.

Expand Down
Expand Up @@ -13,7 +13,7 @@ draft: false

_[TinyGo](https://tinygo.org)_ is _"a Go compiler for small places"_. It is a language designed specifically to work on embedded systems and WebAssembly. If you squint hard enough, you can almost imagine that WebAssembly is a form of embedded system (it's embedded in a host runtime).

One of the core tenets of wasmCloud has always been that we embrace the specification without doing anything proprietary. In other words, anyone who knows the "<u>[wasmCloud ABI](https://wasmcloud.dev/reference/wasmbus/ffi/)</u>" can create actors in any language that compiles to freestanding WebAssembly. While this is technically true, it's certainly a lot easier when we have an easy SDK and code generation support for a language. Using our SDKs gives you a more friendly library while helping insulate your code from changes to the underlying WebAssembly spec.
One of the core tenets of wasmCloud has always been that we embrace the specification without doing anything proprietary. In other words, anyone who knows the "<u>[wasmCloud ABI](https://wasmcloud.com/docs/hosts/abis/wasmbus/)</u>" can create actors in any language that compiles to freestanding WebAssembly. While this is technically true, it's certainly a lot easier when we have an easy SDK and code generation support for a language. Using our SDKs gives you a more friendly library while helping insulate your code from changes to the underlying WebAssembly spec.

The newest language in our arsenal is TinyGo.

Expand Down
Expand Up @@ -29,7 +29,7 @@ Some of the best-known organizations develop in Go; Google, Uber, Netflix, Twitc

wasmCloud has supported Go for [some time](https://wasmcloud.com/blog/example_creating_webassembly_actor_in_go_with_tinygo). As many in the community know, there are several TinyGo example Wasm applications, including `echo actor`, `blobby actor` and `kv-counter actor`, which were written around WASI-Preview 1 specifications. These examples compile to wasm modules and use our stable ABI and, as such, they rely on a few wasmCloud-specific dependencies to successfully run there.

As wasmCloud is engineered around WASI-Preview 2, we have rewritten these actors to use WASI contracts; completely removing any dependencies. Smithy is a thing of the past as we focus on [WIT](https://cosmonic.com/blog/engineering/wit-cheat-sheet) to bind together polyglot components. Take a look at our new WASIfied apps [echo-http-server](https://github.com/wasmCloud/wasmCloud/tree/main/examples/golang/actors/http-echo-tinygo) and [globby-wasi](https://github.com/jordan-rash/globby-wasi) (blobby reimagined in Go!).
As wasmCloud is engineered around WASI-Preview 2, we have rewritten these actors to use WASI contracts; completely removing any dependencies. Smithy is a thing of the past as we focus on [WIT](https://cosmonic.com/blog/engineering/wit-cheat-sheet) to bind together polyglot components. Take a look at our new WASIfied apps [echo-http-server](https://github.com/wasmCloud/wasmCloud/tree/release/v0.82.0/examples/golang/actors/http-echo-tinygo) and [globby-wasi](https://github.com/jordan-rash/globby-wasi) (blobby reimagined in Go!).

This means developers can port their Wasm applications to wasmCloud without any additional requirements. It also means, when componentized, applications are even tinier than before.

Expand Down
2 changes: 1 addition & 1 deletion blog/wasi-preview-2-officially-launches/index.mdx
Expand Up @@ -83,7 +83,7 @@ fn rocket() -> _ {
}
```

Note that there are no Wasm interfaces here! This is actually copy/pasted from the [Rocket homepage](https://rocket.rs/v0.4/). The ideal experience is that developers can use idiomatic community and standard libraries to write their code, then simply compile to a Wasm binary. We're not quite at this point yet, but WASI 0.2.0 is the first step in this direction because it provides a common standard set of interfaces for library developers to build on top of.
Note that there are no Wasm interfaces here! This is actually copy/pasted from the [Rocket homepage](https://rocket.rs/). The ideal experience is that developers can use idiomatic community and standard libraries to write their code, then simply compile to a Wasm binary. We're not quite at this point yet, but WASI 0.2.0 is the first step in this direction because it provides a common standard set of interfaces for library developers to build on top of.

[WASI Preview 2 contains the following APIs:](https://github.com/WebAssembly/WASI/tree/main/preview2#wasi-preview-2-contents)

Expand Down
Expand Up @@ -29,7 +29,7 @@ are able to glue together arbitrary Wasm modules that import or export functions
interface file. These interface files are called `wit` files (Wasm Interface Types) and allow for
language agnostic code generation. This code is what handles converting the raw numbers of plain
Wasm (i.e. integers and bytes) into concrete types. If you are familiar with wasmCloud already, this
is [very similar](https://wasmcloud.dev/interfaces/) to what we call "contract driven development,"
is [very similar](https://wasmcloud.com/docs/1.0/concepts/interfaces) to what we call "contract driven development,"
which we use to separate non-functional requirements from business logic. Still confused? Don't
worry, we'll be using some specific examples below. If this topic interests you and you'd like more
information, we highly recommend you check out all of the
Expand Down Expand Up @@ -543,8 +543,8 @@ current users.
We will also need to rely more heavily on [Bindle](https://github.com/deislabs/bindle) and
eventually on the forthcoming component registry work from the Bytecode Alliance. These tools are
designed specifically to account for assembling various parts of a final application (like the
various interfaces and different modules). We already have [experimental support for
bindles](https://wasmcloud.dev/reference/bindle/) in wasmCloud, but they have to be hand rolled
various interfaces and different modules). We already have experimental support for
bindles in wasmCloud, but they have to be hand rolled
rather than being automatically created. There also needs to be a place from which you can fetch the
necessary interfaces for use in building. All of these elements of developer experience are
important to have before we roll this out.
Expand Down
2 changes: 1 addition & 1 deletion community/2023-02-15-community-meeting.mdx
Expand Up @@ -21,7 +21,7 @@ import ReactPlayer from 'react-player/youtube';
- Additionally, we are also looking into running our examples in a devcontainer so that users could easily go from looking at the repo to a fully featured example environment
- Conferences
- Kevin will be speaking at KubeCon EU 2023! "Distributed Event Sourcing with wasmCloud" https://kccnceu2023.sched.com/event/1Hycy/distributed-event-sourcing-with-wasmcloud-kevin-hoffman-cosmonic
- Bailey Hayes and Dan Chiarlone will be speaking at wasm.io on wasi-cloud: https://wasmio.tech/sessions/wasi-cloud-the-future-of-cloud-computing-with-webassembly/
- Bailey Hayes and Dan Chiarlone will be speaking at wasm.io on wasi-cloud: https://www.youtube.com/watch?v=Z7cSjIp7vRg
- Bailey and Taylor will be running a "wasmCloud crash course with Cosmonic" at wasm.io (link forthcoming)
- General ranting
- We talked about devcontainers, nix, guix, haskell, lisp, and more!
Expand Down
2 changes: 0 additions & 2 deletions community/2023-10-18-community-meeting.mdx
Expand Up @@ -41,8 +41,6 @@ import ReactPlayer from 'react-player/youtube';
- ⚠ There are unfortunately lots of ways to stub your toes currently on the WebAssembly toolchain while trying to build Preview2 components, so there maybe be errors!
- Once your module is built, we can use `wasm-tools` to see the component model imports and exports.
- Command: `wasm-tools component wit path/to/file.wasm`
- A great example to follow is [`kvcounter-wasmcon2023` in `wasmCloud/examples`](https://github.com/wasmCloud/examples/tree/main/actor/kvcounter-wasmcon2023)
- Use the [`just`][just] commands in there to run commands (run `just` to get a list of available commands)
- For stuff like Preview2 to work, *multiple* things have to match up:
- WASI spec & WIT definitions in the adapter
- WASI spec & WIT definitions in the component itself
Expand Down
2 changes: 1 addition & 1 deletion community/2024-02-21-community-meeting.mdx
Expand Up @@ -30,7 +30,7 @@ import ReactPlayer from 'react-player/youtube';

**IMPORTANT: Calling all community members; please try 0.82 for yourselves. We'd love your feedback**

**DISCUSSION: [Roadmap](https://www.notion.so/wasmCloud-Weekly-Notes-98f84ac55c4349dba9c399aa4ba064dc?pvs=21) check-in**
**DISCUSSION: Roadmap check-in**
- Huge amount of progress in the wRPC project thanks to Roman and Victor.
- Swarming on the wasmCloud host right now.
- We are planning on making changes to wasmCloud host and testing suite.
Expand Down
8 changes: 1 addition & 7 deletions docs/reference/faq.mdx
Expand Up @@ -46,14 +46,10 @@ wasmCloud applications are composed of [components](/docs/1.0/concepts/component

wasmCloud supports building and running components written in any language that can target WebAssembly. The WebAssembly components ecosystem is rapidly evolving, so the ease of working with open-source tooling will vary by language. Languages with the best experience today include Rust, Go, Python, and JavaScript.

### Where can I find examples of wasmCloud components, providers, and applications?
### Where can I find examples of wasmCloud components?

The latest examples of components are in the main repo, under the [examples directory](https://github.com/wasmCloud/wasmCloud/tree/main/examples).

For examples of first-party capability providers, check out the [providers directory](https://github.com/wasmCloud/wasmCloud/tree/main/crates/providers).

Every example also includes an [application manifest](/docs/1.0/ecosystem/wadm/model#application), which can be used to deploy the example.

### I see wasmCloud components are stateless, but I need to store state. Is wasmCloud right for me?

wasmCloud applications can access and store state via [capability providers](/docs/1.0/concepts/providers). Only components are stateless (between invocations).
Expand All @@ -62,8 +58,6 @@ wasmCloud applications can access and store state via [capability providers](/do

Capability providers can implement capabilities directly and act as proxies to external capabilities, depending on the needs of your application.

For example, the [HTTP Server provider](https://github.com/wasmCloud/wasmCloud/tree/main/crates/providers/http-server) _is_ a server, while the [Redis provider](https://github.com/wasmCloud/wasmCloud/tree/main/crates/providers/kv-redis) acts as a _client_ to an external Redis server.

### How does wasmCloud handle versioning?

wasmCloud applications, and their components, are versioned. [Application manifests](/docs/1.0/ecosystem/wadm/model#application) include a version, which allows for upgrading (or rolling back) to a different version.
Expand Down
6 changes: 3 additions & 3 deletions versioned_docs/version-0.82/reference/faq.mdx
Expand Up @@ -48,9 +48,9 @@ wasmCloud supports building and running actors written in any language that can

### Where can I find examples of wasmCloud actors, providers, and applications?

The latest examples of actors are in the main repo, under the [examples directory](https://github.com/wasmCloud/wasmCloud/tree/main/examples).
The latest examples of actors are in the main repo, under the [examples directory](https://github.com/wasmCloud/wasmCloud/tree/release/v0.82.0/examples).

For examples of first-party capability providers, check out the [providers directory](https://github.com/wasmCloud/wasmCloud/tree/main/crates/providers).
For examples of first-party capability providers, check out the [providers directory](https://github.com/wasmCloud/wasmCloud/tree/release/v0.82.0/crates/providers).

Every example also includes an [application manifest](/docs/ecosystem/wadm/model#application), which can be used to deploy the example.

Expand All @@ -62,7 +62,7 @@ wasmCloud applications can access and store state via [capability providers](/do

Capability providers can implement capabilities directly and act as proxies to external capabilities, depending on the needs of your application.

For example, the [HTTP Server provider](https://github.com/wasmCloud/wasmCloud/tree/main/crates/providers/http-server) _is_ a server, while the [Redis provider](https://github.com/wasmCloud/wasmCloud/tree/main/crates/providers/kv-redis) acts as a _client_ to an external Redis server.
For example, the [HTTP Server provider](https://github.com/wasmCloud/wasmCloud/tree/release/v0.82.0/crates/providers/http-server) _is_ a server, while the [Redis provider](https://github.com/wasmCloud/wasmCloud/tree/release/v0.82.0/crates/providers/kv-redis) acts as a _client_ to an external Redis server.

### How does wasmCloud handle versioning?

Expand Down