Stephen showed some of the experimentation he's been doing with Simon Brown's C4 model - Context, Containers, Components and Code.
Taking a simple drawing to a level where it can vary the scopes of who you want to speak - be able to address different stakeholders within your organization.
Allows you to dive into the application a little deeper. Basic first experiment where we can start to understand context.
For example: application needs certificates and people's differing relationships that need to be managed. The user interacts with the wasmcCloud app, then dives in to look at how that app comes together. User may want to interact with the client to understand how the client gets through and what information it needs.
Demo shows how we can dive in further to look at the Component Model itself. Allows us to see the major elements of the wasmCloud app and how the calls are happening. When you start to jump further into the code you start to have an extremely deep view of how the language looks.
You are not tied into these 4 perspectives - you can add as many as you like. One of the best ways to impart docs or info is through images - language agnostic and easy to understand if done well.
Demo also shows how the tool can export to HTML - perhaps, in the future, we can embed in documentation and host this type of HTML doc on a static web server.
Been keen to get started since Slack started discussing testing actors with Dagger.
Focused on end-to-end integration tests rather than unit tests right now.
Also working on a way to mock the lattice which he'll use for unit tests eventually.
Dagger allows you to take your CI/CD pipelines and run them identically, locally as you would in Github action or anywhere else.
This is pretty cool as one of the biggest pain points occurs when testing code at work, then trying to test later at home or in github - these are completely different test structures which causes confusion.
Demo shows wash new echo actor - build, sign, inspect, name and then call.
What's really cool is a call test on the actor which allows me to do some sanity checking. I.e. that it's functioning.
As a bonus, we tested starting and stopping inside Cosmonic using appropriate wash context. Not only do we test in a function, we also test whether it deploys and stops properly.
Unit tests are a little hard as we can't mock wasmCloud yet, so this is a different angle - testing end-to-end integration
Next up - start actor, start provider, link then curl through provider.
Little Blobby Tables is a new actor that we created in our example repo.
You can find the code here. You can follow along with the demo in the recording here.
Blobby provides a CRUD interface for interacting with a blobstore. When linked to a provider like blobstore-fs, blobby can act as a file server that exposes a basic HTTP endpoint, that can take a file and store it in anything that implements the blobstore contract.
Demo showed how easy it is to get started - even completely from scratch from wash up.
Linking with the Blobstore to create a contract and linking to HTTP server is a simple process. The blobstore-fs provider is a great way to get started as it uses the local filesystem as a blobstore
Demo shows how easy it is to pull the file back and forth or update and delete using the delete verb.
There's no unwrapping/panicking or any sort of things going on in the code so this a good example for people who want to build a full-featured application from the ground up.
More code than our normal examples - 254 lines but that's 254 lines of code total, to do a full file server with error handling and all the bells and whistles. Now, you can easily move across any compatible blob store - such as s3 or Google blob store - anything you create a capability provider for.