Skip to main content

Developer Loop

When we think of the concept of a developer loop, two variants typically come to mind: inner and outer. The outer loop refers to the cycle that begins when your code is checked into version control and begins integration with the rest of the world. The focus of this doc is the inner loop: the process a single developer goes through to write, test, and debug code.

At a high level, the inner developer loop is created when we start a new project. We then get on the treadmill which includes the following steps:

  1. Change
  2. Run
  3. Analyze
  4. Repeat

Inner loop

Create Project

Creating a new project that will produce an actor you intend to publish in a Cosmonic constellation is as simple as starting a new wasmCloud project. Here we use the wash new actor ... command to build an empty project from one of the available templates. You'll be prompted for (or you can explicitly supply) a project name and any other required information. The output of a newly generated project is ready to build and deploy.


The process of changing your code will vary depending on the language and environment you're using. Today, the most robust ecosystem for building WebAssembly targets is Rust, but other languages are rapidly smoothing out the developer experience.

One of the most important aspects of the change portion of the developer loop, regardless of language, is producing a signed WebAssembly module (.wasm file). The existence or update of this file is the catalyst that will move you to the next step in the developer loop.

Our project templates come with Makefiles that produce these files, but you're free to use whatever automation you like to help rapidly produce the signed modules. By default, we generate files that have an _s suffix on them to indicate a signed module, e.g. echo_s.wasm or kvcounter_s.wasm.


All WebAssembly modules require a host to run, and ours are no different. Whether hosted and managed by Cosmonic, or running on your own infrastructure, you'll need to start your actor inside a wasmCloud host to "run" it. Starting an actor on a local wasmCloud host is as simple as running cosmo launch from within your actor's directory.


If you prefer, you can also interact with the wasmCloud host's local web dashboard (affectionately referred to as the washboard) and use hot reloading to continually monitor that signed file. Any time the file changes, the wasmCloud host will seamlessly reload it.

Invoking Actors

There are many ways to invoke an actor. If you favor command-line interaction, you can always use the wash CLI to run wash call {actor} {operation} {JSON data} to invoke the actor directly.

Unless your actor is a "pure" function and does nothing but return data in response to a request, it will need to utilize one or more capability providers to perform its task.

The actor is your unit of deployment and an encapsulation of business logic. The capability providers are implementations of your non-functional requirements. Link definitions establish a configured link between the two. All three must be in place for an actor to be usable in a host.

For instructions on how to start providers and add link definitions, including how to do this with a number of sample providers and actors, take a look at the relevant wasmCloud documentation.


The analysis phase of the developer loop is where you sit back and bask in the radiant glory of the flawless actor you just created. Or, on the remarkably rare occasion when there is a bug, you can take a look at the results of the invocation to see what went wrong.

wasmCloud hosts have a number of excellent troubleshooting tools available. The first and most easily used, of course, is the standard output log. Watching the console output with debugging or tracing enabled is an invaluable source of information. An excellent troubleshooting tool, especially when running multiple hosts, is running your NATS server with the -DV option, which turns on verbose debugging.

Another incredibly valuable tool is OpenTelemetry Tracing. This lets you keep track of everything that happened in distributed traces. The wasmCloud host comes pre-wired to emit this data, all you need to do is set up a collector and configure the host to emit to that collector. As you can see in the screen capture below, you can get incredibly detailed and actionable information every time you invoke your actor.

Sample Trace

Deploy (Exit the Loop)

When you're satisfied that what you've built is flawless and ready to deploy, you can consult any of our documentation on the various ways you can deploy and manage your actors, providers, and applications. In particular, you may want to read the deploying your application guide.