manter

I've wanted to play around with Cloudflare's Durable Objects more seriously for a while, so this was mostly an excuse to do that. I'll be writing a post about my experience at some point. (Short version - really powerful tech, missing any kind of ops tooling)

Ordah is a dumb side project, but it scratches an itch for me - I had a list of ~100 domain names/product names to choose from for _another_ side project and was going a bit nuts.

... I might have a problem with procrastination.

Swift is tightly bound to the Apple ecosystem (even though it can run outside of it), both in tooling, the ecosystem, and developer's perceptions.

These things all feed into each other.

If you're in the (vast, vast) majority of Swift developers then you're writing apps for iOS, MacOS, etc. This means outside of that context Swift goes from being a relatively popular language with a strong ecosystem to an incredibly niche one.

One angle where this could gain traction is devs writing a server side backend for their Apple app - but this use case is sliced apart in practice.

- Teams that start off wanting to use the same language for the app and the backend are likely to pick React Native or similar.

- The larger teams that want/need to write their app natively likely have devs that write the apps and devs that write the server code - so the desire the for language to be the same is lower.

- The pool of developers you could hire that have backend experience and swift experience is much much smaller than either of those two factors alone.

On a pure 'is this language good enough for the problem' level - sure, swift could do the job.

But that's also true of almost every other language.

D1 is built using Durable Objects - so in theory DO could be faster.

AFAIK when you call D1 it's Worker > D1 (Durable Object) > local storage.

So using DO directly would just be DO > local storage.

I believe the connection between worker and D1 is the painful part, requiring multiple round trips.

I think D1 actually requires multiple round trips, so the higher figures start to make some kind of sense.

I read a blog post about this but can't find it now. I did find this [release note](https://developers.cloudflare.com/d1/platform/release-notes/...) though.

They describe removing _at least_ two round trips back to the DC hosting the D1 instance.

I'm a big fan of Cloudflare's offerings in general, including D1 (despite the fact it admittedly has flaws).

That being said, the pipe dream statement is accurate IMO. I do think they'll get there, but like you said - a lot of the ideas put forward around a DB per customer just aren't present at all in the DX.

If I were to hazard a guess, Durable Objects will slowly gain many of the features and DX of regular workers. Once they reach parity workers will begin end-of-life (though I'd guess the workers name will be kept, since 'Durable Objects' is terribly named IMO).

This is kind of what happened (is happening) with pages right now. Workers gained pretty much all of their features and are now the recommended way to deliver static sites too.

For me, this can't come quickly enough. The DX of workers with the capability of DO is game changing and one of the most unique cloud offerings around.

It'll bring a few new challenges - getting visibility across that many databases for example, but it completely removes a pretty big chunk of scaling pain.