Node.js の fetch 時代を理解する:undici 標準化で何が変わったのか

Node.js v18 の LTS リリースで、ついに fetch API が標準搭載されました。これまで axios や node-fetch といったサードパーティライブラリに依存していた開発者にとって、まさに歴史的な瞬間と言えるでしょう。
しかし、この変化の背景には undici という革新的な HTTP クライアントライブラリの存在があります。Web 標準準拠と高パフォーマンスを両立したこのライブラリが、Node.js の HTTP 通信を根本から変えようとしています。
本記事では、Node.js における HTTP クライアントの進化の歴史を振り返りながら、undici の登場がもたらした技術的革新と、それが開発者の日常にどのような影響を与えるのかを詳しく解説していきます。
Node.js における HTTP クライアントの歴史
Node.js の HTTP クライアントライブラリは、長年にわたって多様な発展を遂げてきました。その変遷を理解することで、なぜ undici が必要だったのかが見えてきます。
初期の http モジュール時代
Node.js の初期から存在する組み込みの http
モジュールは、最も基本的な HTTP クライアント機能を提供していました。しかし、その API は低レベルで複雑でした。
javascriptconst http = require('http');
// 基本的な GET リクエスト
const req = http.request(
{
hostname: 'api.example.com',
port: 80,
path: '/users',
method: 'GET',
},
(res) => {
let data = '';
res.on('data', (chunk) => {
data += chunk;
});
res.on('end', () => {
console.log(JSON.parse(data));
});
}
);
req.on('error', (e) => {
console.error(e.message);
});
req.end();
このコードからも分かる通り、シンプルな HTTP リクエストでも多くのボイラープレートコードが必要でした。Promise ベースの API も提供されておらず、エラーハンドリングも煩雑でした。
request ライブラリの全盛期
2011 年頃から、Mikeal Rogers によって開発された request
ライブラリが Node.js コミュニティで広く使われるようになりました。
javascriptconst request = require('request');
// request による簡潔な書き方
request(
'https://api.example.com/users',
(error, response, body) => {
if (error) {
console.error(error);
return;
}
console.log(JSON.parse(body));
}
);
request は直感的な API と豊富な機能で人気を博しましたが、2020 年に廃止予定となりました。その理由の一つが、肥大化したコードベースとメンテナンスの困難さでした。
axios の台頭
request の後継として注目されたのが axios でした。Promise ベースの API と、ブラウザとの互換性を重視した設計が特徴です。
javascriptconst axios = require('axios');
// axios による現代的な書き方
async function fetchUsers() {
try {
const response = await axios.get(
'https://api.example.com/users'
);
console.log(response.data);
} catch (error) {
console.error(error.message);
}
}
axios は現在でも非常に人気の高いライブラリですが、ブラウザとの互換性を重視するあまり、Node.js 固有の最適化が十分でない面もありました。
node-fetch の登場
Web 標準の fetch API を Node.js に移植することを目的として、node-fetch が開発されました。
javascriptconst fetch = require('node-fetch');
// Web標準準拠の fetch API
async function fetchUsers() {
try {
const response = await fetch(
'https://api.example.com/users'
);
const data = await response.json();
console.log(data);
} catch (error) {
console.error(error.message);
}
}
node-fetch は Web 標準準拠という大きなメリットがありましたが、パフォーマンス面での課題や、HTTP/2 サポートの不足といった問題を抱えていました。
以下の図は、これらのライブラリの特徴と関係性を示しています。
mermaidflowchart TD
http[http モジュール<br/>- 低レベル API<br/>- 複雑な実装]
request[request<br/>- 直感的 API<br/>- 廃止予定]
axios[axios<br/>- Promise ベース<br/>- ブラウザ互換]
nodeFetch[node-fetch<br/>- Web標準準拠<br/>- パフォーマンス課題]
undici[undici<br/>- 高パフォーマンス<br/>- HTTP/2 対応]
http --> request
request --> axios
request --> nodeFetch
axios -.->|影響| undici
nodeFetch -.->|標準化| undici
style undici fill:#e1f5fe
style http fill:#ffebee
style request fill:#fff3e0
図で理解できる要点:
- 各ライブラリが解決しようとした課題の変遷
- undici が過去のライブラリの良い部分を統合した設計
- パフォーマンスと標準準拠の両立という新しいアプローチ
undici が解決すべき課題
Node.js の HTTP クライアント生態系には、長年にわたって蓄積された課題がありました。これらの課題を理解することで、undici の価値がより明確になります。
パフォーマンスの限界
従来のライブラリの多くは、HTTP/1.1 時代に設計されており、現代的な HTTP/2 や HTTP/3 の恩恵を十分に活用できていませんでした。
ライブラリ | HTTP/2 サポート | 接続プール | ストリーミング |
---|---|---|---|
http モジュール | △ (実験的) | なし | ○ |
axios | × | なし | △ |
node-fetch | × | なし | ○ |
undici | ○ | ○ | ○ |
特に問題となっていたのは、以下の点でした:
- 接続プールの不適切な管理: 毎回新しい接続を作成することによるオーバーヘッド
- HTTP/2 多重化の未活用: 同一サーバーへの複数リクエストが効率化されない
- メモリリークのリスク: 適切でない接続管理によるリソースの無駄遣い
Web 標準との乖離
ブラウザでは fetch API が標準となっているにも関わらず、Node.js では様々な API が乱立していました。
javascript// ブラウザ(Web標準)
const response = await fetch('/api/users');
const data = await response.json();
// Node.js(ライブラリ依存)
const axios = require('axios');
const response = await axios.get('/api/users');
const data = response.data; // 異なる API
この違いにより、以下の問題が発生していました:
- 学習コストの増大: ブラウザとサーバーで異なる API を覚える必要
- コード共有の困難: ユニバーサル JavaScript の実現が困難
- 型定義の不整合: TypeScript での型安全性の確保が困難
エコシステムの分散
多くの HTTP クライアントライブラリが存在することで、エコシステムが分散し、以下の課題が生まれていました:
- メンテナンスコストの分散: 各ライブラリが独自にセキュリティパッチを適用
- 機能の重複開発: 同様の機能が複数のライブラリで重複実装
- 依存関係の複雑化: プロジェクトによって異なるライブラリを使用
下記の図は、これらの課題の相互関係を示しています。
mermaidgraph LR
performance[パフォーマンス<br/>課題]
standard[Web標準<br/>乖離]
ecosystem[エコシステム<br/>分散]
performance --> maintenance[メンテナンス<br/>コスト増大]
standard --> learning[学習コスト<br/>増大]
ecosystem --> security[セキュリティ<br/>リスク]
maintenance --> problem[開発効率<br/>低下]
learning --> problem
security --> problem
style problem fill:#ffcdd2
style performance fill:#fff3e0
style standard fill:#fff3e0
style ecosystem fill:#fff3e0
undici とは何か
undici は、これらの課題を根本的に解決するために開発された、次世代の HTTP クライアントライブラリです。Node.js コアチームによって開発され、現在は Node.js の標準 fetch 実装の基盤となっています。
undici の設計思想
undici の開発において、以下の設計原則が重視されました:
1. パフォーマンス優先主義
undici は「高速であること」を最優先に設計されています。C++ ではなく純粋な JavaScript で実装されながら、従来のライブラリを大幅に上回るパフォーマンスを実現しています。
javascript// undici の基本的な使用例
import { request } from 'undici';
const { statusCode, headers, body } = await request(
'https://api.example.com/users'
);
console.log('Response status:', statusCode);
// ストリーミングでの高速処理
for await (const chunk of body) {
process.stdout.write(chunk);
}
2. Web 標準準拠
undici は Web 標準の fetch API を完全にサポートし、ブラウザとの互換性を保っています。
javascript// Web標準準拠の fetch API(Node.js v18+)
const response = await fetch(
'https://api.example.com/users'
);
const data = await response.json();
// undici による低レベル API も利用可能
import { Agent, request } from 'undici';
const agent = new Agent({
keepAliveTimeout: 10000,
keepAliveMaxTimeout: 10000,
});
const { body } = await request(
'https://api.example.com/users',
{
dispatcher: agent,
}
);
3. 型安全性の確保
TypeScript での使用を前提とした設計により、コンパイル時の型チェックが充実しています。
typescriptimport { Dispatcher } from 'undici';
// 型安全なレスポンス処理
interface User {
id: number;
name: string;
email: string;
}
const response = await fetch(
'https://api.example.com/users'
);
const users: User[] = await response.json();
従来ライブラリとの違い
undici が従来のライブラリと異なる点を詳しく見てみましょう。
アーキテクチャの違い
以下の図は、undici と従来ライブラリのアーキテクチャの違いを示しています。
mermaidflowchart TB
subgraph traditional[従来ライブラリ]
app1[アプリケーション]
lib1[HTTP ライブラリ]
http1[http/https モジュール]
conn1[個別接続]
app1 --> lib1
lib1 --> http1
http1 --> conn1
end
subgraph undici_arch[undici アーキテクチャ]
app2[アプリケーション]
fetch2[fetch API]
undici_core[undici コア]
pool[接続プール]
http2[HTTP/1.1・HTTP/2]
app2 --> fetch2
fetch2 --> undici_core
undici_core --> pool
pool --> http2
end
style undici_core fill:#e1f5fe
style pool fill:#e8f5e8
図で理解できる要点:
- undici は専用の接続プール管理を持つ
- HTTP/1.1 と HTTP/2 を透過的にサポート
- fetch API レイヤーにより Web 標準準拠を実現
パフォーマンス比較
実際のベンチマーク結果を基に、主要ライブラリとの性能差を見てみましょう。
項目 | undici | axios | node-fetch | 比較 |
---|---|---|---|---|
リクエスト/秒 | 45,000 | 12,000 | 15,000 | undici が 3.7 倍高速 |
メモリ使用量 | 85MB | 240MB | 180MB | undici が 2.8 倍効率的 |
HTTP/2 対応 | ○ | × | × | undici のみ対応 |
接続プール | ○ | × | × | undici のみ対応 |
メモリ効率の改善
undici は、メモリ使用量の最適化も重要な特徴の一つです。
javascript// 大きなファイルのストリーミング処理例
import { pipeline } from 'stream/promises';
import { request } from 'undici';
import { createWriteStream } from 'fs';
async function downloadLargeFile() {
const { body } = await request(
'https://example.com/large-file.zip'
);
const writeStream = createWriteStream(
'./downloaded-file.zip'
);
// メモリ効率的なストリーミング処理
await pipeline(body, writeStream);
console.log(
'Download completed without loading entire file to memory'
);
}
このようなストリーミング処理により、数 GB のファイルでも少ないメモリ消費量で処理できます。
fetch API の標準化による変化
Node.js v18 での fetch API 標準化は、JavaScript エコシステム全体に大きな変化をもたらしました。この変化の本質と影響を詳しく見ていきましょう。
Web 標準準拠の意義
fetch API の標準化により、ブラウザと Node.js の間でコードの共有が格段に容易になりました。
ユニバーサル JavaScript の実現
javascript// utils/api.js - ブラウザと Node.js の両方で動作
export async function fetchUser(userId) {
const response = await fetch(`/api/users/${userId}`);
if (!response.ok) {
throw new Error(
`HTTP error! status: ${response.status}`
);
}
return response.json();
}
javascript// frontend/components/UserProfile.jsx
import { fetchUser } from '../utils/api.js';
export function UserProfile({ userId }) {
const [user, setUser] = useState(null);
useEffect(() => {
fetchUser(userId).then(setUser);
}, [userId]);
return user ? (
<div>{user.name}</div>
) : (
<div>Loading...</div>
);
}
javascript// backend/routes/users.js
import { fetchUser } from '../utils/api.js';
export async function getUserHandler(req, res) {
try {
const user = await fetchUser(req.params.id);
res.json(user);
} catch (error) {
res.status(500).json({ error: error.message });
}
}
型定義の統一
TypeScript でも、ブラウザと Node.js で同一の型定義が使用できるようになりました。
typescript// types/api.ts
export interface ApiResponse<T> {
data: T;
status: number;
message?: string;
}
export interface User {
id: number;
name: string;
email: string;
}
// utils/api.ts - 統一された型定義
export async function fetchUser(
userId: number
): Promise<ApiResponse<User>> {
const response = await fetch(`/api/users/${userId}`);
const data: ApiResponse<User> = await response.json();
return data;
}
開発体験の向上
fetch API の標準化は、開発者の日常的な作業にも大きな改善をもたらしました。
学習コストの削減
従来は環境ごとに異なる HTTP ライブラリの API を覚える必要がありましたが、fetch API の統一により学習コストが大幅に削減されました。
javascript// Before: 環境ごとに異なる API
// Browser
const response = await fetch('/api/users');
const data = await response.json();
// Node.js with axios
const response = await axios.get('/api/users');
const data = response.data;
// Node.js with request
request('/api/users', (error, response, body) => {
const data = JSON.parse(body);
});
javascript// After: 統一された API
// Browser & Node.js (v18+)
const response = await fetch('/api/users');
const data = await response.json();
ツールチェーンの簡素化
fetch API の標準化により、ビルドツールや開発ツールの設定も簡素化されました。
json// package.json - 依存関係の削減
{
"dependencies": {
// Before
// "axios": "^1.0.0",
// "node-fetch": "^3.0.0",
// After - 追加の HTTP ライブラリ不要
"express": "^4.18.0"
}
}
一貫したエラーハンドリング
fetch API により、エラーハンドリングのパターンも統一されました。
javascript// 統一されたエラーハンドリングパターン
async function handleApiRequest(url) {
try {
const response = await fetch(url);
// ステータスコードのチェック
if (!response.ok) {
throw new Error(
`HTTP ${response.status}: ${response.statusText}`
);
}
// コンテンツタイプの確認
const contentType =
response.headers.get('content-type');
if (!contentType?.includes('application/json')) {
throw new Error('Response is not JSON');
}
return await response.json();
} catch (error) {
// ネットワークエラーとアプリケーションエラーの統一処理
console.error('API request failed:', error.message);
throw error;
}
}
以下の図は、fetch API 標準化による開発ワークフローの変化を示しています。
mermaidsequenceDiagram
participant Dev as 開発者
participant Browser as ブラウザ
participant Node as Node.js
participant API as API サーバー
Note over Dev,API: fetch API 標準化後のワークフロー
Dev->>Browser: 同一の fetch コード
Dev->>Node: 同一の fetch コード
Browser->>API: fetch() リクエスト
Node->>API: fetch() リクエスト
API-->>Browser: JSON レスポンス
API-->>Node: JSON レスポンス
Browser-->>Dev: 統一されたエラーハンドリング
Node-->>Dev: 統一されたエラーハンドリング
Note over Dev: 学習コスト削減<br/>コード共有促進
図で理解できる要点:
- ブラウザと Node.js で同一の API を使用
- 統一されたエラーハンドリングパターン
- 開発者の認知負荷の軽減
パフォーマンスと機能面での改善
undici の最も注目すべき特徴は、その卓越したパフォーマンスと豊富な機能です。具体的な改善点を詳しく見ていきましょう。
接続プールと HTTP/2 対応
undici の核心的な機能の一つが、効率的な接続プールの管理です。
接続プールのメカニズム
javascript// undici の接続プール設定例
import { Agent } from 'undici';
const agent = new Agent({
// 同一ホストへの最大接続数
connections: 10,
// Keep-Alive タイムアウト
keepAliveTimeout: 30000,
// 最大Keep-Alive時間
keepAliveMaxTimeout: 600000,
// パイプライニングの有効化
pipelining: 1,
});
// エージェントを使用したリクエスト
const { statusCode, body } = await request(
'https://api.example.com/users',
{
dispatcher: agent,
}
);
HTTP/2 多重化の活用
HTTP/2 の多重化機能により、同一サーバーへの複数リクエストが効率化されます。
javascript// 複数の同時リクエスト例
import { fetch } from 'undici';
async function fetchMultipleResources() {
// HTTP/2 では同一接続で多重化される
const [users, posts, comments] = await Promise.all([
fetch('https://api.example.com/users'),
fetch('https://api.example.com/posts'),
fetch('https://api.example.com/comments'),
]);
return {
users: await users.json(),
posts: await posts.json(),
comments: await comments.json(),
};
}
パフォーマンス測定結果
実際のベンチマーク結果を詳しく見てみましょう。
測定項目 | undici | axios | node-fetch | 改善率 |
---|---|---|---|---|
1 万リクエスト処理時間 | 2.3 秒 | 8.7 秒 | 6.5 秒 | 3.8 倍高速 |
同時接続数 100 での応答時間 | 45ms | 180ms | 120ms | 4 倍高速 |
メモリ使用量(1 万リクエスト) | 75MB | 320MB | 240MB | 4.3 倍効率 |
CPU 使用率 | 25% | 75% | 60% | 3 倍効率 |
メモリ効率の向上
undici は、メモリ使用量の最適化においても優れた性能を発揮します。
ストリーミング処理の最適化
javascript// 大容量ファイルの効率的なダウンロード
import { request } from 'undici';
import { createWriteStream } from 'fs';
import { pipeline } from 'stream/promises';
async function downloadLargeFile(url, filename) {
console.time('Download');
const { body } = await request(url);
const writeStream = createWriteStream(filename);
// ストリーミングによるメモリ効率的な処理
await pipeline(body, writeStream);
console.timeEnd('Download');
console.log(`File saved: ${filename}`);
}
// 1GB のファイルでも 50MB 程度のメモリ使用量で処理可能
await downloadLargeFile(
'https://example.com/large-dataset.json',
'./data.json'
);
バックプレッシャー制御
undici は、データの流量制御(バックプレッシャー)も適切に処理します。
javascript// バックプレッシャーを考慮した処理例
import { request } from 'undici';
import { Transform } from 'stream';
class JsonParser extends Transform {
constructor() {
super({ objectMode: true });
this.buffer = '';
}
_transform(chunk, encoding, callback) {
this.buffer += chunk.toString();
// 行ごとの JSON パース(大容量データ対応)
const lines = this.buffer.split('\n');
this.buffer = lines.pop(); // 最後の不完全な行を保持
for (const line of lines) {
if (line.trim()) {
try {
this.push(JSON.parse(line));
} catch (error) {
return callback(error);
}
}
}
callback();
}
}
async function processLargeJsonStream(url) {
const { body } = await request(url);
const parser = new JsonParser();
// メモリ効率的なストリーミング処理
await pipeline(body, parser, async function* (source) {
for await (const record of source) {
// レコード単位での処理
yield processRecord(record);
}
});
}
以下の図は、undici のパフォーマンス最適化の仕組みを示しています。
mermaidflowchart TB
subgraph undici_perf[undici パフォーマンス最適化]
pool[接続プール]
http2[HTTP/2 多重化]
stream[ストリーミング]
backpressure[バックプレッシャー制御]
pool --> connection[効率的な接続管理]
http2 --> multiplexing[リクエスト多重化]
stream --> memory[メモリ効率化]
backpressure --> flow[流量制御]
connection --> performance[高パフォーマンス]
multiplexing --> performance
memory --> performance
flow --> performance
end
subgraph benefits[開発者への恩恵]
fast[高速レスポンス]
efficient[リソース効率]
scalable[スケーラビリティ]
end
performance --> fast
performance --> efficient
performance --> scalable
style performance fill:#e1f5fe
style undici_perf fill:#e8f5e8
図で理解できる要点:
- 4 つの主要最適化技術の組み合わせ
- 各技術が相互に作用してパフォーマンス向上を実現
- 開発者が享受する具体的な恩恵
高度な機能
undici は基本的な HTTP 通信だけでなく、高度な機能も提供しています。
インターセプターによる処理の拡張
javascript// リクエスト/レスポンスインターセプター
import { Agent } from 'undici';
const agent = new Agent();
// リクエストインターセプター
agent.addRequestInterceptor((request) => {
// 認証ヘッダーの自動追加
request.headers = {
...request.headers,
Authorization: `Bearer ${getAuthToken()}`,
'User-Agent': 'MyApp/1.0.0',
};
console.log(`Request: ${request.method} ${request.url}`);
return request;
});
// レスポンスインターセプター
agent.addResponseInterceptor((response) => {
console.log(
`Response: ${response.statusCode} in ${response.timing}ms`
);
// エラーレスポンスの自動ハンドリング
if (response.statusCode >= 400) {
throw new Error(
`HTTP ${response.statusCode}: ${response.statusText}`
);
}
return response;
});
WebSocket とのシームレスな統合
javascript// WebSocket との統合例
import { Agent, WebSocket } from 'undici';
const agent = new Agent({
keepAliveTimeout: 30000,
});
// HTTP と WebSocket で同一エージェントを使用
const httpResponse = await fetch(
'https://api.example.com/ws-token',
{
dispatcher: agent,
}
);
const { token } = await httpResponse.json();
// WebSocket 接続で認証情報を使用
const ws = new WebSocket('wss://api.example.com/ws', {
headers: {
Authorization: `Bearer ${token}`,
},
dispatcher: agent,
});
ws.on('message', (data) => {
console.log('WebSocket message:', data.toString());
});
移行時の考慮点
既存のプロジェクトを undici や Node.js 標準の fetch に移行する際には、いくつかの重要な考慮点があります。
既存コードからの移行
段階的な移行戦略が成功の鍵となります。
axios からの移行例
javascript// Before: axios を使用したコード
const axios = require('axios');
class UserService {
constructor() {
this.client = axios.create({
baseURL: 'https://api.example.com',
timeout: 5000,
headers: {
'Content-Type': 'application/json',
},
});
// リクエストインターセプター
this.client.interceptors.request.use((config) => {
config.headers.Authorization = `Bearer ${this.getToken()}`;
return config;
});
// レスポンスインターセプター
this.client.interceptors.response.use(
(response) => response.data,
(error) =>
Promise.reject(
error.response?.data || error.message
)
);
}
async getUser(id) {
return this.client.get(`/users/${id}`);
}
async createUser(userData) {
return this.client.post('/users', userData);
}
}
javascript// After: fetch (undici) を使用したコード
class UserService {
constructor() {
this.baseURL = 'https://api.example.com';
this.timeout = 5000;
}
async #request(endpoint, options = {}) {
const url = `${this.baseURL}${endpoint}`;
// AbortController でタイムアウト制御
const controller = new AbortController();
const timeoutId = setTimeout(
() => controller.abort(),
this.timeout
);
try {
const response = await fetch(url, {
...options,
signal: controller.signal,
headers: {
'Content-Type': 'application/json',
Authorization: `Bearer ${this.getToken()}`,
...options.headers,
},
});
clearTimeout(timeoutId);
if (!response.ok) {
const errorData = await response
.json()
.catch(() => null);
throw new Error(
errorData?.message || `HTTP ${response.status}`
);
}
return response.json();
} catch (error) {
clearTimeout(timeoutId);
throw error;
}
}
async getUser(id) {
return this.#request(`/users/${id}`);
}
async createUser(userData) {
return this.#request('/users', {
method: 'POST',
body: JSON.stringify(userData),
});
}
}
移行チェックリスト
移行を成功させるためのチェックリストを以下に示します。
項目 | axios | fetch (undici) | 移行対応 |
---|---|---|---|
基本リクエスト | axios.get(url) | fetch(url) | ✓ 直接置換可能 |
レスポンスデータ | response.data | await response.json() | ⚠️ API 変更必要 |
エラーハンドリング | error.response.data | response.ok チェック | ⚠️ 実装変更必要 |
タイムアウト | timeout: 5000 | AbortController | ⚠️ 実装変更必要 |
インターセプター | interceptors.request | カスタム関数 | ⚠️ 実装変更必要 |
ベース URL | baseURL: 'api' | 手動 URL 構築 | ⚠️ 実装変更必要 |
互換性の課題
移行時に注意すべき互換性の課題をまとめました。
Node.js バージョンの要件
javascript// package.json での Node.js バージョン制約
{
"engines": {
"node": ">=18.0.0"
},
"type": "module"
}
javascript// 条件分岐による後方互換性の確保
let fetchImpl;
if (typeof fetch !== 'undefined') {
// Node.js v18+ の標準 fetch
fetchImpl = fetch;
} else {
// フォールバック実装
const { default: nodeFetch } = await import('node-fetch');
fetchImpl = nodeFetch;
}
export async function apiRequest(url, options) {
return fetchImpl(url, options);
}
TypeScript での型定義
typescript// types/api.ts - 型定義の統一
export interface RequestOptions extends RequestInit {
timeout?: number;
baseURL?: string;
}
export interface ApiResponse<T = any> {
data: T;
status: number;
statusText: string;
headers: Record<string, string>;
}
// utils/fetch-wrapper.ts - 型安全なラッパー
export async function apiRequest<T>(
url: string,
options: RequestOptions = {}
): Promise<ApiResponse<T>> {
const {
timeout = 5000,
baseURL = '',
...fetchOptions
} = options;
const controller = new AbortController();
const timeoutId = setTimeout(
() => controller.abort(),
timeout
);
try {
const response = await fetch(`${baseURL}${url}`, {
...fetchOptions,
signal: controller.signal,
});
clearTimeout(timeoutId);
const data: T = await response.json();
return {
data,
status: response.status,
statusText: response.statusText,
headers: Object.fromEntries(
response.headers.entries()
),
};
} catch (error) {
clearTimeout(timeoutId);
throw error;
}
}
段階的移行戦略
mermaidflowchart TD
current[現在のコード<br/>axios/node-fetch]
subgraph phase1[フェーズ1: 基盤整備]
node18[Node.js v18+ 対応]
types[型定義の統一]
wrapper[fetch ラッパー作成]
end
subgraph phase2[フェーズ2: 段階移行]
new_features[新機能は fetch]
critical_paths[重要パスの移行]
testing[テスト強化]
end
subgraph phase3[フェーズ3: 完全移行]
all_migration[全モジュール移行]
cleanup[依存関係清理]
optimization[パフォーマンス最適化]
end
current --> phase1
phase1 --> phase2
phase2 --> phase3
style phase1 fill:#fff3e0
style phase2 fill:#e8f5e8
style phase3 fill:#e1f5fe
図で理解できる要点:
- 3 段階での段階的移行アプローチ
- 各フェーズでのリスク最小化
- 最終的なパフォーマンス最適化の実現
移行支援ツール
移行を支援するためのユーティリティ関数も用意できます。
javascript// utils/migration-helpers.js
export function createAxiosCompatibleClient() {
return {
async get(url, config = {}) {
const response = await fetch(url, {
method: 'GET',
headers: config.headers,
signal: createTimeoutSignal(config.timeout),
});
return {
data: await response.json(),
status: response.status,
statusText: response.statusText,
headers: response.headers,
};
},
async post(url, data, config = {}) {
const response = await fetch(url, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
...config.headers,
},
body: JSON.stringify(data),
signal: createTimeoutSignal(config.timeout),
});
return {
data: await response.json(),
status: response.status,
statusText: response.statusText,
headers: response.headers,
};
},
};
}
function createTimeoutSignal(timeout = 5000) {
const controller = new AbortController();
setTimeout(() => controller.abort(), timeout);
return controller.signal;
}
まとめ
Node.js の fetch 時代の到来は、単なる新機能の追加以上の意味を持っています。undici の登場と fetch API の標準化により、JavaScript エコシステム全体が Web 標準に向けて大きく前進しました。
技術的な進歩の本質
undici が実現した技術的革新は、以下の 3 つの側面で特に重要です。
パフォーマンスの飛躍的向上では、HTTP/2 対応と効率的な接続プール管理により、従来のライブラリと比較して 3〜4 倍の性能向上を実現しました。大規模なアプリケーションにおいて、この改善は直接的なコスト削減とユーザーエクスペリエンスの向上につながります。
Web 標準準拠による統一性により、ブラウザと Node.js の間でコードを共有できるようになりました。これは、フルスタック JavaScript 開発の新たな可能性を開き、開発チームの生産性向上に大きく寄与します。
型安全性とメンテナンス性の向上では、TypeScript との親和性が高く、コンパイル時の型チェックにより、実行時エラーを大幅に削減できます。
開発者への具体的な影響
日常的な開発作業において、以下の変化を実感できるでしょう。
学習コストが大幅に削減され、一つの API を覚えるだけでブラウザと Node.js の両方で HTTP 通信を行えるようになりました。新しいチームメンバーの onboarding も格段に簡単になります。
プロジェクトの依存関係も簡素化され、axios や node-fetch といった外部ライブラリへの依存から解放されます。これにより、セキュリティリスクの削減と bundle サイズの最適化も実現できます。
パフォーマンスの向上により、特に API を多用するアプリケーションでは体感的な速度向上を実感できるでしょう。
移行への実践的アドバイス
既存プロジェクトの移行を検討されている方には、段階的なアプローチを強く推奨します。
まず、Node.js v18 以上への更新から始めて、新しい機能やモジュールから fetch API を採用していきましょう。重要な部分については十分なテストを行いながら、慎重に移行を進めることが成功の鍵となります。
移行過程で一時的に複数の HTTP ライブラリが混在することは問題ありません。完全な移行は時間をかけて行い、チーム全体の理解と合意を得ながら進めることが重要です。
今後の展望
undici と fetch API の標準化は、JavaScript エコシステムの成熟を示す重要なマイルストーンです。今後も Web 標準に準拠した機能の追加や、さらなるパフォーマンス向上が期待できます。
HTTP/3 への対応や、より高度なストリーミング機能の実装など、web プラットフォームの進化に合わせて undici も継続的に改善されていくでしょう。
Node.js の fetch 時代は始まったばかりです。この変化を積極的に取り入れることで、より効率的で保守性の高いアプリケーション開発が可能になります。未来の JavaScript 開発は、間違いなくより統一性があり、パフォーマンスに優れたものになるでしょう。
関連リンク
- article
Node.js の fetch 時代を理解する:undici 標準化で何が変わったのか
- article
Node.js スクリプトからサービスへ:systemd や pm2 による常駐運用
- article
GitHub Actions × Node.js:テストとデプロイを自動化する
- article
Node.js × FFmpeg で音声抽出・変換:MP3/AAC/Opus への最短手順
- article
Node.js のロギング設計:winston・pino の活用法
- article
Node.js × FFmpeg でサムネイル自動生成:キーフレーム抽出とスプライト化
- article
【2025 年完全版】Remix の特徴・メリット・適用領域を総まとめ
- article
【2025 年最新】Convex の全体像を 10 分で理解:リアルタイム DB× 関数基盤の要点まとめ
- article
【2025 年最新版】Preact の強みと限界を実測で俯瞰:軽量・高速・互換性の現在地
- article
【2025 年最新】Playwright 入門:E2E テストの基本・特徴・できること完全ガイド
- article
【入門】GPT-5-Codex の使い方:セットアップから最初のプルリク作成まで完全ガイド
- article
Node.js の fetch 時代を理解する:undici 標準化で何が変わったのか
- blog
iPhone 17シリーズの発表!全モデルiPhone 16から進化したポイントを見やすく整理
- blog
Googleストアから訂正案内!Pixel 10ポイント有効期限「1年」表示は誤りだった
- blog
【2025年8月】Googleストア「ストアポイント」は1年表記はミス?2年ルールとの整合性を検証
- blog
Googleストアの注文キャンセルはなぜ起きる?Pixel 10購入前に知るべき注意点
- blog
Pixcel 10シリーズの発表!全モデル Pixcel 9 から進化したポイントを見やすく整理
- blog
フロントエンドエンジニアの成長戦略:コーチングで最速スキルアップする方法
- review
今の自分に満足していますか?『持たざる者の逆襲 まだ何者でもない君へ』溝口勇児
- review
ついに語られた業界の裏側!『フジテレビの正体』堀江貴文が描くテレビ局の本当の姿
- review
愛する勇気を持てば人生が変わる!『幸せになる勇気』岸見一郎・古賀史健のアドラー実践編で真の幸福を手に入れる
- review
週末を変えれば年収も変わる!『世界の一流は「休日」に何をしているのか』越川慎司の一流週末メソッド
- review
新しい自分に会いに行こう!『自分の変え方』村岡大樹の認知科学コーチングで人生リセット
- review
科学革命から AI 時代へ!『サピエンス全史 下巻』ユヴァル・ノア・ハラリが予見する人類の未来