IPs as identifiers aren’t great: in a world of both CGNAT (more shared IPs) and a ton of sketchy residential proxies, they’ve become poor proxies for identity of a “thing”.
There's ~four of us trying to reproduce this right now, using Astro and Remix, and cannot at all.
An important note: React-based frameworks tend to use camelCase attributes vs. hyphen-case (which is the output) in components: including the icon library being used here. Something during the build process is not converting them to hyphen-case.
* This is all deployed via the Pages Build system; no local builds at all.
* Someone else on the team has an Astro example stood up with the specific unplugin-icons library: https://astro-svg.pages.dev/ - cannot reproduce the invalid SVG attributes.
We're going to continue investigating but don't see this as widespread and don't yet have any other reports. That there is a _difference_ between the direct deploy vs. using Pages Builds is a problem, though. We've also asked the Astro folks to understand if there's something up here as well.
> The fact that D1 still doesn't support replication is an indication to me that it has been deprioritized, likely with other newer and less used products, while the infrastructure updates are dealt with.
D1 is definitely not deprioritized. We're heads down on replication, and it's important for us to get it right. Takes time!
> What a nightmare! Now your application code spills into your database and our initial goal of simplifying application development is nothing but a long-forgotten dream. All of that for what? To save a few milliseconds to display a web page.
I think "a few milliseconds" vastly understates this: if you want to run your application closer to users, even just across the US, each query is (at least) 70ms just to get over the network and back again.
"Application code spills into your database" was a bad thing when you wrote one language (say, Java, or PHP) and another language (PSQL/TSQL/etc) for your "stored procedures", but that's not what most modern databases are advocating for.
Instead, and not unlike something like React Server Components (RSC), you can choose whether to run code close to the user or closer to the DB (for transactions) in the same language as your application, because it's still part of your application code. This is the model that Durable Objects[1], our coordinated storage service, uses.
Disclaimer: I work on D1 & Durable Objects at Cloudflare, so I'm likely to be called biased here, but it's not like we haven't a) thought about this deeply and b) actually use D1 and Durable Objects to build distributed systems at Cloudflare.
> due to the writers literally having disdain for the actual source material and we're just using the how's setting as a backdrop to push their own entirely disconnected stories.
Is this concretely true, or just disinformation to put blame on writers vs. producers?
I’m not saying it’s not plausible either way, but this is a common cop out.
(I lead DO & databases product here at Cloudflare)
Thanks for the kind words! Durable Objects also underpins a tremendous amount of what we build internally as well — it’s fundamentally a very powerful “coordination API”.
FYI: We’re continuing to work on observability & throughput improvements so folks can get more of each DO, on top of the horizontal sharding (“a DO per X”) approach we recommend.
> do you think you will have any API driven access to the data held in these services? IE, I don't per se want to have to use a worker to arbitrage between the Cloudflare platform and HTTP access to the data within Cloudflare systems.
For D1, yes — on the roadmap is a native HTTP API. KV has a HTTP API as well, so you can write directly.
Correct. DuckDB is really interesting technology, but it's not a direct successor to SQLite for transactional workloads. It's also very new: there's a LOT of new code in DuckDB on top of the (heavily fuzzed) SQLite parts.
(I use it personally, but it's not the same thing as what we're building with D1)
> High schools in Australia have electronics classes.
They do? None of those I know (high school 2000 - 2005) in Perth did electronics. We had the usual woodworking/metalworking/art/photography electives, plus drama & music, but no electronics. We also had extremely sub-par computing classes, with no option for a T.E.E level (i.e. contributes to your University entrance score) computing class whatsoever.