In similar vein, I’d always thought Redka (https://github.com/nalgeon/redka) was a neat idea since it gives you access to a subset of the Redis API backed by either SQLite or Postgres
The timing of this release couldn't have been more fortuitous for me, I was just recently getting myself reacquainted with the options available for background processing in the Go landscape, and I was specifically looking for options that could be integrated as a library and were built on top of a RDBMS (specifically SQLite + Postgres for different use cases) as opposed to something like a redis/valkey.
Edit: I'm also curious if anyone is aware of companies or open source projects that are building with River?
Kudos for making this freely available, I was initially delighted to find out that there was a StepSecurity maintained alternative for the dorny/paths-filter action[1] as that seemed like a reasonable alternative to migrate to, but ended up being disappointed once I realized that it requires a subscription to use[2]
While edge functions and durable objects are both excellent examples of technologies that could be built using wasmCloud, they are (assuming we’re talking about either a CDN provider like Cloudflare, Fastly, Akamai or Cloud providers like AWS, Azure, GCP) not readily available in many environments.
An example brooksmtownsend linked to elsewhere in the thread is an industrial use case where one of the wasmCloud adopters is shipping a device running wasmCloud (and thus their Wasm components) locally within an industrial site: https://wasmcloud.com/blog/2024-10-22-webassembly-adoption-t...
So from a deployment perspective, not being tied to the public cloud/internet availability in general is a huge benefit.
But beyond deployment, due to the way wasmCloud is designed with the concept of capability providers and components, you are able to write providers that can integrate with any other existing protocols, services, software or hardware to make them available for your WebAssembly components to talk to.
In essence, you use WIT (think Protocol Buffers, but for WebAssembly) to describe the interface you would like your components to be able to call, and then you fulfill the interface from the providers and code generate the “guest” (or client-side) of the calling code for your WebAssembly components.
This means that you are not locked-in to the services and API's of your edge function provider and your function is portable to any cloud or edge.
One of the principles we do our best to follow as we build wasmCloud is the idea of "compatible with, but not dependent upon", and to that end we do in fact integrate very nicely with Kubernetes.
This will provide you an equivalent experience to what you might expect from Kwasm, with the major difference being that you will not need to change the underlying Kubelet in any way while still getting the benefit of being able to deploy WebAssembly components natively on Kubernetes.
I've been keeping an eye on flawless since stumbling across your blog posts from last year, it's great to see more durable execution options entering the market.
Given that you're compiling functions down to WebAssembly, I was curious about which runtime did you end up going with for building out the platform?
I'm also curious about whether you had plans (or any that you would be willing to share anyway) around expanding the languages supported by Flawless beyond Rust any time soon?