Web開発者のためのStreams解説

fetch()を呼び出してレスポンスを待つとき、ブラウザはすでにそのデータを断片的に受信しています。Web Streams APIは、レスポンス全体が到着してから触れるのを待つのではなく、到着した断片にJavaScriptコードからアクセスできるようにします。

この転換 — 「すべてを待つ」から「到着したものから処理する」へ — がストリームの本質です。

すべてを一度に読み込むことが問題である理由

従来のデータ取得アプローチは次のようなものです:

const response = await fetch('/large-dataset.json')
const data = await response.json()
// Nothing happens until all bytes are downloaded and parsed

小さなペイロードであれば問題ありません。しかし50MBのJSONファイルや長時間実行されるAPIレスポンスの場合、1つのレコードも処理する前に全体をメモリに保持することになります。制約のあるデバイスや低速な接続では、これはUIの遅延、高いメモリ圧迫、そしてユーザーのフラストレーションを意味します。

ストリームを使えば、最初のチャンクが到着した瞬間からデータの処理を開始できます。

Web Streams APIの3つのコアプリミティブ

Web Streams APIは3つのクラスを中心に構築されています:

• ReadableStream — データを読み取るソース
• WritableStream — データを書き込む宛先
• TransformStream — 中間に位置し、一方から読み取って変換されたデータをもう一方に書き込む

データはこれらのストリームを通じてチャンクとして移動します — 一度に1つずつ処理される小さな断片です。チャンクは、ストリームに応じて、バイトのUint8Array、文字列、または任意のJavaScript値になります。

Fetchストリーミング: レスポンスの段階的読み取り

ほとんどのfetch()レスポンスは、response.bodyを介してボディをReadableStreamとして公開します。これはフロントエンド開発者にとって、JavaScriptストリームへの最も一般的なエントリーポイントです。

async function processLargeResponse(url) {
  const response = await fetch(url)
  const reader = response.body.getReader()
  const decoder = new TextDecoder()

  try {
    while (true) {
      const { done, value } = await reader.read()
      if (done) break
      console.log(decoder.decode(value, { stream: true }))
    }
  } finally {
    reader.releaseLock()
  }
}

reader.read()は{ value, done }で解決されるpromiseを返します。doneがtrueのとき、ストリームは終了しています。このパターンにより、全体をバッファリングすることなく、数メガバイトのレスポンスをチャンクごとに処理できます。

リクエストボディのストリーミングに関する注意: ReadableStreamをfetch()のリクエストボディとして渡すことは可能ですが、ブラウザサポートにばらつきがあります。レスポンスのストリーミングは、今日使える十分にサポートされた実用的なパターンです。

pipeThrough()とpipeTo()によるデータパイプラインの構築

ストリームが真に強力になるのは合成です。ReadableStreamを1つ以上のTransformStreamインスタンスを通して連鎖させ、結果をWritableStreamにパイプできます。

fetch('./data.txt').then((response) =>
  response.body
    .pipeThrough(new TextDecoderStream())
    .pipeThrough(new TransformStream({
      transform(chunk, controller) {
        controller.enqueue(chunk.toUpperCase())
      }
    }))
    .pipeTo(new WritableStream({
      write(chunk) {
        document.body.textContent += chunk
      }
    }))
)

このパイプラインは、バイトをテキストにデコードし、各チャンクを大文字に変換してから、DOMに書き込みます — すべて段階的に、完全なレスポンスを待つことなく実行されます。

pipeThrough()はReadableStreamをTransformStreamに接続し、新しいReadableStreamを返します。pipeTo()はReadableStreamをWritableStreamに接続し、ストリームが完了したときに解決されるpromiseを返します。

バックプレッシャー: ストリームが過負荷を回避する方法

コンシューマーがプロデューサーがデータを生成するよりも遅くデータを処理する場合、ストリームはバックプレッシャーを適用します — パイプチェーンを通じて伝播する信号で、ソースに速度を落とすよう指示します。これはpipeTo()とpipeThrough()を使用すると自動的に発生します。これが、ループ内で手動でチャンクを読み取るよりもパイピングを優先すべき主な理由の1つです。

知っておくべき組み込みストリーム

ブラウザにはいくつかの既製のストリームユーティリティが搭載されています:

• TextDecoderStream / TextEncoderStream — バイトと文字列の間で変換
• CompressionStream / DecompressionStream — データをその場でgzipまたはdeflate
• Blob.stream() — 任意のBlobまたはFileをReadableStreamとして読み取る

最新のNode.jsもWeb Streams APIをサポートしているため、ブラウザ用に構築したパイプラインはサーバーサイド環境にもきれいに移植できます。

まとめ

Web Streams APIは、フロントエンド開発者に、時間をかけて到着するデータを処理するための、組み合わせ可能でメモリ効率の良い方法を提供します。ReadableStreamとTransformStreamは最もよく使うプリミティブです — 特に段階的なレスポンス処理のためにfetch()と組み合わせる場合に。response.bodyから始め、データを変換する必要があるときはpipeThrough()を使い、フロー制御はバックプレッシャーに任せましょう。

よくある質問

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.