Comments URL: https://news.ycombinator.com/item?id=47602832

Points: 703

# Comments: 504

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.

* I've pasted a decently complex SVG exported from Figma into a Remix component verbatim (hyphen-attributes) and it renders fine: https://9b14a265.test-broken-svgs-remix.pages.dev/ (scroll down)

* I've rewritten those attributes to camelCase: and again, renders fine - https://1af766a8.test-broken-svgs-remix.pages.dev/

* 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.

(If not clear: I work at Cloudflare)

(I lead our storage & DB product teams here at CF)

D1 is definitely not deprioritized. We're heads down on replication, and it's important for us to get it right. Takes time!

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.

[1]: https://blog.cloudflare.com/durable-objects-easy-fast-correc...

The dashboard team had a bug that caused too-large cookies to be returned to some users.

They’ve rolled out a fix but you can also clear cookies to remedy.

(We’ll share more when we can)

This is not the way we wanted anyone to start their week.

(I am the PM lead for Cloudflare Workers: Databases & Storage)

(I am the PM lead for Workers databases & storage)

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.

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.

For D1, yes — on the roadmap is a native HTTP API. KV has a HTTP API as well, so you can write directly.

(I use it personally, but it's not the same thing as what we're building with D1)

We support MQTT over WS (or JSON over WS, or just HTTP) in Cloudflare Pub/Sub, FWIW - https://developers.cloudflare.com/pub-sub/learning/websocket...

I also agree with the comments re: MQTT being well suited to a lot of these "broadcast" use-case, but that the IoT roots seem to hold it back. MQTT 5.0 is just a great protocol — clear spec, explicit about errors, flexible payloads — that make it well suited to these broadcast/fan-in/real-time workloads. The traditional cloud providers do MQTT (3.1.1) in their respective IoT platforms but never grew it beyond that.

You should validate that the request is signed correctly, and reject it if not. An IP ACL can be a useful "remove some of the noise" tool, but no more than that.

For example, Discord's webhook implementation has you verify the incoming request against an app-specific (your app; not all apps) public key: https://discord.com/developers/docs/interactions/receiving-a... — this is really the right approach to this.