Product Tour
Welcome aboard, Cosmonaut! This quickstart will walk you through the application UI to get you familiar with the controls. Then, you'll set up and deploy your first application.
When you first land on your empty constellation, you'll see a tool palette at the top left of the canvas:
The first thing we need is a host. Hosts are wasmCloud processes that, as the name implies, host actors and capability providers. Click on the Host+ icon and it will bring up a new host dialog as shown in the following image:
You can specify an arbitrary set of labels that you want to put on the host. These can be used later
in an auction when you're looking for a suitable host on which to
deploy actors or providers. After you click the Launch Host button, you will see a pulsing gray
box letting you know the host is being provisioned. Once it's up and running, you'll see an element
on your constellation's infrastructure view that looks similar to this:
Now that you've got a host running, you've got something on which you can deploy actors and
providers. First, let's start an actor on our host (remember that your host names won't match the
ones in the screenshots). Click the Logic view button at the top to switch to the
logic view. This view shows you all of your actors and providers
and how they're connected, regardless of where they're running.
Click the Actor+ button on the the tool palette on the top left of the canvas, and you'll be presented with a dialog similar to this one:
| Launch Actor Dialog |
|---|
 |
An OCI Reference is a URL that points to a versioned artifact,
like you might find in Docker Hub, but we use it for .wasm files or capability providers. Here
we've chosen the OCI reference wasmcloud.azurecr.io/echo:0.3.5, which is our sample echo actor.
This actor receives an HTTP request and responds with a copy of what it was sent.
While any capability provider that implements the right contract can be used, we're going to link this actor to our wormhole-compatible provider. To do this, first we'll launch this provider. Click the Provider+ button on the tool palette and fill out the dialog as shown below (remember your host name will be different):
| Launch Provider Dialog |
|---|
 |
In a few moments, the provider will start. Your logical view should now contain the echo actor and a web server. It should look similar to the following:
| Actor and Provider |
|---|
 |
Linking the actor and provider is as simple as dragging from the outlet (the circle) on the Echo
element to the inlet on the HTTP Server - (Wormhole) element. You'll be prompted to supply
configuration values by a dialog that looks like this:
| Link Definition Dialog |
|---|
 |
Because this is going to be accessed through a Cosmonic wormhole, you don't need to supply any
configuration data here. You can simply click the Link Actor button and a new line will appear on
your canvas:
| Linked Actor and Provider |
|---|
 |
We're almost there! Everything you run inside your constellation is secure by default and the public internet has no access. However, when you want to expose a particular API managed by one of your actors, you can do so through a wormhole. To create a new wormhole, click the Wormhole+ button in the tool palette at the upper left of your canvas:
| Add Wormhole |
|---|
 |
Leave all these values as the default and click the Create Wormhole button. After the wormhole has
been provisioned (the color stops pulsing), your canvas should show connection lines between the
actor and provider, and between the provider and the wormhole.
With a wormhole granting access to your echo actor, you can now use it! The easiest way to check out
your wormhole is to click the Access your wormhole button in the details panel when it is
selected:
| Wormhole Details |
|---|
 |
This will open a new browser tab pointing at your new public endpoint, and you should see output that looks like this:
json
json
But wait, there's more!
Switch back to your constellation's logic view and you should see something new:
| Wormhole Traffic |
|---|
 |
You'll see a dotted line between the web server provider and the actor. Note the direction of the flow animation - it's pointing toward the actor. This is real-time, automatically discovered traffic and it works for every element on your constellation canvas. Not only can you see configuration binding lines, but you'll also see live traffic patterns, even when there is no configuration (e.g. actor-to-actor communication).
Congratulations, Cosmonaut! You've made it through the first quickstart. You deployed a portable unit of business logic, bound it to a web server that you didn't have to write (or manage!), safely exposed an API to the outside world, and visualized real-time traffic flow.
In the next set of tutorials, we'll start exploring the developer experience and building our own actors.