Hello! We posted a Show HN for Rivet last year for our container orchestration project (<a href="https://news.ycombinator.com/item?id=37188659">https://news.ycombinator.com/item?id=37188659</a>). In that time, a lot has changed that I think HN will find interesting.<p>Rivet is open-source actor infrastructure similar to Cloudflare's Durable Objects. Rivet itself already serves millions of MAU in production using our current container runtime – primarily for multiplayer games – and Rivet Actors are a new extension to support actor-like workloads. Rivet Actor's core primitives are RPC, state, and events.<p>Actors are powered by Rust, V8 isolates (supports Deno), and FoundationDB. An architecture diagram is available here for [1]. If you're not familiar with FoundationDB, you're overdue to watch Dave Rosenthal's talk [3]. (I firmly believe it's by far the best permissively licensed database; if only it had a well maintained SQL layer.)<p>Here's where Rivet's architecture gets fun – we don't rely on a traditional orchestrator like Kubernetes or Nomad for our runtime. Instead, our orchestrator is powered by an in-house actor-like workflow engine – similar to how FoundationDB is powered by their own actor library (Flow [4]) internally. It lets us reliably & efficiently build complex logic – like our orchestrator – that would normally be incredibly difficult to build correctly. For example, here's the logic that powers Rivet Actors themselves with complex mechanisms like retry upgrades, retry backoffs, and draining [2].<p>One of the reasons we built Rivet Actors is because we tried to replace most of our Redis-based realtime infrastructure with Durable Objects. The architecture allowed us to build realtime features much faster & efficiently, but the platform & APIs were needlessly rigid and difficult to use. Our goal is to build an actor-like platform that includes the bells and whistles required for developers to benefit from the actor model without the learning curve of tools like Erlang/OTP, Akka, or Orleans.<p>Rivet Actors provides a few key benefits in flexibility over Durable Objects:<p>- Open-source (Apache 2.0) – built to be self-hosted and deployed on-prem<p>- Provides observability out of the box, no Logpush required<p>- Rivet Actors support the Deno runtime, so NPM & JSR just works<p>- @rivet-gg/actor [5] framework provides RPC, state, and events out of the box for faster bootstrapping; you can modify and deploy it yourself<p>- Supports both V8 isolates & Docker-compatible containers so you can run any software you'd like, like Godot/Unity servers or video transcoding<p>- Also supports TCP & UDP (we run games!)<p>- Provides vanilla HTTP API for easy use with existing apps<p>- Full control over regions<p>There's plenty more that I don't have space to talk about. Give our docs a read if you'd like to learn more [6] or read about internal design decisions [7]. I'll be in the comments answering questions!<p>Cheers,
Nathan<p>[1] <a href="https://github.com/rivet-gg/rivet?tab=readme-ov-file#diagram">https://github.com/rivet-gg/rivet?tab=readme-ov-file#diagram</a><p>[2] <a href="https://github.com/rivet-gg/rivet/blob/a3db31f3b5c351061d665003a6a8dfbf3372690b/packages/services/ds/src/workflows/server/pegboard/mod.rs#L49">https://github.com/rivet-gg/rivet/blob/a3db31f3b5c351061d665...</a><p>[3] <a href="https://www.youtube.com/watch?v=9g84y_60VGM" rel="nofollow">https://www.youtube.com/watch?v=9g84y_60VGM</a><p>[4] <a href="https://apple.github.io/foundationdb/flow.html" rel="nofollow">https://apple.github.io/foundationdb/flow.html</a><p>[5] <a href="https://jsr.io/@rivet-gg/actor/doc" rel="nofollow">https://jsr.io/@rivet-gg/actor/doc</a><p>[6] <a href="https://rivet.gg/docs">https://rivet.gg/docs</a><p>[7] <a href="https://rivet.gg/docs/internals/design-decisions">https://rivet.gg/docs/internals/design-decisions</a>
If I wanted a Rivet integration with Godot Engine and/or Elixir, how would I do it for shared durable objects in a virtual reality environment?<p>I have code for Godot Engine Foundationdb access, but I'm cutting too many encapsulation layers.
For ages I've been hoping someone will clone Durable Objects and here you are! I'm going to check this out.<p>Are there any gotchas or differences from Durable Objects behaviour when using Rivet Actors? There seems to be quite a lot of subtlety in some of how they handle e.g. IO, so I assume you wouldn't be compatible with this directly?<p><a href="https://blog.cloudflare.com/durable-objects-easy-fast-correct-choose-three/" rel="nofollow">https://blog.cloudflare.com/durable-objects-easy-fast-correc...</a>
How is this different from the Durable Promises idea by ResonateHQ?
It seams to me a bitter easer to get started with as a small standalone project.
Would you mind comparing this solutions to that?
> Here's where Rivet's architecture gets fun – we don't rely on a traditional orchestrator like Kubernetes or Nomad for our runtime. Instead, our orchestrator is powered by an in-house actor-like workflow engine – similar to how FoundationDB is powered by their own actor library (Flow [4]) internally. It lets us reliably & efficiently build complex logic – like our orchestrator – that would normally be incredibly difficult to build correctly. For example, here's the logic that powers Rivet Actors themselves with complex mechanisms like retry upgrades, retry backoffs, and draining [2].<p>It is a bit unclear for me, do you use actors themself to develop Rivet Actors, or it is another actor-like workflow engine, not the final product?<p>(I would be super happy to read an article, which explains architecture, main blocks of the system, gives some an example)
Related discussion in 2023 <a href="https://news.ycombinator.com/item?id=37188659">https://news.ycombinator.com/item?id=37188659</a>
What kinds of web sites need this level of complexity? They must be doing something really hard and tightly coordinated, such as collaborative editing, right?<p>Does this have enough performance to solve the server cost problem of Improbable's metaverse back end? That's a remote object system too expensive to run 24/7.
Here’s my once a month comment that I should probably put on autopilot:<p>“at least half of show HN posts are just reimplementations of what already exits in Erlang/Elixir”.
Out of curiosity, what's the sort of consistency (in the sense of linearizable etc.,.) provided here? If an RPC is handled by some actor, is it guaranteed to have seen all previously accepted messages that completed up to that point?<p>If so, how does that work?<p>Edit: I guess this sort of comes by forcing everything to round trip through foundationdb for state? As long as the actor reads the state from foundationdb before handling the response, and writes to foundationdb before sending a reply, it should guarantee the same sort of consistency you'd get from foundationdb?<p>What about calls to other actors? If I make a potentially state changing RPC call to some other actor as a part of handling an RPC, do those commit together, or is it possible for the other actor to commit without me?