Smithyプロジェクト
Smithyは、サービスとそれらが交換するデータを記述するためのインターフェース定義言語です。Smithyプロジェクトジェネレーターは、Smithyモデルを含むプロジェクトを作成します。
Smithyプロジェクトには2種類あります:
- Service (
--type=service) — サービスとその操作を定義するモデル。これはts#api --framework=smithyジェネレーターがTypeScript実装と一緒に作成するものです。 - Shape library (
--type=shapes) — 再利用可能なシェイプを定義するが、サービスは定義しないモデル。シェイプライブラリをSmithyプロジェクトに接続することで、各プロジェクトで定義を重複させるのではなく、プロジェクト間でシェイプを共有できます。
Smithyプロジェクトの生成
Section titled “Smithyプロジェクトの生成”- インストール Nx Console VSCode Plugin まだインストールしていない場合
- VSCodeでNxコンソールを開く
- クリック
Generate (UI)"Common Nx Commands"セクションで - 検索
@aws/nx-plugin - smithy#project - 必須パラメータを入力
- name: my-shapes
- クリック
Generate
pnpm nx g @aws/nx-plugin:smithy#project --name=my-shapesyarn nx g @aws/nx-plugin:smithy#project --name=my-shapesnpx nx g @aws/nx-plugin:smithy#project --name=my-shapesbunx nx g @aws/nx-plugin:smithy#project --name=my-shapes変更されるファイルを確認するためにドライランを実行することもできます
pnpm nx g @aws/nx-plugin:smithy#project --name=my-shapes --dry-runyarn nx g @aws/nx-plugin:smithy#project --name=my-shapes --dry-runnpx nx g @aws/nx-plugin:smithy#project --name=my-shapes --dry-runbunx nx g @aws/nx-plugin:smithy#project --name=my-shapes --dry-run| パラメータ | 型 | デフォルト | 説明 |
|---|---|---|---|
| name 必須 | string | - | Smithyプロジェクト名 |
| type | service | shapes | service | 作成するSmithyプロジェクトのタイプ。service(実装の準備が整ったサービスシェイプを持つモデル)とshapes(複数のSmithyプロジェクト間で共有される再利用可能なシェイプのライブラリ)から選択します。 |
| serviceName | string | - | Smithyサービスの名前。デフォルトでは指定された名前を使用します。シェイプライブラリには適用されません。 |
| namespace | string | - | Smithy APIの名前空間。デフォルトではモノレポのスコープを使用します。 |
| directory | string | packages | Smithyプロジェクトが配置される親ディレクトリ。 |
| subDirectory | string | - | Smithyプロジェクトが配置されるサブディレクトリ。デフォルトではプロジェクト名になります。 |
| preferInstallDependencies | boolean | true | ジェネレーター実行後に依存関係のインストールを優先するかどうか。複数のジェネレーターをバッチ処理する際にインストールを延期する場合はfalseに設定します(後続のジェネレーターがNxプロジェクトグラフを計算できるよう、必要に応じてインストールは実行されます)。最後に一度だけインストールします。 |
ジェネレーター出力
Section titled “ジェネレーター出力”シェイプライブラリ
Section titled “シェイプライブラリ”Directorymy-shapes
Directorysrc
- main.smithy 共有シェイプ定義
- smithy-build.json Smithyビルド設定
- build.Dockerfile モデルをビルドして検証
- project.json プロジェクト設定とビルドターゲット
シェイプライブラリはシェイプのみを定義します:
$version: "2.0"
namespace com.example
structure Customer { @required id: String
name: String email: String}シェイプライブラリにはサービスがないため、そのsmithy-build.jsonはコード生成を設定しません — ビルドするとモデルを検証し、dist/<my-shapes>/build/model/model.jsonに単一のJSONモデルファイルとして組み立てます。
Directorymy-service
Directorysrc
- main.smithy サービス定義
Directoryoperations
- echo.smithy 操作の例
- smithy-build.json コード生成を含むSmithyビルド設定
- build.Dockerfile モデル、OpenAPI仕様、TypeScript Server SDKをビルド
- project.json プロジェクト設定とビルドターゲット
サービスモデルは、サービスシェイプとそれが公開する操作を定義します:
$version: "2.0"
namespace com.example
use aws.protocols#restJson1
@title("MyService")@restJson1service MyService { version: "1.0.0" operations: [ Echo ]}サービスプロジェクトをビルドすると、OpenAPI仕様とTypeScript Server SDKがdist/<my-service>/build/に生成されます。
SmithyプロジェクトはDockerを使用してビルドされ、Smithy CLIを実行してモデルを検証します:
pnpm nx build my-shapesyarn nx build my-shapesnpx nx build my-shapesbunx nx build my-shapesシェイプライブラリへの依存
Section titled “シェイプライブラリへの依存”シェイプライブラリをビルドすると、組み立てられたモデルがdist/<my-shapes>/build/model/model.jsonに書き込まれます。この単一ファイルには、ライブラリが定義するすべてのシェイプと、それが依存するすべてのシェイプが含まれているため、コンシューマーは直接参照するライブラリのみを宣言すればよいことになります。
別のSmithyプロジェクトからシェイプライブラリに依存するには、コンシューマープロジェクトに3つの変更を加えます:
-
Smithyプロジェクトはコンテナ内でビルドされ、ビルドには名前付きビルドコンテキストとしてワークスペースルートが与えられます。コンシューマープロジェクトの
build.Dockerfileに、独自のソースがコピーされる場所と並んでCOPYを追加します:# Copy project filesCOPY smithy-build.json .COPY src srcCOPY --from=workspace dist/packages/my-shapes/build/model/model.json deps/my-shapes.json -
コピーしたファイルをコンシューマープロジェクトの
smithy-build.jsonのimportsに追加します:{"version": "1.0","sources": ["src/"],"imports": ["deps/my-shapes.json"],...} -
ライブラリの
buildターゲットを、コンシューマープロジェクトのproject.json内のcompileターゲットの依存関係として追加し、コンシューマーがビルドする前にモデルが存在するようにします:{"targets": {"compile": {"dependsOn": ["@my-scope/my-shapes:build"],...}}}
これで、モデルはuseでライブラリのシェイプを参照できるようになります:
$version: "2.0"
namespace com.example.api
use com.example.shared#Customer
structure GetCustomerOutput { @required customer: Customer}シェイプライブラリは、同じ方法で他のシェイプライブラリに依存できます。各ライブラリのビルドされたモデルには既に独自の依存関係が含まれているため、直接参照するライブラリに対してのみこれらの手順を繰り返す必要があります。複数のパスから到達するライブラリは一度だけ解決されます — Smithyは重複しているが同等のシェイプ定義を無視します。