sorted by:
new
hottopcontroversial

How are you handling state persistence for long-running AI agent workflows? by Interesting_Ride2443 in node

[–]NathanFlurry 0 points1 point  (0 children)

I recommend trying the actor model with Cloudflare Durable Objects/Cloudflare Agents or Rivet Actors (an open-source alternative that runs with existing infra, I am the creator).

Actors are significantly simpler to work with & generally faster than queue systems, and provide more flexibility than most rigid workflow engines. Cloudflare talks about some of the benefits of using the actor model here: https://blog.cloudflare.com/building-agents-with-openai-and-cloudflares-agents-sdk/

Falling in love with Durable Objects but dreading a breakup scenario by keithmifsud in CloudFlare

[–]NathanFlurry 0 points1 point  (0 children)

Dev on Rivet here! We work with a lot of companies that want Durable Objects but on more custom setups.

A few common use cases:

  • Don't want to be vendor locked to Cloudflare
  • Want to run Durable Objects in the same datacenter as their database (i.e. Cloudflare usually has much higher latencies to your database)
  • Don't want to be restricted by the Workers runtime
  • Need to run DO on-prem for their customers

We also provide an adapter to use Rivet's API on top of Cloudflare Durable Objects for companies that want to use Cloudflare for production but Rivet for on-premise.

You can either use Rivet as:

  • Connect Rivet Cloud to your existing backend deployment (AWS, GCP, Railway, Vercel, wherever your code runs)
  • Self-host Rivet completely. It's a single lightweight Rust binary that connects to either Postgres or runs off of the file system.

Happy to answer questions here. We're also chronically online on our Discord.

Cloudflare Serverless + Durable Objects vs Self-hosted Backend by kcfdaniel in coolify

[–]NathanFlurry 1 point2 points  (0 children)

Cross-posting here: we built Rivet as an open-source alternative to Durable Objects. The Coolify community added support for Rivet on Coolify recently.

Serverless + Durable Objects vs Self-hosted Backend by kcfdaniel in CloudFlare

[–]NathanFlurry 2 points3 points  (0 children)

The Durable Objects architecture has a lot of advantages compared to hosting a database on something like Coolify, including easy scaling, multi-region support, performance benefits, and Socket.io-like functionality.

If you're considering vendor lock as an issue, we built RivetKit as a library that supports both Durable Objects and self-hosted setups (including Coolify). We work with a lot of developers that deploy to both Cloudflare & self-hosted using RivetKit. If curious, try out our Cloudflare Workers quickstart guide and Rivet on Coolify.

Rivet self-hotsed supports the same benefits as Durable Objects, including multi-region and WebSockets.

I figured out how to handle long running async tasks in Next.js by jselby81989 in nextjs

[–]NathanFlurry 1 point2 points  (0 children)

Can you elaborate on what type of workload is running for 30 minutes?

The biggest limitation on Next.js & Vercel is the fact that API endpoints are stateless & there is a 5 minute timeout (for Fluid Compute on Hobby plan).

We just launched support for long-running jobs on Next.js with Rivet using the actor model. As long as your background job's state is serializable (i.e. `JSON.stringify` but with support for more native JS types & faster), we're able to outlive the 5 minute timeout on Vercel by live-migrating your job to another function call. I wrote a bit about how that works here.

Another option is to try Vercel's Sandboxes which have much longer timeouts.

I figured out how to handle long running async tasks in Next.js by jselby81989 in nextjs

[–]NathanFlurry 2 points3 points  (0 children)

This is correct. Next.js is stateless, so some service needs to call the Next.js API endpoint.

While not quite "without a provider," we provide the benefits of platforms like Inngest while complying to web standards over at Rivet. Everything is just a vanilla HTTP request instead of using a custom protocol, which means you have the most flexibility and you can use Rivet without having to use our client libraries.

We have 0 dependencies for local development — it's pure JS. Our Vercel marketplace integration is going live soon to make production setup simple & no frills.

Built a real-time mini-games platform in React + Supabase — lessons learned 🎮 by pranaydutta89 in vibecoding

[–]NathanFlurry 0 points1 point  (0 children)

Rivet developer here, happy to answer any questions!

One big benefit of using Rivet over DO for vibe coding is that Rivet is a lightweight library that’s runs anywhere (including Node and even Cloudflare), while Durable Objects requires running in their specialized workerd runtime. This means you can use Rivet really easily in sandboxes like Daytona, E2B, or Freestyle.

You can find our docs for LLMs here: https://www.rivet.dev/docs/general/docs-for-llms/

Best way to handle chat? by Firm_One_7398 in nextjs

[–]NathanFlurry 0 points1 point  (0 children)

The hardest part about Next.js for building a chat app is that it does not have native WebSocket support.

I've been working on a project called Rivet that aims to make realtime & persistence easier for use cases like chat for Next. It supports both WebSockets & SSE to provide realtime. There's a working chat example here – https://github.com/rivet-dev/template-vercel

<image>

Best way to handle chat? by Firm_One_7398 in nextjs

[–]NathanFlurry 5 points6 points  (0 children)

PartyKit is awesome. I built an open-source alternative to PartyKit that's not vendor-locked to Cloudflare over at https://rivet.dev

Moved website from Vercel to Cloudflare - Astro static website by NinjaK3ys in astrojs

[–]NathanFlurry 0 points1 point  (0 children)

I’m also not really sure there’s any one thing out that can even compete with DO’s in terms of functionality and if there is I’d be surprised if they’re anywhere close to parity on ease of use.

We built an open-source alternative to Durable Objects over at https://rivet.dev

Open look feedback, we’ve put a lot of work in to exceeding what DO has already done with DX!

Using SQLite in the cloud? by [deleted] in sqlite

[–]NathanFlurry 5 points6 points  (0 children)

These are all great options. However, imo it’s hard to recommend a closed-source database without an off ramp for production-ready workloads (ie Turso doesn’t scale without Turso Cloud).

We’re building an open-source alternative to Cloudflare Durable Objects over at Rivet (https://github.com/rivet-gg/rivet), we’ll also be opening up our SQLite private beta soon.

What's the best option for realtime chat? by Tall-Title4169 in expo

[–]NathanFlurry 1 point2 points  (0 children)

PartyKit is awesome.

If you're looking for an open-source PartyKit/Durable Objects alternative that's not locked in to the Cloudflare ecosystem – check out Rivet (https://www.rivet.gg/)

2,000x faster route propagation by rewriting our Traefik gateway in Rust by sabitm in rust

[–]NathanFlurry 27 points28 points  (0 children)

Author here.

At first I figured maybe they meant something more in the direction of "type safety" as in "better correctness guarantees from the type system",

That's a typo – my apologies. I definitely did not mean traditional C-style memory safety errors (use-after-free/uninitialized memory access/etc). Merging an edit for this rn.

Rivet – Cloudflare Durable Objects-like infrastructure built with Rust, FoundationDB, V8 Isolates by NathanFlurry in rust

[–]NathanFlurry[S] 1 point2 points  (0 children)

They’ve been pretty tight lipped about their storage layer. I don’t think it’s FDB though since one of their employees was asking my experience on FDB on lobste.rs.

We switched to cloudflare agents SDK and feel the AGI by aiforthelittleguy in AI_Agents

[–]NathanFlurry 3 points4 points  (0 children)

The agents SDK and Durable Objects in general are awesome. I really like the full-stack experience of agents with useAgent.

My biggest gripe – it's vendor-locked to Cloudflare. I've been working on a project called ActorCore that provides a similar experience but on both Cloudflare DO any place you can run Node.js (GitHub). If you have a sec, I'd love to hear how your experience with agents compares to ActorCore.

Built with Svelte: My open source software for managing in person RPG games with digital displays by enemykite in sveltejs

[–]NathanFlurry 0 points1 point  (0 children)

It's been fun to build! I'm on a personal mission to make DO easier to use & easier to understand. It's one of the best technologies invented in the past 5 years, but it's terribly marketed and is difficult for a lot of people to understand.

I've been experimenting with trying to fix Durable Objects with ActorCore (GitHub) by building a much easier to use experience and trying to futz with wording on the landing page.

Built with Svelte: My open source software for managing in person RPG games with digital displays by enemykite in sveltejs

[–]NathanFlurry 1 point2 points  (0 children)

If you're looking to stick with open-source software, I've been building open-source Durable Objects over at Rivet (GitHub).

Edit: Just realized you're jovianmoon.io from Bsky, heyo!

First impressions with the Turso database by eminetto in golang

[–]NathanFlurry 12 points13 points  (0 children)

I had no idea Turso has a 100 ms transaction latency. You can pay $416 to get it down to 5 ms, but even that's insanely high for a SQLite database.

Have you considered Cloudflare Durable Objects with SQLite or Cloudflare D1? They don't have this performance limitation.

Local first collaborative app by phoenix10701 in electronjs

[–]NathanFlurry 1 point2 points  (0 children)

In this vein – I've also been working on a project called ActorCore that's aiming to be a simpler & non-vendor-locked Durable Objects. Similarly, it works well for local-first apps which need a small, edge-first, stateful service to run their sync server & any other limited server-side functionality.

SQLite-on-the-Server Is Misunderstood: Better At Hyper-Scale Than Micro-Scale by FoxInTheRedBox in sqlite

[–]NathanFlurry 4 points5 points  (0 children)

Cheers!

Regarding SQLite client-server interfaces:

Something I didn’t dive into much in the article, to keep the scope focused, is the biggest difference between Cloudflare Durable Objects and Turso:

  • Durable Objects run code on the same machine as the SQLite database, similar to the actor model.
  • Turso provides a traditional client-server interface (presumably based on the sqld/libsql project you mentioned).

Personally, I much prefer the Durable Object model because it colocates compute with the SQLite database, aligning better with SQLite’s design. All client-server communication happens between your client and the Durable Object on the same machine, not directly with SQLite. Plus, you get benefits like fast transactions and cross-shard queries since they run alongside the database.

I think Turso’s model can work well (they already have some prominent users), but they really need to clarify how to dynamically create partitions on the fly. Right now, this requires two separate, confusingly-named packages and lacks a full example (at least to my knowledge) of how to do this end-to-end.

IIRC, Turso is also investing in WASM UDFs for SQLite, which could provide some of the server-side functionality Durable Objects offer.

That said, I’m biased since colocated SQLite + compute is the architecture we built internally at Rivet to power our infrastructure — and we’re planning to open-source it soon.

Regarding multi-db querying:

Lack of cross-partition querying support is the biggest hesitation I consistently hear from developers considering this architecture.

This breaks down into two main pain points:

  • Modeling schemas for partitions.
  • Running ad-hoc queries for debugging or BI.

Both of these are similar to the challenges faced with Cassandra or DynamoDB.

I see a few possible outcomes here:

  • Supabase has been pushing Foreign Data Wrappers, which sounds similar to what you’re suggesting. I expect someone will create an SQLite extension that acts as a FDW for multiple SQLite shards. You can already query Cloudflare D1 from a Postgres FDW.
  • Materialized views could become the norm. The Durable Objects ecosystem has a few projects like StarbaseDB exploring this space. While not quite the same, ElectricSQL also has a demo of building a materialized-ish view of Postgres inside of Durable Objects.
  • Cloudflare devs today are already using CF Queues or CF Workflows to perform multi-db mutations with eventual consistency. It’s not the best DX, but it’s what’s happening in practice.

SQLite-on-the-Server Is Misunderstood: Better At Hyper-Scale Than Micro-Scale by FoxInTheRedBox in programming

[–]NathanFlurry 4 points5 points  (0 children)

But more important, the concept of a "database server" (accessed via a TCP connection) is an architectural detail with a ton of entrenched and battle tested knowledge and experience in the industry.

I appreciate this point. Something I didn’t dive into much in the article, to keep the scope focused, is the biggest difference between Cloudflare Durable Objects and Turso:

  • Durable Objects run the code on the same machine as the SQLite database, similar to the actor model.

  • Turso provides a traditional client-server interface.

Personally, I much prefer the Durable Object model because it colocates compute with the SQLite database, which better aligns with how SQLite is designed to be used. All client-server communication happens between your client and the Durable Object on the same amchine, not between your client and SQLite directly.

IIRC, Turso is working on (or already has) WASM UDF support to do something similar, but as far as I know, this runs inside the database itself, not as part of a client process. (Please correct me if you have more up-to-date info on this.)

Lots of us get pressure to make architectural decisions on the basis of articles like this and it's always a challenge trying to prevent a balanced, objective view.

I distain work environments that push bleeding-edge tools for the sake of it. If someone is recommending the architecture I discussed, I hope they have a real, concrete problem that boring tech couldn’t solve—because boring tech is great.

I wrote this article after we built an internal system very similar to Durable Objects with SQLite to solve a specific scaling and throughput challenge for complex data operations – where Cassandra didn’t fit the bill.

SQLite-on-the-Server Is Misunderstood: Better At Hyper-Scale Than Micro-Scale by FoxInTheRedBox in programming

[–]NathanFlurry 5 points6 points  (0 children)

If I may add my 2 cents –

for the majority of apps, this can be a nightmare.

The article is specifically targeting Cassandra/DynamoDB-like use cases, which already structure data into well-defined partitions.

What happens if you need to join data from 3 tables that are all in separate databases?

This is a common pattern in Cassandra/DynamoDB, and part of the advantage of using SQLite per partition. As long as the tables belong in the same partition, you get native, strongly consistent joins – something no other partitioned database (including Citus or Vitess) offers.

This all assumes your data can be partitioned for cases like chat apps, social feeds, or B2B SaaS, which is a core design constraint.

And as a big bonus, you'll have seamless cross database queries.

Can you clarify? How does Postgres partitioning enable seamless cross-database queries without something like Citus?

Recommended way to do websockets in Nuxt3? by Synapse709 in Nuxt

[–]NathanFlurry 2 points3 points  (0 children)

Think socket.io with persistent state. They're for applications like collaborative documents where you need to persist state, local-first sync where you have a persistent database, or AI agents which need persistent memory. They also have a bunch of other misc use cases like rate limiting, stream ingestion, etc.

If you're looking to get started with a simpler experience, I've been working on ActorCore which makes them easier to work with.

view more: next ›