577 karma · joined September 16, 2016
https://rivet.dev
From the companies I've talked to, most developers using this architecture are building quick scripts to do this in-house. Both Turso and Durable Objects SQLite already a surprising amount of usage that people don't talk about much publicly yet, so I suspect some of this tooling will start to be published in the next year.
So we built out a library that lets you run Durable Object-like backends on any cloud: https://github.com/rivet-gg/actor-core
This reminds me of HAFS – a FUSE-based filesystem based on FoundationDB [1]. It does a lot of the same things under the hood to work with FDB's requirements (i.e. slicing, etc). Looking forward to seeing your time travel implementation.
Regarding Gitlip – I've spent a lot of time in the gaming industry where many workflows rely on Perforce for collaboration/file locking instead of Git & Git LFS. It's a widely disdained tool because of its rigidity and complexity. Gitlip feels like a better approach to collaboration than Perforce, but applied to wider use cases. I'll have to give it a spin some time.
#1:
I would like to see some sort of guarantee by Turso that they plan on sticking to an MIT or Apache license and don't plan on re-licensing to AGPL or non-OSI-approved licenses.
Some context – the founders of Turso were early employees at ScyllaDB (phenomenal Cassandra rewrite, powering Apple, Discord, etc). I'm speculating on how much influence they had over the licensing of the database, but ScyllaDB was kept under an AGPL license during their ~8 year tenure there. However, ScyllaDB still rug pulled their license and switched to enterprise-only in 2024 [1].
I also run a venture-backed startup with an open-source product (Apache 2.0), so I completely understand the pressures that cause these decisions. A rug pull with something like Limbo seems very tangible as Turso competitors like Cloudflare D1 start making cloud-based SQLite a commodity.
Regardless, we're avoiding touching libSQL or Limbo because we've already been burned by Nomad (BSL relicense), Redis (SSPL relicense), and CockroachDB (custom enterprise relicense); all of which affect our ability to keep an Apache 2.0 license. (e.g. AGPL is a viral license that affects us to change our license if we use software like Minio.)
It's worth noting that Limbo does not have a CLA, which is a good indicator that they intend to keep Limbo licensed permissively.
#2:
One big focus of Limbo (and libSQL) is the WASM-based extensions for user-defined functions. Postgres also has a powerful UDF system because users need to be able to define custom logic without an extra network hop between client <-> database. However, SQLite runs on the same machine as the code that's querying it, so it doesn't make sense to make the database heavier to allow UDF when there's already a ~0-latency way of providing extensions.
Frankly, this feels a lot like Turso investing in features to match the constraints of Turso Cloud. Turso Cloud can't run arbitrary code, so they need to implement user logic in to the database itself.
I'd much rather a Supabase-like approach: provide vanilla Postgres-as-a-service and add Auth/PostgREST/Realtime/Functions/etc as a separate bundled service instead of rewriting Postgres itself. Similarly, Neon innovated on Postgres' storage architecture, but still provides full compatibility.
StarbaseDB [2] is taking the Supabase-like approach with SQLite, and I'm really excited for this. They're leveraging Cloudflare Durable Objects + SQLite to do things like provide a native auth & rate limiting & sharding & Stripe integration in to the database without modifications to SQLite itself.
#3:
I'm not looking forward to the fracturing of the SQLite ecosystem – similar to what happened with the enshittification of the MySQL ecosystem with MariaDB or NodeJS when io.js forked off. This is not a comment against Limbo itself, just something that's inevitably going to happen.
---
To be clear – despite these concerns, I'm very excited for Limbo for:
- The new governance model
- Heavier investment in to SQLite tooling
- Promote SQLite-in-the-cloud
- Promoting local-first database architectures
Props to the engineering team for their work on this (esp the DST) and the founders/management to green-light such an ambitious project.
[1] https://www.scylladb.com/2024/12/18/why-were-moving-to-a-sou...
In the past, we relied heavily on using EVAL[SHA] with 200+ loc Lua scripts in order to implement high throughput, atomic transactions for realtime systems. We also used the JSON & Redis Query Language (previous named "full-text search") to build a more maintainable & strongly consistent system than using raw key-values and manually building secondary indexes.
We’ve since migrated to a native FoundationDB and SQLite hybrid setup, but this approach would have been really helpful for early-stage prototyping with a higher performance ceiling (thanks to FDB sharding) than a single-node Redis with AOF.
Related: Redis Cluster is a world of pain when handling clustering keys and cross-node queries and orchestration. DragonflyDB is chasing after the market of companies considering sharding Redis because of performance issues by providing better single-node performance. There's probably an alternative approach that could work by using an architecture like this.
[1] https://redis.io/resources/building-large-databases-redis-en...
For comparison:
- Hand made diagram: https://github.com/rivet-gg/rivet/blob/d45bf556e903404ab2df0...
- GitDiagram (no instructions): https://gitdiagram.com/rivet-gg/rivet
D1’s read replicas [1] is still pretty new, how has this worked out for a read-heavy workload like FlagShip?
[1] https://blog.cloudflare.com/building-d1-a-global-database/#s...
We built something almost identical in Rust to let us use async/await for long-running & failure-prone workflows. This powers almost everything we do at Rivet. We have a technical writeup coming later, but here's a couple links of interest:
- Rough overview: https://github.com/rivet-gg/rivet/blob/58b073a7cae20adcf0fa3...
- Example async/await-heavy workflow: https://github.com/rivet-gg/rivet/blob/58b073a7cae20adcf0fa3...
- Example actor-like workflow: https://github.com/rivet-gg/rivet/blob/58b073a7cae20adcf0fa3...
Rivet Actors can start, stop, or crash at any time and still continue functioning, much like Durable Promises.
However, their scope differs: Rivet Actors are broader and designed for anything stateful & realtime, while Durable Promises seem focused on workflows with complex control flow.
Rivet Actors can (and likely will) support workflow-like applications in the future, since state management and rescheduling are already built-in.
For a deeper dive, Temporal has a writeup comparing actors and workflows: https://temporal.io/blog/workflows-as-actors-is-it-really-po...
> I guess this sort of comes by forcing everything to round-trip through FoundationDB for state?
If you’re using the KV API directly, this is correct.
Actors also have a `this._state` property, which is automatically written to FDB after each RPC call if modified [2]. This allows developers to rapidly prototype by writing vanilla JS code like `this._state.count += 1` without having to worry about writing state and its associated edge cases.
> What about calls to other actors? If I make a potentially state-changing RPC call to some other actor as part of handling an RPC, do those commit together, or is it possible for the other actor to commit without me?
Not at the moment. You’d need to use a 2-phase commit for that.
[1] https://rivet.gg/docs/internals/design-decisions#parallel-rp...
I dearly love Erlang & co., but its learning curve is way too steep for most developers today. Our goal is to bring the benefits of Erlang/Akka/Orleans/etc. to more developers by:
(a) supporting mainstream languages, and
(b) lowering the technical and conceptual barriers to entry.
> What kinds of web sites need this level of complexity?
The most common use cases are high contention & strong consistency workloads where using an OLTP database doesn't work well. A few examples:
- Collaborative docs
- Local-first & CRDT sync (e.g. Yjs)
- Stateful multiplayer games, often async multiplayer (e.g. chess)
- Agentic workflows with frequent memory updates
- Chat
- Scheduling software
- Rate limiting
Actors can also be used for stateless realtime workloads that benefit from edge computing, similar to what you would use existing serverless edge functions for.
The actor model is widely used in larger companies. The best-known example is how WhatsApp used Erlang to scale to 900 M users with 50 devs [2]. It's also widely used at Discord, LinkedIn, Microsoft, etc. Take a look at Erlang/Elixir, Akka, and Orleans for prior art.
> Does this have enough performance to solve the server cost problem of Improbable's metaverse back end?
Actors usually have a single responsibility (e.g. document or chat room) while Improbable focused on building expansive worlds without clear boundaries between entities. Our docs include tips on scoping the responsibility of actors [1].
The actor model encourages actor-actor communication, sort of similar how entities in the ECS model communicate in games.
> That's a remote object system too expensive to run 24/7.
Actors automatically go to sleep when unused. They provide the benefit of realtime workloads without the cost of keep idle compute sitting around.
[1] https://rivet.gg/docs/scaling#tips-for-architecting-actors-f...
[2] https://www.wired.com/2015/09/whatsapp-serves-900-million-us....
Godot runs using our container runtime on Rivet. The FDB API for containers is currently undocumented. I'd be happy to share early access on Discord – https://rivet.gg/discord
Games running on Rivet usually have a hybrid of actors that handle persistent storage (e.g. a matchmaker) and the game server itself.
- Rewrote Nomad from scratch with our own in-house workflow engine
- Launched Rivet Actors and isolate runtime
- Overhauled our OSS experience to make self-hosting easier
- Rewrote frontend from scratch with shadcn to be like the cool kids
- Replaced Nebula with mTLS
- Completely stripped out Redis for non-caching use cases
We've also opened up the platform to non-gaming use cases.
To this day, I still believe it's one of the best ways to learn to program:
- You're exposed to low-level primitives instead of complicated high-level frameworks (like Unity) that abstract the fun/educational code away.
- The Lua manual is arguably the best programming manual for students learning to program.
- Includes a built-in GLSL shader editor makes advanced graphics programming a small stepping stone.
- They automatically shipped in-depth examples with the app that are intentionally built for learning by reading the code.
- In-app docs encouraged discovering new APIs; I took it as a challenge to use all of the APIs they exposed and learned a lot in the process.
- No package managers, no complicated install steps, no security concerns, and a unified editor.
P.S. If you have an iPad and haven't played Two Lives Left's Crabitron [1] – it's easily the most creative game shipped for iPad.
[1] https://apps.apple.com/se/app/crabitron/id440462182?l=en
Cloudflare has a lower latency product called Argo Smart Routing [1]. When we tried Argo in 2020, we still saw 10+ ms increased latency across the board, which is unacceptable for competitive multiplayer games. That said, Discord voice still (or used to) uses Argo for voice, so there are certainly less latency-sensitive games where it would work well.
The other issue with sockets over Cloudflare (circa 2020 on business plan) is they get terminate liberally with the assumption you have a reconnection mechanism in place. I'd imagine this is acceptable for traditional WebSocket use cases, but not for games.
Services like OVH & Vultr also advertise "DDoS protection for games," but I've found these to be pretty useless in practice. We can only measure traffic that reaches our game servers, so I have no way of knowing if they're actually helping at all.
Your best bet is getting familiar with iptables and fine-tuning rules to match your game's traffic patterns. Thankfully, LLMs are pretty good at generating these rules for you nowadays if you're not already familiar with these tools. Make sure to set up something like node-exporter to be able to monitor attacks and understand where things go wrong. There have been a few other posts on HN in the past that go into more depth about game server DoS mitigation [2] [3].
I built something in the same vein for my startup (Apache 2.0 OSS, steal our code!) [4] that runs a series of load balancers in front of game servers in order to act like a mini-Cloudflare. In addition to the basics I already listed, we also have logic under the hood that (a) dynamically routes traffic to load balancers and (b) autoscales hardware based on traffic in order to absorb attacks. We're rolling out a dynamic bot attack & mitigation mechanism soon to handle more complex patterns.
[1] https://www.cloudflare.com/application-services/products/arg...
[2] https://news.ycombinator.com/item?id=35771466
We use a mix of Traefik and Envoy for complex + dynamic LB configurations. Doing anything related to custom middleware, dynamic configuration, and caching feels archaic on Traefik and requires a non-trivial amount of code on Envoy. I hope Dito becomes the next gold standard for load balancing.
One caveat — one of my biggest complaints with Traefik is the memory usage, which makes it difficult to run as an mTLS proxy between services. We use Envoy for these use cases instead. I’m curious to see how Dito compares on memory usage, despite also being written in Go.
This the demo we share: https://github.com/rivet-gg/examples/tree/main/javascript/we...
Really cool project, love to see things that touch web tech, VPLs, and creative programming. Could not find repo from the website on mobile, would love to see it in the footer or in the CTA.
Plot twist: people stop writing casual games in Unity and switch to Unreal to target low-end hardware.
Needless to say: as someone who spent my teens and early 20s working on multiplayer web games, I'm incredibly excited for this.
No one on our team had used rebasing extensively before this, but it's hard to go back. Similar to the article, the benefits we see are:
- Fast iteration with `gt m` (`git commit --amend`) and `gt s` (`git push --force`) - Using `gt restack` (`git rebase` on each parent commit) helps make merge conflicts more transparent in what happened - Commit histories are much more legible
I highly recommend giving it a go.
Related -- we also built a simple (but not production-grade) tunneling solution just for devving on our open-source project (multiplayer game server management).
We recently ran in to an issue where we need devs to be able to have a public IP with vanilla TCP+TLS sockets to hack on some parts of our software. I tried Ngrok TCP endpoints, but didn't feel comfortable requiring our maintainers to pay for SaaS just to be able to hack around with our software. Cloudflare Tunnels is awesome if you know what you're doing, but too complicated to set up.
It works by automating a Terraform plan to (a) set up a remote VM, (b) set up SSH keys, and (c) create a container that uses reverse SSH tunneling to expose a port on the host. We get the benefit of a dedicated IP + any port + no 3rd party vendors for $2.50/mo in your own cloud. All you need is a Linode access token, arguably faster and cheaper than any other reverse tunneling software.
Source: https://github.com/rivet-gg/rivet/tree/main/infra/dev-tunnel
Setup guide: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...
- The OP's acc was created today
- The support email for their site is a Tencent email (timmerse_support@tencent.com)
- They have an old NPM package [1] which lists colleenyu@tencent.com as a contact
- "colleenyu tencent" brings up a PM at Tencent on LinkedIn [2]
I have a lot of questions, now I really want to know the story behind this project.
[1] https://www.npmjs.com/package/timmerse
[2] https://www.linkedin.com/in/ucl-kejing-yu/?original_referer=...
That said, I've met & work with _a lot_ of developers who shipped Unity for web solely because (a) they already knew Unity, (b) they could easily hire for Unity, (c) their art pipeline only worked with Unity, or (d) they aim to ship to mobile later. Built-in physics + better rendering + networking are usually just a bonus.
BSL is not OSI-approved, but it’s a much more reasonable AWS-resistant license. It’s the same license CockroachDB uses, for example.
KeyDB (BSL, acquired by Snapchat) is also an option: https://keydb.dev/
BSL is a much better license, but it’s a gamble on how long KeyDB will be supported. I don’t want to mess around with such a core part of my architecture.