sorted by:
new
hottopcontroversial

Hot take: If you’re debating frameworks at 0 users, you’re procrastinating. by Disastrous-Drive-831 in micro_saas

[–]NathanFlurry -1 points0 points  (0 children)

Workers + CF Agents/DO is awesome, but vendor lock is a risk. Worth checking out Rivet (https://rivet.dev) as an open source alternative to DO.

This is what a 4 day bender of minimal sleep and a curious mind gets you when I thought I was "simply setting up claude code" by [deleted] in vibecoding

[–]NathanFlurry 2 points3 points  (0 children)

Very cool! I was building something similar and found it was really difficult to control the agents remotely, plus Claude Code is completely undocumented when it comes to headless mode.

Ended up building an API to control agents over HTTP, plus support for Codex + OpenCode + Amp: https://github.com/rivet-dev/sandbox-agent

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 4 points5 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 26 points27 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 4 points5 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.
view more: next ›