A client library shared between a website and a React Native app usually fails on the boring parts of the Web platform, not on fetch. Reading React Native 0.87.1 and Expo 57 sources shows three layers of runtime, a URL class that returns ‘/b/c/d/../x’ where the web returns ‘/b/x’, and a fetch with no response stream unless Expo replaces it. A small client that checks what it needs, tested against four simulated runtimes.
A Durable Object has one alarm, runs it at least once, and retries a failing handler with backoff up to six times. After that nothing wakes the object again. A walkthrough of a lease-expiry ledger that survives all three: a table as the source of truth, a constructor that re-arms the alarm, and an effect that tolerates being run twice. Run on local workerd, with the documented limits quoted from Cloudflare.
Cloudflare’s docs say hibernation keeps WebSocket connections open and discards in-memory state. This post runs a small Durable Object under local workerd and watches exactly what that means: the socket stays OPEN, the constructor runs again on the next message, class fields reset, attachments survive only if you serialize them, and a pending timer or the standard WebSocket API quietly turns hibernation off. Production behaviour and billing are not tested.
A request deadline fired on a connection that carries many requests at once. Do you close the connection, or only the request? In a small Node lab, closing the HTTP/2 session failed two innocent requests, while cancelling only the stream let them finish on the same TCP connection. The same lab shows the one case where cancelling is not enough: a lost packet stalls every stream on a TCP connection, and a connection-level PING is the right way to tell.
WebSocket send() never waits, and bufferedAmount only sees the part of the path that is in your own process. In a small lab, a sender that politely waited for bufferedAmount to drain still let a slow consumer queue nearly all 400 messages in its own memory, while a credit window of 8 kept the backlog at 8. This post goes through four common beliefs about send(), bufferedAmount, message size and backpressure, tests each one, and ends with a table for choosing between them.
Refresh token rotation turns a reused token into a theft alarm. A client that fires three requests with an expired access token and refreshes once per 401 presents the same refresh token three times, and trips that alarm on itself. This post breaks a naive client on purpose, fixes it with single-flight refresh and a stale check, and compares the alternatives: a server grace window, request gating, proactive refresh and sender-constrained tokens.
When every WebSocket message costs money and every frame has a hard cap, you need batching with independent flush triggers, a single-frame threshold below the cap, bounded chunking, and capability flags that survive mixed-version rollouts. The sharp edges are ordering on shutdown and a zero value that disappears from the wire.
A client library shared between a website and a React Native app usually fails on the boring parts of the Web platform, not on fetch. Reading React Native 0.87.1 and Expo 57 sources shows three layers of runtime, a URL class that returns ‘/b/c/d/../x’ where the web returns ‘/b/x’, and a fetch with no response stream unless Expo replaces it. A small client that checks what it needs, tested against four simulated runtimes.
A Durable Object has one alarm, runs it at least once, and retries a failing handler with backoff up to six times. After that nothing wakes the object again. A walkthrough of a lease-expiry ledger that survives all three: a table as the source of truth, a constructor that re-arms the alarm, and an effect that tolerates being run twice. Run on local workerd, with the documented limits quoted from Cloudflare.
Cloudflare’s docs say hibernation keeps WebSocket connections open and discards in-memory state. This post runs a small Durable Object under local workerd and watches exactly what that means: the socket stays OPEN, the constructor runs again on the next message, class fields reset, attachments survive only if you serialize them, and a pending timer or the standard WebSocket API quietly turns hibernation off. Production behaviour and billing are not tested.
A request deadline fired on a connection that carries many requests at once. Do you close the connection, or only the request? In a small Node lab, closing the HTTP/2 session failed two innocent requests, while cancelling only the stream let them finish on the same TCP connection. The same lab shows the one case where cancelling is not enough: a lost packet stalls every stream on a TCP connection, and a connection-level PING is the right way to tell.
WebSocket send() never waits, and bufferedAmount only sees the part of the path that is in your own process. In a small lab, a sender that politely waited for bufferedAmount to drain still let a slow consumer queue nearly all 400 messages in its own memory, while a credit window of 8 kept the backlog at 8. This post goes through four common beliefs about send(), bufferedAmount, message size and backpressure, tests each one, and ends with a table for choosing between them.
Refresh token rotation turns a reused token into a theft alarm. A client that fires three requests with an expired access token and refreshes once per 401 presents the same refresh token three times, and trips that alarm on itself. This post breaks a naive client on purpose, fixes it with single-flight refresh and a stale check, and compares the alternatives: a server grace window, request gating, proactive refresh and sender-constrained tokens.
When every WebSocket message costs money and every frame has a hard cap, you need batching with independent flush triggers, a single-frame threshold below the cap, bounded chunking, and capability flags that survive mixed-version rollouts. The sharp edges are ordering on shutdown and a zero value that disappears from the wire.