https://blog.yusukeikoma.com/ja/tags/javascript/Recent content in javascript on Ikoma's BlogHugoja-jpSat, 26 Sep 2026 21:31:14 +0900https://blog.yusukeikoma.com/ja/posts/react-native-builtin-url-does-not-resolve-dot-dot/Sat, 26 Sep 2026 21:31:14 +0900https://blog.yusukeikoma.com/ja/posts/react-native-builtin-url-does-not-resolve-dot-dot/ウェブサイトと React Native アプリで共有するクライアントライブラリが壊れるのは、fetch ではなく、Web プラットフォームの地味な部分であることが多いです。React Native 0.87.1 と Expo 57 のソースを読むと、ランタイムが3層あること、ウェブなら ‘/b/x’ になるところを ‘/b/c/d/../x’ と返す URL クラスがあること、Expo が置き換えない限り fetch にレスポンスのストリームがないことが分かります。必要なものを確認する小さなクライアントを、4つの模擬ランタイムでテストします。https://blog.yusukeikoma.com/ja/posts/durable-object-alarm-retries-six-times-then-stops/Thu, 24 Sep 2026 21:33:45 +0900https://blog.yusukeikoma.com/ja/posts/durable-object-alarm-retries-six-times-then-stops/Durable Object のアラームは1つだけで、少なくとも1回実行され、失敗するハンドラーはバックオフ付きで最大6回再試行されます。それが尽きると、オブジェクトを再び起こすものは何もありません。この3つに耐えるリース失効の台帳を、コードに注釈をつけて見ていきます。真実を持つ表、アラームを再設定するコンストラクター、2回実行されても困らない副作用です。ローカルの workerd で動かし、制限は Cloudflare の文書から引用しています。https://blog.yusukeikoma.com/ja/posts/durable-objects-websocket-hibernation/Tue, 22 Sep 2026 13:39:45 +0900https://blog.yusukeikoma.com/ja/posts/durable-objects-websocket-hibernation/CloudflareのドキュメントはWebSocket Hibernationについて、接続は維持され、メモリ上の状態は破棄される、と書いています。この記事では小さなDurable Objectをローカルのworkerdで動かし、それが具体的に何を意味するかを観察します。ソケットはOPENのまま、次のメッセージでコンストラクターが再実行され、クラスのフィールドは初期化され、アタッチメントはserializeしたものだけが残り、保留中のタイマーや標準のWebSocket APIを使うとハイバネーションがひそかに無効になります。本番の挙動や課金は試していません。https://blog.yusukeikoma.com/ja/posts/http2-timeout-stream-vs-connection/Tue, 08 Sep 2026 12:56:00 +0900https://blog.yusukeikoma.com/ja/posts/http2-timeout-stream-vs-connection/たくさんのリクエストを同時に流している1本の接続で、1つのリクエストの期限が来たとき、接続ごと閉じるべきか、そのリクエストだけを閉じるべきか。小さなNodeの実験では、HTTP/2のセッションを閉じると無関係な2本が失敗し、ストリームだけをキャンセルすると同じTCP接続のまま2本とも完了しました。ただし、TCPの1パケットの遅れは接続上の全ストリームを止めます。その場合に接続の生死を確かめる方法として、PINGを使った確認も試します。https://blog.yusukeikoma.com/ja/posts/websocket-bufferedamount-backpressure/Sun, 06 Sep 2026 20:54:24 +0900https://blog.yusukeikoma.com/ja/posts/websocket-bufferedamount-backpressure/WebSocketのsend()は待ってくれず、bufferedAmountが見ているのは自分のプロセスの中の待ち行列だけです。小さな実験では、bufferedAmountが減るのを待ってから送る送信側でも、受信側のメモリには、400件のほぼ全部が溜まりました。受信側が処理済みを返す「クレジット窓」(8件)なら、溜まるのは8件で止まりました。send()、bufferedAmount、メッセージサイズ、バックプレッシャーについてよくある4つの思い込みを実際に試し、使い分けの表にまとめます。https://blog.yusukeikoma.com/ja/posts/refresh-token-rotation-concurrent-requests/Sun, 30 Aug 2026 13:34:18 +0900https://blog.yusukeikoma.com/ja/posts/refresh-token-rotation-concurrent-requests/リフレッシュトークンのローテーションは、使用済みトークンの再利用を盗難の警報として扱います。期限切れのアクセストークンで3つのリクエストを同時に送り、401ごとに更新するクライアントは、同じリフレッシュトークンを3回提示して、自分で警報を鳴らします。この記事では、素朴なクライアントをあえて壊し、single-flight と stale check で直します。そのうえで、サーバー側の猶予期間、リクエストの待機、先回り更新、送信者制約付きトークンを比べます。https://blog.yusukeikoma.com/ja/posts/batching-and-bounded-frames-on-a-metered-relay/Wed, 19 Aug 2026 12:47:53 +0900https://blog.yusukeikoma.com/ja/posts/batching-and-bounded-frames-on-a-metered-relay/WebSocket のメッセージごとに課金され、フレームにも上限がある環境では、独立したフラッシュ条件を持つバッチ送信、上限より低い単一フレームのしきい値、上限付きの分割、混在バージョンのロールアウトを生き延びる能力フラグが必要です。難所は、終了時の順序と、ワイヤ上から消えるゼロ値です。