TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Show HN: Rivet Actors – Durable Objects built with Rust, FoundationDB, Isolates

133 点作者 NathanFlurry5 个月前
Hello! We posted a Show HN for Rivet last year for our container orchestration project (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37188659">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;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&#x27;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&#x27;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&#x27;re not familiar with FoundationDB, you&#x27;re overdue to watch Dave Rosenthal&#x27;s talk [3]. (I firmly believe it&#x27;s by far the best permissively licensed database; if only it had a well maintained SQL layer.)<p>Here&#x27;s where Rivet&#x27;s architecture gets fun – we don&#x27;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 &amp; efficiently build complex logic – like our orchestrator – that would normally be incredibly difficult to build correctly. For example, here&#x27;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 &amp; efficiently, but the platform &amp; 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&#x2F;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 &amp; JSR just works<p>- @rivet-gg&#x2F;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 &amp; Docker-compatible containers so you can run any software you&#x27;d like, like Godot&#x2F;Unity servers or video transcoding<p>- Also supports TCP &amp; UDP (we run games!)<p>- Provides vanilla HTTP API for easy use with existing apps<p>- Full control over regions<p>There&#x27;s plenty more that I don&#x27;t have space to talk about. Give our docs a read if you&#x27;d like to learn more [6] or read about internal design decisions [7]. I&#x27;ll be in the comments answering questions!<p>Cheers, Nathan<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;rivet-gg&#x2F;rivet?tab=readme-ov-file#diagram">https:&#x2F;&#x2F;github.com&#x2F;rivet-gg&#x2F;rivet?tab=readme-ov-file#diagram</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;rivet-gg&#x2F;rivet&#x2F;blob&#x2F;a3db31f3b5c351061d665003a6a8dfbf3372690b&#x2F;packages&#x2F;services&#x2F;ds&#x2F;src&#x2F;workflows&#x2F;server&#x2F;pegboard&#x2F;mod.rs#L49">https:&#x2F;&#x2F;github.com&#x2F;rivet-gg&#x2F;rivet&#x2F;blob&#x2F;a3db31f3b5c351061d665...</a><p>[3] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=9g84y_60VGM" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=9g84y_60VGM</a><p>[4] <a href="https:&#x2F;&#x2F;apple.github.io&#x2F;foundationdb&#x2F;flow.html" rel="nofollow">https:&#x2F;&#x2F;apple.github.io&#x2F;foundationdb&#x2F;flow.html</a><p>[5] <a href="https:&#x2F;&#x2F;jsr.io&#x2F;@rivet-gg&#x2F;actor&#x2F;doc" rel="nofollow">https:&#x2F;&#x2F;jsr.io&#x2F;@rivet-gg&#x2F;actor&#x2F;doc</a><p>[6] <a href="https:&#x2F;&#x2F;rivet.gg&#x2F;docs">https:&#x2F;&#x2F;rivet.gg&#x2F;docs</a><p>[7] <a href="https:&#x2F;&#x2F;rivet.gg&#x2F;docs&#x2F;internals&#x2F;design-decisions">https:&#x2F;&#x2F;rivet.gg&#x2F;docs&#x2F;internals&#x2F;design-decisions</a>

10 条评论

iFire5 个月前
If I wanted a Rivet integration with Godot Engine and&#x2F;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&#x27;m cutting too many encapsulation layers.
评论 #42479990 未加载
crabmusket5 个月前
For ages I&#x27;ve been hoping someone will clone Durable Objects and here you are! I&#x27;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&#x27;t be compatible with this directly?<p><a href="https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;durable-objects-easy-fast-correct-choose-three&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;durable-objects-easy-fast-correc...</a>
FjordWarden5 个月前
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?
评论 #42483889 未加载
Hixon105 个月前
&gt; Here&#x27;s where Rivet&#x27;s architecture gets fun – we don&#x27;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 &amp; efficiently build complex logic – like our orchestrator – that would normally be incredibly difficult to build correctly. For example, here&#x27;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)
pvg5 个月前
Related discussion in 2023 <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37188659">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37188659</a>
评论 #42472780 未加载
评论 #42482238 未加载
Animats5 个月前
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&#x27;s metaverse back end? That&#x27;s a remote object system too expensive to run 24&#x2F;7.
评论 #42483483 未加载
评论 #42483009 未加载
cpursley5 个月前
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&#x2F;Elixir”.
评论 #42483005 未加载
评论 #42483604 未加载
评论 #42485263 未加载
foota5 个月前
Out of curiosity, what&#x27;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&#x27;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?
评论 #42483667 未加载
wdb5 个月前
Looks interesting. I am wondering if I could get this to run with F5 XC
cjbb245 个月前
Thanks for sharing! This is awesome