メインコンテンツまでスキップ
バージョン: 0.9.0 (最新)

🚀 製品機能

製品機能は、Nodeblocksアプリケーションにおける製品管理操作のための完全な事前構成済み機能を提供します。これらの機能は、スキーマ、ルート、ハンドラーを組み合わせて、製品CRUD操作、バッチ操作、製品コピーのための即座に使用可能なAPIエンドポイントを作成します。


🎯 概要

製品機能は以下の目的で設計されています:

  • 完全なCRUD操作を含む完全な製品管理を提供
  • 効率的な一括製品処理のためのバッチ操作をサポート
  • 安全な製品操作のための検証とルーティングを含む
  • 製品一覧のためのフィルタリングとページネーションをサポート
  • 製品コピーと複製ワークフローを処理

📋 機能構造

各製品機能は一貫した構成パターンに従います:

  • スキーマ: 製品入力データとパラメータを検証
  • ルート: 製品ハンドラー付きHTTPエンドポイントを提供
  • 構成: compose関数を使用してスキーマとルートを組み合わせ

🔧 利用可能な製品機能

createProductFeature

スキーマ検証とルーティング付き製品作成機能。

目的: 完全な検証を含む製品作成を処理

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';


// With database configuration
app.use('/api', defService(partial(features.createProductFeature, [{ dataStores: db }])));

APIエンドポイント: POST /api/products


createProductBatchFeature

スキーマ検証とルーティング付きバッチ製品作成機能。

目的: 検証を含むバッチ製品作成を処理

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';


// With database configuration
app.use('/api', defService(partial(features.createProductBatchFeature, [{ dataStores: db }])));

APIエンドポイント: POST /api/products/batch


getProductFeatures

個別製品データを取得するための製品取得機能。

目的: 適切な検証を含む製品情報を取得

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';


// With database configuration
app.use('/api', defService(partial(features.getProductFeatures, [{ dataStores: db }])));

APIエンドポイント: GET /api/products/:productId


findProductsFeatures

フィルタリングとページネーション付き製品検索機能。

目的: 検索機能付きの製品一覧を提供

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';


// With database configuration
app.use('/api', defService(partial(features.findProductsFeatures, [{ dataStores: db }])));

APIエンドポイント: GET /api/products


editProductFeatures

スキーマ検証とルーティング付き製品更新機能。

目的: 適切な検証を含む製品情報を変更

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';


// With database configuration
app.use('/api', defService(partial(features.editProductFeatures, [{ dataStores: db }])));

APIエンドポイント: PATCH /api/products/:productId


editProductBatchFeatures

スキーマ検証とルーティング付きバッチ製品更新機能。

目的: 検証を含むバッチ製品更新を処理

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';


// With database configuration
app.use('/api', defService(partial(features.editProductBatchFeatures, [{ dataStores: db }])));

APIエンドポイント: PATCH /api/products/batch


deleteProductFeatures

ルーティング付き製品削除機能。

目的: アクセス制御とクリーンアップ付きで製品を削除

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';


// With database configuration
app.use('/api', defService(partial(features.deleteProductFeatures, [{ dataStores: db }])));

APIエンドポイント: DELETE /api/products/:productId


deleteProductBatchFeatures

スキーマ検証とルーティング付きバッチ製品削除機能。

目的: 検証を含むバッチ製品削除を処理

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';


// With database configuration
app.use('/api', defService(partial(features.deleteProductBatchFeatures, [{ dataStores: db }])));

APIエンドポイント: DELETE /api/products/batch


copyProductFeatures

ルーティング付き製品コピー機能。

目的: 適切な複製で製品コピーを作成

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';


// With database configuration
app.use('/api', defService(partial(features.copyProductFeatures, [{ dataStores: db }])));

APIエンドポイント: POST /api/products/:productId/copy


copyProductBatchFeatures

スキーマ検証とルーティング付きバッチ製品コピー機能。

目的: 検証を含むバッチ製品コピーを処理

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';


// With database configuration
app.use('/api', defService(partial(features.copyProductBatchFeatures, [{ dataStores: db }])));

APIエンドポイント: POST /api/products/batch/copy


getProductImageUploadUrlFeature

製品画像をアップロードするための事前署名付きURLを生成します。

目的: 一意のオブジェクト名で署名付きアップロードURLを発行し、生成されたobjectIdと共に返す

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';

// With file storage service in configuration:
app.use(
'/api',
defService(partial(features.getProductImageUploadUrlFeature, [{ configuration: { fileStorageDriver } }]))
);

APIエンドポイント: GET /api/products/:productId/image-upload-url


createProductImageFeature

検証とルーティング付きで既存の製品の新しい製品画像を作成します。

目的: 完全な検証と取得を含む製品画像作成を処理

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';

// With database configuration:
app.use('/api', defService(partial(features.createProductImageFeature, [{ dataStores: db }])));

APIエンドポイント: POST /api/products/:productId/images

リクエストボディ:

{
"objectId": "550e8400-e29b-41d4-a716-446655440000",
"type": "image/png"
}

レスポンス(201 Created):

{
"id": "generated-image-id",
"objectId": "550e8400-e29b-41d4-a716-446655440000",
"type": "image/png",
"createdAt": "2025-01-15T10:30:00Z",
"updatedAt": "2025-01-15T10:30:00Z"
}

機能:

  • 画像の自動ベースエンティティ生成(id、createdAt、updatedAt)
  • 製品の画像配列に画像を追加
  • レスポンス用の作成後の画像取得
  • 欠落している製品またはデータベース失敗の適切なエラー処理

deleteProductImageFeature

検証とファイルストレージクリーンアップ付きで製品画像を削除します。

目的: 完全な検証とストレージクリーンアップを含む製品画像削除を処理

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';

// With database and file storage configuration:
app.use('/api', defService(
partial(features.deleteProductImageFeature, [
{ dataStores: db, fileStorageDriver }
])
));

APIエンドポイント: DELETE /api/products/:productId/images/:imageId

レスポンス(204 No Content): 削除成功時の空のレスポンスボディ

機能:

  • 製品の画像配列から画像を削除
  • ファイルストレージから実際の画像ファイルを削除
  • 製品のupdatedAtタイムスタンプを更新
  • 適切なロールバック処理を含むアトミック操作
  • 欠落している製品または画像の適切なエラー処理

エラーレスポンス:

  • 404: 製品が見つからないか、画像が見つかりませんでした
  • 500: データベース操作が失敗したか、ファイル削除が失敗しました

createProductVariantFeature

スキーマ検証とルーティング付き製品バリアント作成機能。

目的: 完全な検証と正規化を含む既存の製品の新しい製品バリアントを作成

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';

// Direct usage:
app.use('/api', defService(features.createProductVariantFeature));

// With database configuration:
app.use('/api', defService(
partial(features.createProductVariantFeature, [
{ dataStores: { productVariants: db.collection('productVariants') } }
])
));

APIエンドポイント: POST /api/products/:productId/variants

リクエストボディ:

{
"title": "Blue Baseball Cap",
"description": "Premium baseball cap in blue color",
"sku": "BBC-BLUE",
"imageIds": ["img-456", "img-789"],
"price": {
"amount": 2999,
"currency": "USD",
"taxIncluded": false,
"taxable": true
}
}

レスポンス(201 Created):

{
"id": "uuid-string",
"productId": "prod-123",
"title": "Blue Baseball Cap",
"description": "Premium baseball cap in blue color",
"sku": "BBC-BLUE",
"imageIds": ["img-456", "img-789"],
"price": {
"amount": 2999,
"currency": "USD",
"taxIncluded": false,
"taxable": true
},
"delFlg": 0,
"createdAt": "2024-01-01T00:00:00.000Z",
"updatedAt": "2024-01-01T00:00:00.000Z"
}

主な機能:

  • 必須タイトル: すべてのバリアントには識別用の説明的なタイトルが必要
  • 柔軟な価格設定: 金額、通貨、税設定を含むオプションの価格構造
  • 画像サポート: imageIds配列を介して既存の製品画像を参照可能
  • SKU管理: 在庫追跡のためのオプションの在庫管理単位
  • 親関連付け: バリアントを親製品に自動的に関連付け
  • データ正規化: APIレスポンスからMongoDB _idフィールドを削除
  • 自動生成フィールド: ID、タイムスタンプ、delFlgが自動的に管理される

認可:

  • 現在、管理者ユーザーのみに制限されています(checkIdentityType(['admin'])
  • TODO: 組織ベースのアクセス制御を追加
  • TODO: メール確認要件を追加

検証ルール:

  • titleは必須で、空でない文字列である必要があります
  • 他のすべてのフィールドはオプションです
  • imageIdsが提供されている場合は文字列の配列である必要があります
  • priceオブジェクトは提供されている場合、特定の構造に従う必要があります
  • 追加のプロパティは許可されません(厳密なスキーマ)

エラーレスポンス:

  • 400 Bad Request: 無効なリクエストボディまたは必須タイトルが不足しています
  • 401 Unauthorized: 認証が失敗しました
  • 403 Forbidden: 管理者以外のユーザーが作成を試行しています
  • 404 Not Found: 作成後に製品バリアントが見つかりませんでした(予期しないエラー)
  • 500 Internal Server Error: データベース操作が失敗しました

ハンドラープロセス:

  1. リクエストボディとパスパラメータを検証
  2. 自動生成されたフィールドでデータベースにバリアントを作成
  3. 作成されたバリアントを取得して作成の成功を確認
  4. レスポンスデータを正規化(_idを削除)
  5. 正規化されたバリアントデータで201 Createdを返す

ユースケース:

  • カラーバリエーションの追加(赤、青、緑のシャツ)
  • サイズバリエーション(S、M、L)
  • 素材バリエーション(綿、ポリエステル)
  • スタイルバリエーション(Vネック、クルーネック)
  • カスタム製品設定

createProductVariantBulkFeature

スキーマ検証とルーティング付き製品バリアント一括作成機能。

目的: 包括的な検証、正規化、エラー処理を含む単一の操作で複数の製品バリアントを作成します。

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';

// Direct usage:
app.use('/api', defService(features.createProductVariantBulkFeature));

// With database configuration:
app.use('/api', defService(
partial(features.createProductVariantBulkFeature, [
{ dataStores: { productVariants: db.collection('productVariants') } }
])
));

APIエンドポイント: POST /api/product/:productId/variants/bulk

リクエストボディ(バリアントの配列):

[
{
"title": "Small - Red",
"description": "Small size in red color",
"sku": "S-RED",
"price": {
"amount": 1999,
"currency": "USD"
},
"imageIds": ["img-456"],
"isActive": true
},
{
"title": "Medium - Blue",
"description": "Medium size in blue color",
"sku": "M-BLUE",
"price": {
"amount": 2099,
"currency": "USD"
},
"imageIds": ["img-789"],
"isActive": true
}
]

レスポンス (201 Created, 作成されたバリアントの配列):

[
{
"id": "uuid-1",
"productId": "prod-123",
"title": "Small - Red",
"description": "Small size in red color",
"sku": "S-RED",
"price": {
"amount": 1999,
"currency": "USD"
},
"imageIds": ["img-456"],
"isActive": true,
"createdAt": "2024-01-15T10:30:00Z",
"updatedAt": "2024-01-15T10:30:00Z"
},
{
"id": "uuid-2",
"productId": "prod-123",
"title": "Medium - Blue",
"description": "Medium size in blue color",
"sku": "M-BLUE",
"price": {
"amount": 2099,
"currency": "USD"
},
"imageIds": ["img-789"],
"isActive": true,
"createdAt": "2024-01-15T10:30:00Z",
"updatedAt": "2024-01-15T10:30:00Z"
}
]

主な機能:

  • バッチ効率: 単一のデータベース操作で複数のバリアントを作成
  • アトミック操作: すべてのバリアントが成功するか、操作全体が失敗
  • 包括的な検証: 配列全体と個々のバリアント要件を検証
  • エラー特異性: インデックス情報を含むバッチ書き込み失敗の詳細なエラー報告
  • データ正規化: APIレスポンスでの自動MongoDBフィールドクリーンアップ
  • サイズ制約: パフォーマンスのためにリクエストごとに1-100バリアントに制限

認可:

  • 現在、管理者ユーザーのみに制限されています(checkIdentityType(['admin'])
  • TODO: 組織ベースのアクセス制御を追加
  • TODO: メール確認要件を追加
  • TODO: 各バリアントの製品所有権検証を追加

検証ルール:

  • 配列は1〜100個のバリアントオブジェクトを含む必要があります
  • 各バリアントにはtitleフィールドが必要です
  • パスパラメータproductIdは必須です
  • 他のすべてのフィールドはオプションです
  • リクエストアイテムに追加のプロパティは許可されません
  • priceオブジェクトは提供されている場合、標準の価格設定構造に従う必要があります

エラーレスポンス:

  • 400 Bad Request: 無効なリクエストボディ、必須フィールドの不足、または制約違反
  • 401 Unauthorized: 認証が失敗しました
  • 403 Forbidden: 管理者以外のユーザーが一括作成を試行しています
  • 500 Internal Server Error: データベース操作が失敗したか、特定のインデックス情報を含む一括書き込みエラーが発生しました

ハンドラープロセス:

  1. 認証、パスパラメータ、リクエストボディ配列構造を検証
  2. 製品関連付けを含むすべてのバリアントの一括データベース挿入を実行
  3. 生成されたIDで作成されたバリアントを取得
  4. レスポンスデータを正規化(MongoDB _idフィールドを削除)
  5. 正規化されたバリアントデータの配列で201 Createdを返す

ユースケース:

  • 一括製品セットアップ: 新規製品のサイズ/カラーバリアントの初期セットアップ
  • カタログ移行: 外部システムからの製品バリアントのインポート
  • 季節的更新: 季節的な製品ラインの複数のバリアントの追加
  • 管理者操作: 大規模な製品カタログの効率的な管理

パフォーマンスの利点:

  • 複数のバリアントに対する単一のデータベーストランザクション
  • 個別のAPI呼び出しと比較してネットワークオーバーヘッドを削減
  • 大規模な製品管理操作に最適化

updateProductVariantBulkFeature

スキーマ検証とルーティング付き製品バリアント一括更新機能。

目的: 包括的な検証、データ正規化、エラー処理を含む単一の操作で複数の製品バリアントを更新します。

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';

// Direct usage:
app.use('/api', defService(features.updateProductVariantBulkFeature));

// With database configuration:
app.use('/api', defService(
partial(features.updateProductVariantBulkFeature, [
{ dataStores: { productVariants: db.collection('productVariants') } }
])
));

APIエンドポイント: PATCH /api/product/:productId/variants/bulk

リクエストボディ:

{
"ids": ["var-123", "var-456", "var-789"],
"data": {
"description": "Updated description for all variants",
"price": {
"amount": 2999,
"currency": "USD",
"taxIncluded": true,
"taxable": true
},
"sku": "UPDATED-SKU",
"title": "Updated Title",
"imageIds": ["img-456", "img-789"]
}
}

レスポンス(200 OK):

[
{
"id": "var-123",
"productId": "prod-123",
"title": "Updated Title",
"description": "Updated description for all variants",
"sku": "UPDATED-SKU",
"price": {
"amount": 2999,
"currency": "USD",
"taxIncluded": true,
"taxable": true
},
"imageIds": ["img-456", "img-789"],
"createdAt": "2024-01-15T10:30:00Z",
"updatedAt": "2024-01-16T14:20:00Z"
},
{
"id": "var-456",
"productId": "prod-123",
"title": "Updated Title",
"description": "Updated description for all variants",
"sku": "UPDATED-SKU",
"price": {
"amount": 2999,
"currency": "USD",
"taxIncluded": true,
"taxable": true
},
"imageIds": ["img-456", "img-789"],
"createdAt": "2024-01-15T10:30:00Z",
"updatedAt": "2024-01-16T14:20:00Z"
}
]

主な機能:

  • バッチ効率: 単一のデータベース操作で複数のバリアントを更新
  • アトミック操作: すべての更新が成功するか、操作全体が失敗
  • 包括的な検証: 配列全体と個々のバリアント要件を検証
  • エラー特異性: バッチ書き込み失敗の詳細なエラー報告
  • データ正規化: APIレスポンスでの自動MongoDBフィールドクリーンアップ
  • 柔軟な更新: 任意のバリアントフィールドの組み合わせを更新(部分更新をサポート)
  • サイズ制約: パフォーマンスのためにリクエストごとに1-100バリアントに制限

認可:

  • 現在、管理者ユーザーのみに制限されています(checkIdentityType(['admin'])
  • TODO: 組織ベースのアクセス制御を追加
  • TODO: メール確認要件を追加
  • TODO: 各バリアントの製品所有権検証を追加

検証ルール:

  • パスパラメータproductIdは必須です
  • リクエストボディはids配列(1〜100アイテム)とdataオブジェクトを含む必要があります
  • dataオブジェクト内のすべてのフィールドはオプションです(部分更新用)
  • priceオブジェクトは提供されている場合、標準の価格設定構造に従う必要があります
  • 画像IDが提供されている場合は有効な文字列である必要があります

エラーレスポンス:

  • 400 Bad Request: 無効なリクエストボディ、必須フィールドの不足、または制約違反
  • 401 Unauthorized: 認証が失敗しました
  • 403 Forbidden: 管理者以外のユーザーが一括更新を試行しています
  • 404 Not Found: 1つ以上の製品バリアントが見つかりませんでした
  • 500 Internal Server Error: データベース操作が失敗したか、一括書き込みエラーが発生しました

ハンドラープロセス:

  1. 認証、パスパラメータ、リクエストボディ配列構造を検証
  2. 指定されたすべてのバリアントの一括データベース更新を実行
  3. 生成されたIDで更新されたバリアントを取得
  4. レスポンスデータを正規化(MongoDB _idフィールドを削除)
  5. 正規化されたバリアントデータの配列で200 OKを返す

ユースケース:

  • 一括価格更新: 複数の製品バリアントの価格を同時に更新
  • カタログメンテナンス: 説明またはSKUの変更を複数のバリアントに一度に適用
  • 季節的調整: 季節的な製品ラインの価格、説明、または画像を変更
  • 在庫管理: 複数のバリアントの在庫レベルまたは可用性ステータスを更新
  • 管理者操作: 類似の更新を含む大規模な製品カタログの効率的な管理

データフロー:

  • 入力: 製品ID(パス)、バリアントID配列、更新データ
  • 検証: 認証、認可、データ構造の検証
  • データベース操作: $set操作を使用したMongoDB updateMany
  • レスポンス処理: データ正規化とフォーマット
  • 出力: 更新された正規化されたバリアントオブジェクトの配列

パフォーマンスに関する注意:

  • 効率的な一括操作のためにMongoDB updateManyを使用
  • アトミック性のための単一のデータベーストランザクション
  • 結果セットに適用されるデータ正規化
  • 高ボリュームのカタログ管理操作に適している

deleteProductVariantBulkFeature

スキーマ検証とルーティング付き製品バリアント一括削除機能。

目的: 包括的な検証、エラー処理、クリーンなレスポンスフォーマットを含む単一の操作で複数の製品バリアントを削除します。

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';

// Direct usage:
app.use('/api', defService(features.deleteProductVariantBulkFeature));

// With database configuration:
app.use('/api', defService(
partial(features.deleteProductVariantBulkFeature, [
{ dataStores: { productVariants: db.collection('productVariants') } }
])
));

APIエンドポイント: POST /api/product/:productId/variants/bulk-delete

リクエストボディ:

["var-123", "var-456", "var-789"]

レスポンス(204 No Content): 削除成功時の空のレスポンスボディ

主な機能:

  • バッチ効率: 単一のデータベース操作で複数のバリアントを削除
  • アトミック操作: すべての削除が成功するか、操作全体が失敗
  • 包括的な検証: 配列全体と個々のバリアント要件を検証
  • クリーンなレスポンス: 成功したバッチ削除に対して204 No Contentを返す
  • エラー特異性: バッチ書き込み失敗の詳細なエラー報告
  • サイズ制約: パフォーマンスのためにリクエストごとに1-100バリアントに制限

認可:

  • 現在、管理者ユーザーのみに制限されています(checkIdentityType(['admin'])
  • TODO: 組織ベースのアクセス制御を追加
  • TODO: メール確認要件を追加
  • TODO: 各バリアントの製品所有権検証を追加

検証ルール:

  • パスパラメータproductIdは必須です
  • リクエストボディは1〜100個のバリアントID文字列の配列である必要があります
  • リクエストボディに追加のプロパティは許可されません

エラーレスポンス:

  • 400 Bad Request: 無効なリクエストボディ、必須フィールドの不足、または制約違反
  • 401 Unauthorized: 認証が失敗しました
  • 403 Forbidden: 管理者以外のユーザーが一括削除を試行しています
  • 500 Internal Server Error: データベース操作が失敗したか、バリアントが削除されませんでした

ハンドラープロセス:

  1. 認証、パスパラメータ、リクエストボディ配列構造を検証
  2. 指定されたすべてのバリアントの一括データベース削除を実行
  3. 少なくとも1つのバリアントが削除されたことを検証
  4. 成功した一括削除時に204 No Contentを返す

ユースケース:

  • 一括クリーンアップ: 複数の廃止または中止された製品バリアントを削除
  • カタログ再構築: 製品ライン再編成中のバリアントの削除
  • データメンテナンス: 重複または無効なバリアントエントリのクリーンアップ
  • 管理者操作: 大規模な製品カタログの効率的な管理

データフロー:

  • 入力: 製品ID(パス)、バリアントID配列
  • 検証: 認証、認可、データ構造の検証
  • データベース操作: IDフィルタを使用したMongoDB deleteMany
  • レスポンス処理: 204レスポンス用の空のボディフォーマット
  • 出力: 空のレスポンスボディを持つ204 No Contentステータス

パフォーマンスに関する注意:

  • 効率的な一括操作のためにMongoDB deleteManyを使用
  • アトミック性のための単一のデータベーストランザクション
  • 最小限のレスポンスペイロード(204 No Content)
  • 高ボリュームのカタログクリーンアップ操作に適している

getProductVariantFeature

スキーマ検証とルーティング付き製品バリアント取得機能。

目的: 適切な検証と正規化を含む個別の製品バリアントの詳細を取得

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';

// Direct usage:
app.use('/api', defService(features.getProductVariantFeature));

// With database configuration:
app.use('/api', defService(
partial(features.getProductVariantFeature, [
{ dataStores: { productVariants: db.collection('productVariants') } }
])
));

APIエンドポイント: GET /api/products/:productId/variants/:productVariantId

レスポンス(200 OK):

{
"id": "uuid-string",
"productId": "prod-123",
"title": "Blue Baseball Cap",
"description": "Premium baseball cap in blue color",
"sku": "BBC-BLUE",
"imageIds": ["img-456", "img-789"],
"price": {
"amount": 2999,
"currency": "USD",
"taxIncluded": false,
"taxable": true
},
"delFlg": 0,
"createdAt": "2024-01-01T00:00:00.000Z",
"updatedAt": "2024-01-01T00:00:00.000Z"
}

主な機能:

  • 個別バリアント取得: 特定の製品バリアントの詳細情報を取得
  • 親製品スコープ: バリアントが指定された製品に属することを保証
  • データ正規化: APIレスポンスからMongoDB _idフィールドを削除
  • 認証必須: 有効な認証トークンが必要
  • 柔軟な認可: 現在、すべての認証済みユーザーに開放
  • 包括的なエラー処理: 異なる失敗シナリオのための特定のエラークラス

認可:

  • 認証のみが必要です(現在、ロール制限なし)
  • TODO: 組織ベースのアクセス制御を追加
  • TODO: メール確認要件を追加

検証ルール:

  • productIdは有効な文字列である必要があります(必須パスパラメータ)
  • productVariantIdは有効な文字列である必要があります(必須パスパラメータ)
  • バリアントは存在し、指定された製品に属している必要があります

エラーレスポンス:

  • 401 Unauthorized: 認証が失敗しました
  • 404 Not Found: 製品バリアントが見つからないか、指定された製品に属していません
  • 500 Internal Server Error: データベース操作が失敗しました

ハンドラープロセス:

  1. 認証とパスパラメータを検証
  2. 製品スコープ付きでデータベースから製品バリアントを取得
  3. レスポンスデータを正規化(_idを削除)
  4. 正規化されたバリアントデータで200 OKを返す

ユースケース:

  • 製品ページでの詳細なバリアント情報の表示
  • 特定のバリアント設定の管理者レビュー
  • 電子商取引のカート/チェックアウトでのバリアント選択
  • 在庫管理システム
  • バリアント比較と編集インターフェース

updateProductVariantFeature

スキーマ検証とルーティング付き製品バリアント更新機能。

目的: 部分更新サポートと検証を含む既存の製品バリアントデータを更新

構成:

  • Schema: updateProductVariantSchema - 必須パスパラメータ付きオプションバリアントフィールドを検証
  • Route: updateProductVariantRoute - PATCH /products/:productId/variants/:productVariantId 更新と正規化ハンドラー付き

使用例:

import { features } from '@nodeblocks/backend-sdk';

// Direct usage:
app.use('/api', defService(features.updateProductVariantFeature));

// With database configuration:
app.use('/api', defService(
partial(features.updateProductVariantFeature, [
{ dataStores: { productVariants: db.collection('productVariants') } }
])
));

APIエンドポイント: PATCH /api/products/:productId/variants/:productVariantId

リクエストボディ(すべてのフィールドはオプション):

{
"title": "Updated Title",
"description": "Updated description",
"sku": "UPDATED-SKU",
"imageIds": ["img-789", "img-101"],
"price": {
"amount": 2999,
"currency": "USD",
"taxIncluded": false,
"taxable": true
}
}

レスポンス(200 OK):

{
"id": "uuid-string",
"productId": "prod-123",
"title": "Updated Title",
"description": "Updated description",
"sku": "UPDATED-SKU",
"imageIds": ["img-789", "img-101"],
"price": {
"amount": 2999,
"currency": "USD",
"taxIncluded": false,
"taxable": true
},
"delFlg": 0,
"createdAt": "2024-01-01T00:00:00.000Z",
"updatedAt": "2024-01-01T00:00:00.000Z"
}

主な機能:

  • 部分更新: 変更したいフィールドのみを更新
  • 柔軟な価格設定: 個々の価格コンポーネント(金額、通貨、税設定)を更新
  • 画像管理: 画像参照を置き換えまたは変更
  • 検証: 厳密な検証により無効なデータを防止
  • アトミック操作: 適切なエラー処理を含むアトミックなデータベース更新
  • 監査証跡: 自動updatedAtタイムスタンプ管理
  • データ正規化: レスポンスからMongoDB _idフィールドを削除

認可:

  • 現在、管理者ユーザーのみに制限されています(checkIdentityType(['admin'])
  • TODO: 組織ベースのアクセス制御を追加
  • TODO: メール確認要件を追加

検証ルール:

  • パスパラメータproductIdproductVariantIdは必須です
  • リクエストボディフィールドはすべてオプションです(空のボディも許可)
  • バリアントは存在し、指定された製品に属している必要があります
  • 厳密なスキーマ検証(追加プロパティなし)

エラーレスポンス:

  • 400 Bad Request: 無効なリクエストボディまたはスキーマ検証の失敗
  • 401 Unauthorized: 認証が失敗しました
  • 403 Forbidden: 管理者以外のユーザーが更新を試行しています
  • 404 Not Found: 製品バリアントが見つかりませんでした
  • 500 Internal Server Error: データベース操作が失敗しました

ハンドラープロセス:

  1. 認証とパスパラメータを検証
  2. 提供されたフィールドのみでデータベース内の製品バリアントを更新
  3. 更新されたバリアントを取得して変更の成功を確認
  4. レスポンスデータを正規化(_idを削除)
  5. 正規化された更新されたバリアントデータで200 OKを返す

ユースケース:

  • 季節セールやプロモーションのための価格更新
  • 在庫調整(SKU変更)
  • コンテンツ更新(タイトル、説明の変更)
  • 画像ギャラリーの変更
  • 税設定の調整
  • 部分的なデータ修正

パフォーマンスに関する注意:

  • 効率的な部分更新のためにMongoDB $set演算子を使用
  • 変更されたドキュメントのupdatedAtタイムスタンプのみを更新
  • アトミックなデータベース操作によりデータの一貫性を確保

deleteProductVariantFeature

スキーマ検証とルーティング付き製品バリアント削除機能。

目的: 適切な検証とエラー処理を含むデータベースから製品バリアントを削除

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';

// Direct usage:
app.use('/api', defService(features.deleteProductVariantFeature));

// With database configuration:
app.use('/api', defService(
partial(features.deleteProductVariantFeature, [
{ dataStores: { productVariants: db.collection('productVariants') } }
])
));

APIエンドポイント: DELETE /api/products/:productId/variants/:productVariantId

レスポンス(204 No Content): 削除成功時の空のレスポンスボディ

主な機能:

  • 永続的な削除: データベースから製品バリアントを完全に削除
  • パスパラメータ検証: 製品IDとバリアントIDの両方が提供されることを保証
  • 存在確認: 削除前にバリアントの存在を確認
  • アトミック操作: データベース削除はアトミックで検証済み
  • 空のレスポンス: 成功した削除に対して204 No Contentを返す
  • 包括的なエラー処理: 異なる失敗シナリオのための特定のエラークラス

認可:

  • 現在、管理者ユーザーのみに制限されています(checkIdentityType(['admin'])
  • TODO: 組織ベースのアクセス制御を追加
  • TODO: メール確認要件を追加

検証ルール:

  • パスパラメータproductIdproductVariantIdは必須です
  • 削除するにはバリアントがデータベースに存在する必要があります
  • リクエストボディ検証なし(DELETE操作)

エラーレスポンス:

  • 401 Unauthorized: 認証が失敗しました
  • 403 Forbidden: 管理者以外のユーザーが削除を試行しています
  • 500 Internal Server Error: データベース操作が失敗したか、バリアントが見つかりませんでした

ハンドラープロセス:

  1. 認証とパスパラメータを検証
  2. IDでデータベースから製品バリアントを削除
  3. 削除が成功したことを確認(deletedCountをチェック)
  4. 空のレスポンスボディを正規化
  5. 削除成功時に204 No Contentを返す

ユースケース:

  • 廃止された製品バリアントの削除
  • テストまたはデモデータのクリーンアップ
  • 在庫問題のあるバリアントの削除
  • 管理データ管理
  • 製品カタログのメンテナンス

データ整合性に関する注意:

  • 削除は永続的で元に戻すことはできません
  • カスケード効果を考慮してください(バリアントを参照する注文、カート)
  • TODO: 製品が削除されたときに関連データのカスケード削除を追加

パフォーマンスに関する注意:

  • 効率的な単一ドキュメント削除のためにMongoDB deleteOneを使用
  • アトミック操作によりデータの一貫性を確保
  • 削除検証を超えた追加のクエリなし

findProductVariantsFeature

スキーマ検証とルーティング付き製品バリアント取得機能。

目的: ページネーションとデータ正規化を含む特定の製品の製品バリアントを一覧表示

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';

// Direct usage:
app.use('/api', defService(features.findProductVariantsFeature));

// With database configuration:
app.use('/api', defService(
partial(features.findProductVariantsFeature, [
{ dataStores: { productVariants: db.collection('productVariants') } }
])
));

APIエンドポイント: GET /api/products/:productId/variants

レスポンス(200 OK):

{
"data": [
{
"id": "string",
"productId": "string",
"title": "string",
"description": "string",
"sku": "string",
"imageIds": ["string"],
"price": {
"amount": "number",
"currency": "string"
},
"createdAt": "string",
"updatedAt": "string"
}
],
"metadata": {
"pagination": {
"page": 1,
"limit": 10,
"total": 25,
"totalPages": 3,
"hasNext": true,
"hasPrev": false
}
}
}

主な機能:

  • ページネーションサポート: 設定可能なページサイズとナビゲーションを含む組み込みページネーション
  • データ正規化: APIレスポンスからMongoDB _idフィールドの自動削除
  • 柔軟なフィルタリング: 拡張可能なクエリオプションで製品IDでバリアントをフィルタ
  • 包括的なレスポンス: データ配列とページネーションメタデータの両方を含む
  • エラー処理: データベース失敗と正規化問題のための特定のエラークラス

認可:

  • 現在、認証または認可は不要
  • TODO: 製品の存在検証を追加
  • TODO: 組織ベースのアクセス制御を追加

検証ルール:

  • パスパラメータproductIdは必須
  • オプションのページネーションパラメータ(pagelimitsortorder
  • ページネーションとソートのためのクエリパラメータ検証

エラーレスポンス:

  • 500 Internal Server Error: データベース操作が失敗しました

ハンドラープロセス:

  1. パスパラメータとオプションのクエリパラメータを検証
  2. 製品バリアント取得用のデータベースフィルタを構築
  3. ページネーション付きでMongoDBコレクションをクエリ
  4. _idフィールドを削除してドキュメントを正規化
  5. データとページネーションメタデータでレスポンスをフォーマット
  6. ページネーション付きのバリアントリストで200 OKを返す

ユースケース:

  • 電子商取引の製品ページでの製品バリアントの表示
  • 製品バリアントを管理するための管理者インターフェース
  • 製品のバリアント情報を取得するAPIコンシューマー
  • ページネーション付きの製品カタログ表示の構築

データフロー:

  • 入力: 製品IDとオプションのページネーションパラメータ
  • データベースクエリ: productIdフィルタを使用したMongoDB find操作
  • データ処理: ページネーションラッパー、ドキュメント正規化
  • 出力: バリアント配列とページネーションメタデータを含む構造化されたレスポンス

パフォーマンスに関する注意:

  • 効率的なクエリのためにカーソルを使用したMongoDB findを使用
  • 最適なパフォーマンスのためにデータベースレベルでページネーションを処理
  • 結果セットに適用されるドキュメント正規化
  • 高トラフィックの製品カタログ操作に適している

findProductsByOrganizationIdFeature

スキーマ検証とルーティング付き組織IDによる製品取得機能。

目的: ページネーション、画像正規化、適切な認証制御を含む特定の組織にスコープされた製品を取得します。

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';

// Direct usage:
app.use('/api', defService(features.findProductsByOrganizationIdFeature));

// With database and file storage configuration:
app.use('/api', defService(
partial(features.findProductsByOrganizationIdFeature, [
{ dataStores: db, fileStorageDriver }
])
));

APIエンドポイント: GET /api/products/organizations/:organizationId

リクエストパラメータ:

  • パスパラメータ: organizationId(文字列)- 組織識別子
  • クエリパラメータ: pagelimitsortorder(ページネーションオプション)

レスポンス(200 OK):

{
"data": [
{
"id": "prod-123",
"organizationId": "org-456",
"name": "Premium Widget",
"description": "High-quality widget for professionals",
"images": [
{
"id": "img-789",
"objectId": "abc123...",
"type": "image/jpeg",
"url": "https://storage.googleapis.com/bucket/abc123..."
}
],
"createdAt": "2024-01-15T10:30:00Z",
"updatedAt": "2024-01-15T10:30:00Z"
}
],
"metadata": {
"pagination": {
"page": 1,
"limit": 10,
"total": 25,
"totalPages": 3,
"hasNext": true,
"hasPrev": false
}
}
}

主な機能:

  • 組織スコープ: マルチテナントサポートのために製品を組織IDでフィルタ
  • 画像正規化: ファイルストレージドライバーを使用した製品画像の自動URL生成
  • ページネーションサポート: 設定可能なページサイズとナビゲーションを含む組み込みページネーション
  • データ正規化: MongoDB _idフィールドを削除し、生成されたURLでデータを強化
  • ロールベースアクセス: 組織メンバーシップ(所有者、管理者、またはメンバーロール)が必要

認可:

  • 認証が必要です(isAuthenticated
  • 組織メンバーシップが必要です(hasOrgRole(['owner', 'admin', 'member'])
  • TODO: メール確認要件を追加

検証ルール:

  • organizationIdは有効な文字列である必要があります(必須パスパラメータ)
  • ユーザーは指定された組織にアクセスできる必要があります
  • オプションのページネーションパラメータ(pagelimitsortorder

エラーレスポンス:

  • 401 Unauthorized: 認証が失敗しました
  • 403 Forbidden: ユーザーが組織にアクセスできません
  • 500 Internal Server Error: データベース操作が失敗したか、ファイルストレージエラーが発生しました

ハンドラープロセス:

  1. 認証と組織アクセスを検証
  2. 製品取得用の組織固有のフィルタを構築
  3. ページネーションとソート付きで製品をクエリ
  4. 署名付きURLで製品画像を正規化
  5. データ配列とページネーションメタデータでレスポンスをフォーマット
  6. ページネーション付きの製品リストで200 OKを返す

ユースケース:

  • マルチテナントアプリケーションでの組織固有の製品カタログ
  • 組織内の製品を管理するための管理者ダッシュボード
  • 特定のビジネスエンティティの製品を取得するAPIコンシューマー
  • 組織スコープの電子商取引インターフェースの構築

パフォーマンスに関する注意:

  • 効率的なクエリのために組織フィルタリングを使用したMongoDB findを使用
  • 最適なパフォーマンスのためにデータベースレベルでページネーションを処理
  • 画像URL生成はメディアリッチな製品に処理オーバーヘッドを追加
  • 組織スコープの製品カタログ操作に適している

getProductLikersFeature

スキーマ検証とルーティング付き製品フォロワー取得機能。

目的: ページネーション、アバター正規化、適切な認証制御を含む特定の製品をいいねしたユーザーを取得します。

構成:

使用例:

import { features } from '@nodeblocks/backend-sdk';

// Direct usage:
app.use('/api', defService(features.getProductLikersFeature));

// With database and file storage configuration:
app.use('/api', defService(
partial(features.getProductLikersFeature, [
{ dataStores: db, fileStorageDriver }
])
));

APIエンドポイント: GET /api/products/:productId/likers

リクエストパラメータ:

  • パスパラメータ: productId(文字列)- いいねユーザーを見つけるための製品識別子
  • クエリパラメータ: pagelimitsortorder(ページネーションオプション)

レスポンス(200 OK):

{
"data": [
{
"id": "user-123",
"name": "John Doe",
"avatar": {
"id": "avatar-456",
"objectId": "abc123...",
"type": "image/jpeg",
"url": "https://storage.googleapis.com/bucket/abc123..."
}
}
],
"metadata": {
"pagination": {
"page": 1,
"limit": 10,
"total": 25,
"totalPages": 3,
"hasNext": true,
"hasPrev": false
}
}
}

主な機能:

  • 製品いいねユーザー取得: 特定の製品をいいねしたすべてのユーザーを見つける
  • アバター正規化: ファイルストレージドライバーを使用したユーザーアバターの自動URL生成
  • ページネーションサポート: 設定可能なページサイズとナビゲーションを含む組み込みページネーション
  • データ正規化: MongoDB _idフィールドを削除し、生成されたURLでデータを強化
  • 管理者専用アクセス: プライバシーとセキュリティのために管理者ユーザーに制限

認可:

  • 認証が必要です(isAuthenticated
  • 管理者ユーザーのみに制限されています(checkIdentityType(['admin'])
  • TODO: レート制限付きの製品所有者アクセスまたはパブリックアクセスの実装を検討

検証ルール:

  • productIdは有効な文字列である必要があります(必須パスパラメータ)
  • 製品はデータベースに存在する必要があります
  • ユーザーは管理者権限を持っている必要があります

エラーレスポンス:

  • 401 Unauthorized: 認証が失敗しました
  • 403 Forbidden: 管理者以外のユーザーがいいねユーザーを表示しようとしています
  • 404 Not Found: 製品が見つかりませんでした
  • 500 Internal Server Error: データベース操作が失敗したか、ファイルストレージエラーが発生しました

ハンドラープロセス:

  1. 認証と管理者権限を検証
  2. 製品を取得して存在を確認
  3. 製品をいいねしたユーザーを見つけるためのフィルタを構築
  4. ページネーション付きでユーザーコレクションをクエリ
  5. 署名付きURLでユーザーアバターを正規化
  6. ユーザーデータとページネーションメタデータでレスポンスをフォーマット
  7. ページネーション付きのいいねユーザーリストで200 OKを返す

ユースケース:

  • 製品エンゲージメントメトリクスを表示する管理者ダッシュボード
  • どの製品が最も人気があるかを理解するための分析
  • オーディエンスへの製品所有者の洞察
  • いいね数やプロフィールを表示するソーシャル機能

パフォーマンスに関する注意:

  • 効率的な配列クエリのためにMongoDB $elemMatchを使用
  • 最適なパフォーマンスのためにデータベースレベルでページネーションを処理
  • アバターURL生成はユーザーリッチな結果に処理オーバーヘッドを追加
  • 管理者分析と製品管理操作に適している

🔗 関連ドキュメント