Engineering @ Cosmonic

WIT, or Wasm Interface Types, allows WebAssembly modules to communicate with each other using complex data types. WIT is a language agnostic interface definition language (IDL) that enables composing WebAssembly components, regardless of source language, using language-specific bindings. If you're using a WIT-generated set of language bindings it will feel just like using a regular language SDK. If you're writing your own WIT, then this guide is for you!

Making sure that the team has a holistic view of the event flows throughout an application while still being able to synchronize code, schemas, and documentation is probably harder than actually writing the code.

New to the Cosmonic PaaS, we’re introducing an easy-to-use UI for managing declarative Wasm applications. Just like the platform’s opinionated views for Logic and Infrastructure, the new Application View provides a user interface for interacting with Wadm applications defined using the Open Application Model (OAM). This view includes an in-UI YAML editor and YAML validation.

Time is one of those things we all take for granted. Time marches on and does a dozen other things described by pithy sayings on T-shirts and motivational posters. When it comes to software, however, time is often our worst enemy. In this blog post, I talk about some patterns for dealing with the passage of time in event sourced applications.

The Cosmonic wormhole exposes an HTTPS endpoint for your application that's accessible from outside of your constellation. Any actor with the HTTP Server capability can use a wormhole through Cosmonic's implementation of the HTTP Server provider. When you first create a wormhole, a randomly generated DNS name like fuzzy-lake-1234.cosmonic.app. These random DNS names are auto-generated; a couple of familiar words and numbers, designed to be unique but user-friendly, no long strings of random characters.

Recently I had the opportunity to pick the brain of someone who has more experience and exposure to large scale, event-sourced systems than I do. We talked about event sourcing, specifically command processing, the subject of this blog post. It was an enlightening conversation that reminded me that insight is information tempered with experience. No amount of book reading is a substitute for learning from watching things go horribly wrong in production 😃.

One of the most formidable barriers in adopting and building event-sourced systems is learning to live with, and even embrace, the restrictions on component behavior. As it turns out, the same restrictions that make WebAssembly so powerful line up perfectly with event sourcing requirements.

In our last post we built an deployed a service with Rust and deployed it to Cosmonic's free infrastructure. In this post we'll build a React frontend to interact with the service.

One of the many things that Cosmonic makes incredibly simple is building and deploying services. In this post, we'll show how easy it is to build a service from scratch, and how a service can shift from monolith to globally distributed function at runtime without rebuilding.

In our last post, we looked at some of the challenges inherent in running a highly distributed, microservices-centric infrastructure and how to overcome issues of networking and security in this novel environment.

In particular, we looked at some of the limitations Kubernetes has, especially at the edge, and why this was a key reason for selecting HashiCorp Nomad as our container orchestrator for WebAssembly and wasmCloud.