@aws/nx-plugin | Blog

v1.0.0 リリース

Tue, 08 Sep 2026 00:00:00 GMT

Nx Plugin for AWS が v1.0.0 に到達したことを発表できることを嬉しく思います！最初のリリース以来、本番プロジェクトを自信を持って開始できるツールキットの構築に取り組んできましたが、1.0 はそのマイルストーンです。

いくつかのハイライト: ジェネレーターが冪等になり、再実行しても常に安全でコードを上書きしません。nx migrate @aws/nx-plugin が完全にサポートされ、バージョンを上げるにつれて、上流で行った改善がワークスペースに流れ込みます。新しい init ジェネレーターにより、既存の Nx または非 Nx リポジトリでプラグインを採用できます。ジェネレーター全体で CDK と並んで Terraform がサポートされ、新しい DynamoDB とリレーショナルデータベースのジェネレーター、デフォルトで AgentCore Runtime にデプロイされるエージェントと MCP サーバー、新しい AgentCore Gateway ジェネレーター、そしてローカル開発用の単一の dev ターゲットがあります。ジェネレーターの名前とオプションが標準化され、ツールチェーンは Nx 23.2、ESM、Biome に移行しました。セキュリティのデフォルトも強化され、WAF、Cognito 脅威保護、強制 CSP、API アクセスログ、イメージスキャンが含まれています。

完全なローンチアナウンスについては、AWS Open Source ブログをご覧ください。

これまでに貢献し、問題を報告し、フィードバックをくださったすべての方に感謝します — 私たちはまだ始まったばかりです。いつものように、次に何を見たいかディスカッションを投稿するか、問題を報告してお知らせください！

AWS PDKからの移行

Mon, 07 Sep 2026 00:00:00 GMT

このガイドでは、AWS PDKプロジェクトをNx Plugin for AWSに移行する例を説明し、このトピックに関する一般的なガイダンスを提供します。

Nx Plugin for AWSへの移行により、PDKと比較して以下のメリットが得られます：

より高速なビルド
より使いやすい（UIとCLI）
Vibe-codingフレンドリー（MCPサーバーをお試しください！）
より最新のテクノロジー
ローカルAPIとウェブサイト開発
より多くの制御（ユースケースに合わせて提供されたファイルを変更可能）
その他多数！

プロジェクトを移行する際には、多くのニュアンスと考慮事項があります。このガイドは簡単な例を対象としており、お客様のプロジェクトに必要な手順が欠けている可能性があります。

このガイドでは、新しいワークスペースを作成し、PDKプロジェクトから新しいプロジェクトに部品をコピーするアプローチを採用しています。異なる方法で移行する必要がある場合、またはPDKからNx Plugin for AWSへの移行に関する質問がある場合は、GitHubディスカッションでお問い合わせください！

また、PDKの一部の機能には正確な同等物がないことにも注意してください。これらのヒント/アイデアについては、FAQセクションを参照してください。

移行例：ショッピングリストアプリケーション

このガイドでは、PDKチュートリアルのショッピングリストアプリケーションを移行対象プロジェクトとして使用します。ご自身で実際に試す場合は、そのチュートリアルの手順に従って対象プロジェクトを作成してください。

ショッピングリストアプリケーションは、以下のPDKプロジェクトタイプで構成されています：

MonorepoTsProject
TypeSafeApiProject
CloudscapeReactTsWebsiteProject
InfrastructureTsProject

ワークスペースの作成

まず、新しいプロジェクト用の新しいワークスペースを作成します。インプレース移行よりも極端ですが、このアプローチにより最もクリーンな最終結果が得られます。Nxワークスペースの作成は、PDKのMonorepoTsProjectの使用と同等です：

Create your workspace@aws/nx-workspace@1.0.0

$ pnpm create @aws/nx-workspace@1.0.0 shopping-list --iac=cdk

$ yarn create @aws/nx-workspace@1.0.0 shopping-list --iac=cdk

$ npm create @aws/nx-workspace@1.0.0 -- shopping-list --iac=cdk

$ bun create @aws/nx-workspace@1.0.0 shopping-list --iac=cdk

このコマンドで作成されたshopping-listディレクトリをお気に入りのIDEで開きます。

APIの移行

The TypeSafeApiProject used in the shopping list application made use of:

Smithy as the modelling language
TypeScript for implementing operations
TypeScript hook generation for integrating with a react website

We can therefore use the ts#smithy-api generator to provide equivalent functionality.

Generate a TypeScript Smithy API

Run the ts#api generator with framework set to smithy to set up your api project in packages/api:

Run this generator@aws/nx-plugin:ts#api

CLI
VSCode

$ pnpm nx g @aws/nx-plugin:ts#api --name=api --framework=smithy --namespace=com.aws --auth=iam --no-interactive

$ yarn nx g @aws/nx-plugin:ts#api --name=api --framework=smithy --namespace=com.aws --auth=iam --no-interactive

$ npx nx g @aws/nx-plugin:ts#api --name=api --framework=smithy --namespace=com.aws --auth=iam --no-interactive

$ bunx nx g @aws/nx-plugin:ts#api --name=api --framework=smithy --namespace=com.aws --auth=iam --no-interactive

Install the Nx Console VSCode Plugin if you haven't already
Open the Nx Console in VSCode
Click Generate (UI) in the "Common Nx Commands" section
Search for @aws/nx-plugin - ts#api
Fill in the required parameters
- name: api
- framework: smithy
- namespace: com.aws
- auth: iam
Click Generate

You will notice this generates a model project, as well as a backend project. The model project contains your Smithy model, and backend contains your server implementation.

The backend uses the Smithy Server Generator for TypeScript. We will explore this further below.

Migrate the Smithy Model

Now that we have the basic structure for our Smithy API project, we can migrate the model:

Delete the generated example Smithy files in packages/api/model/src
Copy your model from the PDK project’s packages/api/model/src/main/smithy directory into your new project’s packages/api/model/src directory.
Update the service name and namespace in smithy-build.json to match the PDK application:
smithy-build.json
```
"plugins": {
    "openapi": {
      "service": "com.aws#MyApi",
      ...
```

Update the service in main.smithy to add the ValidationException error, which is required when using the Smithy TypeScript Server SDK.

main.smithy

use smithy.framework#ValidationException

/// My Shopping List API
@restJson1
service MyApi {
    version: "1.0"
    operations: [
        GetShoppingLists
        PutShoppingList
        DeleteShoppingList
    ]
    errors: [
        BadRequestError
        NotAuthorizedError
        InternalFailureError
        ValidationException
    ]
}

Add an extensions.smithy file to packages/api/model/src where we will define a trait that provides pagination information to the generated client:

extensions.smithy

$version: "2"
namespace com.aws

use smithy.openapi#specificationExtension

@trait
@specificationExtension(as: "x-cursor")
structure cursor {
    inputToken: String
    enabled: Boolean
}

Add the new @cursor trait to the GetShoppingLists operation in get-shopping-lists.smithy:

operations/get-shopping-lists.smithy

@readonly
@http(method: "GET", uri: "/shopping-list")
@paginated(inputToken: "nextToken", outputToken: "nextToken", pageSize: "pageSize", items: "shoppingLists")
@cursor(inputToken: "nextToken")
@handler(language: "typescript")
operation GetShoppingLists {
    input := with [PaginatedInputMixin] {
        @httpQuery("shoppingListId")
        shoppingListId: ShoppingListId
    }

Any @paginated operations should also use @cursor if you’re using the client generator provided by the Nx Plugin for AWS (via the api-connection generator).

Finally, remove the @handler trait from all operations as this isn’t supported by the Nx Plugin for AWS. Using ts#smithy-api, we don’t need the auto-generated lambda function CDK constructs and bundling targets generated by this trait, as we use a single bundle for all lambda functions.

At this point, let’s run a build to check our model changes and ensure we have some generated server code to work with. There will be some failures in the backend project (@shopping-list/api) but we’ll address those next.

pnpm build

yarn build

npm run build

bun build

Migrate the Lambda Handlers

You can consider the api/backend project as somewhat equivalent to Type Safe API’s api/handlers/typescript project.

One of the main differences between Type Safe API and the ts#smithy-api generator is that handlers are implemented using the Smithy Server Generator for TypeScript, rather than Type Safe API’s own generated handler wrappers (found in the api/generated/typescript/runtime project).

The shopping list application’s lambda handlers rely on the @aws-sdk/client-dynamodb package, so let’s install that into the @shopping-list/api project:

pnpm add @aws-sdk/client-dynamodb --filter api

yarn workspace @shopping-list/api add @aws-sdk/client-dynamodb

npm install --legacy-peer-deps @aws-sdk/client-dynamodb -w packages/api

bun add @aws-sdk/client-dynamodb --cwd packages/api

Then, let’s copy the handlers/typescript/src/dynamo-client.ts file from the PDK project to backend/src/operations so it’s available for our handlers.

The ts#smithy-api generator scaffolds an example Echo operation. Since we removed this from our model, delete the corresponding handler in backend/src/operations/echo.ts. We’ll register our migrated operations in service.ts further below.

To migrate the handlers, you can follow these general steps:

Copy the handler from your PDK project’s packages/api/handlers/typescript/src directory to your new project’s packages/api/backend/src/operations directory.

Remove my-api-typescript-runtime imports and instead import the operation type from the generated TypeScript Server SDK, as well as the ServiceContext for example:

import {
  deleteShoppingListHandler,
  DeleteShoppingListChainedHandlerFunction,
  INTERCEPTORS,
  Response,
  LoggingInterceptor,
} from 'myapi-typescript-runtime';
import { DeleteShoppingList as DeleteShoppingListOperation } from '../generated/ssdk/index.js';
import { ServiceContext } from '../context.js';

Delete the handler wrapper export

export const handler = deleteShoppingListHandler(
  ...INTERCEPTORS,
  deleteShoppingList,
);

Update the signature for your operation handler to use the SSDK:

export const deleteShoppingList: DeleteShoppingListChainedHandlerFunction = async (request) => {
export const DeleteShoppingList: DeleteShoppingListOperation<ServiceContext> = async (input, ctx) => {

Replace usage of the LoggingInterceptor with ctx.logger. (Also applies to metrics and tracing interceptors):
```
LoggingInterceptor.getLogger(request).info('...');
ctx.logger.info('...');
```
Update references to input parameters. Since the SSDK provides types that match your Smithy model exactly (rather than grouping path/query/header parameters separately to the body parameter), update any input references accordingly:
```
const shoppingListId = request.input.requestParameters.shoppingListId;
const shoppingListId = input.shoppingListId;
```

Remove use of Response. We instead just return plain objects in the SSDK.

return Response.success({ shoppingListId });
return { shoppingListId };

We also no longer throw or return Response, instead we throw the SSDK’s generated errors:

throw Response.badRequest({ message: 'oh no' });
return Response.badRequest({ message: 'oh no' });
import { BadRequestError } from '../generated/ssdk/index.js';
throw new BadRequestError({ message: 'oh no' });

Update any imports to use ESM syntax, namely adding the .js extension to relative imports.

Add the operation to service.ts

service.ts

import { ServiceContext } from './context.js';
import { MyApiService } from './generated/ssdk/index.js';
import { DeleteShoppingList } from './operations/delete-shopping-list.js';
import { GetShoppingLists } from './operations/get-shopping-lists.js';
import { PutShoppingList } from './operations/put-shopping-list.js';

// Register operations to the service here
export const Service: MyApiService<ServiceContext> = {
  PutShoppingList,
  GetShoppingLists,
  DeleteShoppingList,
};

Click here for full before/after examples for the three shopping list operations from the tutorial

We generated the Smithy API project with the name api initially as we wanted it to be added to packages/api for consistency with the PDK project. Since our Smithy API now defines service MyApi instead of service Api, we need to update any instances of getApiServiceHandler with getMyApiServiceHandler.

Make this change to handler.ts:

packages/api/backend/src/handler.ts

 import { getApiServiceHandler } from './generated/ssdk/index.js';
 import { getMyApiServiceHandler } from './generated/ssdk/index.js';

process.env.POWERTOOLS_METRICS_NAMESPACE = 'Api';
process.env.POWERTOOLS_SERVICE_NAME = 'Api';

const tracer = new Tracer();
const logger = new Logger();
const metrics = new Metrics();

 const serviceHandler = getApiServiceHandler(Service);
 const serviceHandler = getMyApiServiceHandler(Service);

And to local-server.ts:

packages/api/backend/src/local-server.ts

import { getApiServiceHandler } from './generated/ssdk/index.js';
import { getMyApiServiceHandler } from './generated/ssdk/index.js';

const PORT = 3001;

const tracer = new Tracer();
const logger = new Logger();
const metrics = new Metrics();

const serviceHandler = getApiServiceHandler(Service);
const serviceHandler = getMyApiServiceHandler(Service);

Additionally, update packages/api/backend/project.json and update metadata.apiName to my-api:

packages/api/backend/project.json

  "metadata": {
    "generator": "ts#smithy-api",
    "apiName": "api",
    "apiName": "my-api",
    "auth": "iam",
    "modelProject": "@shopping-list/api-model",
    "iac": "cdk",
    "ports": [3001]
  },

Verify with a Build

We can now build the project to check that the migration has worked so far:

pnpm build

yarn build

npm run build

bun build

ウェブサイトの移行

The CloudscapeReactTsWebsiteProject used in the shopping list application configured a React website with CloudScape and Cognito authentication built in.

This project type leveraged create-react-app, which is now deprecated. For migrating the website in this guide, we will use the ts#website generator, which uses more modern and supported technologies, namely Vite.

As part of the migration, we will also move from PDK’s configured React Router to TanStack Router, which adds additional type-safety to website routing.

Generate a React Website

Run the ts#website generator with framework set to react to set up your website project in packages/website. Since the shopping list application is built with CloudScape components, we also set ux to cloudscape (the default is shadcn):

Run this generator@aws/nx-plugin:ts#website

CLI
VSCode

$ pnpm nx g @aws/nx-plugin:ts#website --name=website --framework=react --ux=cloudscape --no-interactive

$ yarn nx g @aws/nx-plugin:ts#website --name=website --framework=react --ux=cloudscape --no-interactive

$ npx nx g @aws/nx-plugin:ts#website --name=website --framework=react --ux=cloudscape --no-interactive

$ bunx nx g @aws/nx-plugin:ts#website --name=website --framework=react --ux=cloudscape --no-interactive

Install the Nx Console VSCode Plugin if you haven't already
Open the Nx Console in VSCode
Click Generate (UI) in the "Common Nx Commands" section
Search for @aws/nx-plugin - ts#website
Fill in the required parameters
- name: website
- framework: react
- ux: cloudscape
Click Generate

Add Cognito Authentication

The React website generator above doesn’t bundle cognito authentication by default like CloudscapeReactTsWebsiteProject, instead it’s added explicitly via the ts#website#auth generator.

Run this generator@aws/nx-plugin:ts#website#auth

CLI
VSCode

$ pnpm nx g @aws/nx-plugin:ts#website#auth --project=website --cognitoDomain=shopping-list --no-interactive

$ yarn nx g @aws/nx-plugin:ts#website#auth --project=website --cognitoDomain=shopping-list --no-interactive

$ npx nx g @aws/nx-plugin:ts#website#auth --project=website --cognitoDomain=shopping-list --no-interactive

$ bunx nx g @aws/nx-plugin:ts#website#auth --project=website --cognitoDomain=shopping-list --no-interactive

Install the Nx Console VSCode Plugin if you haven't already
Open the Nx Console in VSCode
Click Generate (UI) in the "Common Nx Commands" section
Search for @aws/nx-plugin - ts#website#auth
Fill in the required parameters
- project: website
- cognitoDomain: shopping-list
Click Generate

This adds React components which manage the appropriate redirects to ensure users log in using the Cognito hosted UI. This also adds a CDK construct to deploy the Cognito resources in packages/common/constructs, called UserIdentity.

The PDK CloudscapeReactTsWebsiteProject relied on @aws-northstar/ui to provide Cognito login components in-app. If you would prefer to use this approach instead of moving to the hosted UI, you can replace the generated packages/common/constructs/src/core/user-identity.ts with the implementation from PDK, replacing the constructs from @aws-cdk/aws-cognito-identitypool-alpha with those vended by aws-cdk-lib, and make sure to set the relevant values in RuntimeConfig:

RuntimeConfig.ensure(this).set('connection', 'cognitoProps', {
  region: Stack.of(this).region,
  identityPoolId: this.identityPool.identityPoolId,
  userPoolId: this.userPool.userPoolId,
  userPoolWebClientId: this.userPoolClient.userPoolClientId,
});

You can then reuse the Auth component from your CloudscapeReactTsWebsiteProject.

Connect the Website to the API

In PDK you could pass the vended Projen projects to one another to trigger integration code to be vended. This was used in the shopping list application to configure the website to be able to integrate with the API.

With the Nx Plugin for AWS, API integration is supported via the connection generator. Next, we use this generator so that our website can invoke our Smithy API:

Run this generator@aws/nx-plugin:connection

CLI
VSCode

$ pnpm nx g @aws/nx-plugin:connection --sourceProject=website --targetProject=api --no-interactive

$ yarn nx g @aws/nx-plugin:connection --sourceProject=website --targetProject=api --no-interactive

$ npx nx g @aws/nx-plugin:connection --sourceProject=website --targetProject=api --no-interactive

$ bunx nx g @aws/nx-plugin:connection --sourceProject=website --targetProject=api --no-interactive

Install the Nx Console VSCode Plugin if you haven't already
Open the Nx Console in VSCode
Click Generate (UI) in the "Common Nx Commands" section
Search for @aws/nx-plugin - connection
Fill in the required parameters
- sourceProject: website
- targetProject: api
Click Generate

This generates the necessary client providers and build targets for your website to call your API via a generated TypeScript client.

Add AWS Northstar Dependency

The CloudscapeReactTsWebsiteProject automatically included a dependency on @aws-northstar/ui which is used in our shopping list application, so we add it to the @shopping-list/website project:

pnpm add @aws-northstar/ui --filter website

yarn workspace @shopping-list/website add @aws-northstar/ui

npm install --legacy-peer-deps @aws-northstar/ui -w packages/website

bun add @aws-northstar/ui --cwd packages/website

@aws-northstar/ui bundles a code editor component which depends on ace-builds, using a webpack-specific import that Vite cannot resolve. Since our shopping list application doesn’t use this component, we exclude it from the bundle by adding it to the external configuration within the existing build options in packages/website/vite.config.mts:

packages/website/vite.config.mts

  build: {
    outDir: '../../dist/packages/website/bundle',
    emptyOutDir: true,
    reportCompressedSize: true,
    commonjsOptions: {
      transformMixedEsModules: true,
    },
    rollupOptions: {
      external: ['ace-builds/webpack-resolver'],
    },
  },

Move the Components and Pages

The shopping list application has one component called CreateItem, and two pages, ShoppingList and ShoppingLists. We’ll migrate these to the new website, making a few adjustments since we’re using TanStack Router and the Nx Plugin for AWS TypeScript client code generator.

Copy packages/website/src/components/CreateItem/index.tsx from the PDK project into the exact same location in the new project.
Copy packages/website/src/pages/ShoppingLists/index.tsx to packages/website/src/routes/index.tsx, since ShoppingLists is our home page and we use file-based routing with TanStack router.
Copy packages/website/src/pages/ShoppingList/index.tsx to packages/website/src/routes/$shoppingListId.tsx, since ShoppingList was the page we want to show on the /:shoppingListId route.

Note that you’ll now have some build errors visible in your IDE, we’ll need to make a few more changes to fit within the new framework, outlined below.

Migrate from React Router to TanStack Router

Since we’re using file-based routing, we can use the website local development server to manage automatically generating route configuration.

Let’s start the local website server:

pnpm dev

yarn dev

npm run dev

bun dev

You’ll see some errors, but the local website server should start on port 4200, as well as the local Smithy API server on port 3001.

Follow the below steps in both routes/index.tsx and routes/$shoppingListId.tsx to migrate to TanStack Router:

Add createFileRoute to register each route:

routes/index.tsx
routes/$shoppingListId.tsx

import { createFileRoute } from "@tanstack/react-router";
...
export default ShoppingLists;
export const Route = createFileRoute('/')({
  component: ShoppingLists,
});

import { createFileRoute } from "@tanstack/react-router";
...
export default ShoppingList;
export const Route = createFileRoute('/$shoppingListId')({
  component: ShoppingList,
});

After you save the file, you’ll notice that type errors with call to createFileRoute have gone.

Replace the useNavigate hook.

Update the import:

import { useNavigate } from 'react-router-dom';
import { useNavigate } from '@tanstack/react-router';

Update calls to the navigate method (returned by useNavigate) to pass in the type-safe routes:

navigate(`/${cell.shoppingListId}`);
navigate({
  to: '/$shoppingListId',
  params: { shoppingListId: cell.shoppingListId },
});

Replace the useParams hook.

Remove the import:

import { useParams } from 'react-router-dom';

Update calls to useParams with the hook provided by the Route created above. These are now type-safe!

const { shoppingListId } = useParams();
const { shoppingListId } = Route.useParams();

Fix Component Imports

Since our route files aren’t as deeply nested in the file tree as they were in our PDK project, we need to fix the import for CreateItem in both routes/index.tsx and routes/$shoppingListId.tsx:

import CreateItem from "../../components/CreateItem";
import CreateItem from "../components/CreateItem";

The AppLayoutContext is also vended in a slightly different location in our new project:

import { AppLayoutContext } from "../../layouts/App";
import { AppLayoutContext } from "../components/AppLayout";

Migrate to use the new Generated TypeScript Client

We’re getting closer now! Next, we need to migrate to use the TypeScript client vended by the Nx Plugin for AWS, which has a few improvements compared to Type Safe API. To achieve this, follow the below steps

Import the new generated client and types instead of the old, for example:
```
import {
  ShoppingList,
  usePutShoppingList,
  useDeleteShoppingList,
  useGetShoppingLists,
} from "myapi-typescript-react-query-hooks";
import { ShoppingList } from "../generated/my-api/types.gen";
import { useMyApi } from "../hooks/useMyApi";
import { useInfiniteQuery, useMutation } from "@tanstack/react-query";
```
Note that routes/$shoppingListId.tsx imports the ShoppingList type as _ShoppingList - in that file we should do the same, but again importing from types.gen.

Note also we import the relevant hooks directly from @tanstack/react-query, since the generated client provides methods to generate options for TanStack query hooks, rather than hook wrappers.

Instantiate the new TanStack Query hooks, for example:

const getShoppingLists = useGetShoppingLists({ pageSize: PAGE_SIZE });
const putShoppingList = usePutShoppingList();
const deleteShoppingList = useDeleteShoppingList();
const api = useMyApi();
const getShoppingLists = useInfiniteQuery(
  api.getShoppingLists.infiniteQueryOptions(
    { pageSize: PAGE_SIZE },
    { getNextPageParam: (p) => p.nextToken },
  ),
);
const putShoppingList = useMutation(api.putShoppingList.mutationOptions());
const deleteShoppingList = useMutation(
  api.deleteShoppingList.mutationOptions(),
);

Remove the wrapper <operation>RequestContent for calls to operations which accept parameters in the request body:
```
await putShoppingList.mutateAsync({
  putShoppingListRequestContent: {
    name: item,
  },
});
```

There was also a minor bug in the shopping list application’s pages/ShoppingList/index.tsx where it was not using optional chaining correctly. Let’s fix this too to avoid a lint error when we run our final build:

const shoppingList: _ShoppingList | undefined =
    getShoppingLists.data?.pages[0].shoppingLists[0]!;
    getShoppingLists.data?.pages?.[0]?.shoppingLists?.[0];

And likewise update the references which assumed it’s defined:

name: shoppingList.name,
shoppingListId: shoppingList.shoppingListId,
name: shoppingList?.name ?? 'my list',
shoppingListId: shoppingList?.shoppingListId,

Migrate from TanStack Query v4 to v5

There are a few errors left to fix due to differences between TanStack Query v4 (used by PDK) and v5 which the connection generator added:

Replace isLoading with isPending for mutations, for example:
```
putShoppingList.isLoading
putShoppingList.isPending
```
The shopping list application made use of the InfiniteQueryTable from @aws-northstar/ui which expects a type from TanStack Query v4. This actually works with infinite queries from v5, so we can just suppress the type error:
```
<InfiniteQueryTable
  query={getShoppingLists}
  query={getShoppingLists as any}
```

Visit the Local Website

You can now visit the local website at http://localhost:4200/

The website should load up now that everything’s been migrated! Since the only infrastructure that the shopping list application relies on besides API, Website and Identity is the DynamoDB table - if you’ve got a DynamoDB table named shopping_list in-region, and local AWS credentials which can access it, the website will be fully functional!

If not, that’s ok, we’ll migrate the infrastructure next.

Click here for full before/after examples for the two shopping list pages from the tutorial

インフラストラクチャの移行

The last project we need to migrate for our shopping list application is the InfrastructureTsProject. This is a TypeScript CDK project, for which the Nx Plugin for AWS equivalent is the ts#infra generator.

As well as the Projen projects, PDK also vended CDK constructs which these projects depend on. We will migrate the shopping list application from these CDK constructs too, in favour of the ones generated by the Nx Plugin for AWS.

Generate a TypeScript CDK Infrastructure Project

Run the ts#infra generator to set up your infrastructure project in packages/infra:

Run this generator@aws/nx-plugin:ts#infra

CLI
VSCode

$ pnpm nx g @aws/nx-plugin:ts#infra --name=infra --no-interactive

$ yarn nx g @aws/nx-plugin:ts#infra --name=infra --no-interactive

$ npx nx g @aws/nx-plugin:ts#infra --name=infra --no-interactive

$ bunx nx g @aws/nx-plugin:ts#infra --name=infra --no-interactive

Install the Nx Console VSCode Plugin if you haven't already
Open the Nx Console in VSCode
Click Generate (UI) in the "Common Nx Commands" section
Search for @aws/nx-plugin - ts#infra
Fill in the required parameters
- name: infra
Click Generate

Migrate the CDK Infrastructure

The PDK shopping list application instantiated the following constructs within the CDK application stack:

DatabaseConstruct for the DynamoDB table storing shopping lists
UserIdentity for Cognito resources, imported directly from PDK
MyApi for deploying the Smithy API, which used the generated TypeScript CDK construct with type-safe integrations, depending on PDK’s TypeSafeRestApi CDK construct under the hood.
Website for deploying the Website, wrapping PDK’s StaticWebsite CDK construct.

Next, we will migrate each of these to the new project.

Copy the Application Stack

Copy packages/infra/src/stacks/application-stack.ts from the PDK shopping list application to the exact same location in your new project. You’ll see some TypeScript errors which we’ll address below.

Copy the Database Construct

The PDK shopping list application had a Database construct in packages/src/constructs/database.ts. Copy this to the exact same location in your new project.

Since the Nx Plugin for AWS uses Checkov for security tests which is a little stricter than PDK Nag, we also need to add some suppressions:

constructs/database.ts

import { suppressRules } from '@shopping-list/common-constructs';
...
suppressRules(
  this.shoppingListTable,
  ['CKV_AWS_28', 'CKV_AWS_119'],
  'Backup and KMS key not required for this project',
);

In application-stack.ts, update the import for the DatabaseConstruct to use ESM syntax:

stacks/application-stack.ts

import { DatabaseConstruct } from '../constructs/database';
import { DatabaseConstruct } from '../constructs/database.js';

Migrate the UserIdentity Construct

The UserIdentity construct can generally be swapped out without changes by adjusting the imports.

import { UserIdentity } from "@aws/pdk/identity";
import { UserIdentity } from '@shopping-list/common-constructs';
...
const userIdentity = new UserIdentity(this, `${id}UserIdentity`);

Note that the underlying constructs used by the new UserIdentity construct are vended directly from aws-cdk-lib, where PDK used @aws-cdk/aws-cognito-identitypool-alpha.

Migrate the API Construct

The PDK shopping list application had a construct in constructs/apis/myapi.ts which instantiated a CDK construct which Type Safe API generated from your Smithy model.

As well as this construct, since the PDK project used the @handler trait, generated lambda function CDK constructs were also generated.

Like Type Safe API, the Nx Plugin for AWS provides type-safety for integrations based on your Smithy model, however it’s achieved in a much simpler and more flexible way. Instead of generating an entire CDK construct at build time, only minimal “metadata” is generated, which the packages/common/constructs/src/app/apis/api.ts uses in a generic fashion. You can learn more about how to use the construct in the ts#smithy-api generator guide.

Follow the below steps:

Instantiate the Api construct in application-stack.ts

stacks/application-stack.ts

import { MyApi } from "../constructs/apis/myapi";
import { Api } from '@shopping-list/common-constructs';
...
const myapi = new MyApi(this, "MyApi", {
  databaseConstruct,
  userIdentity,
});
const api = new Api(this, 'MyApi', {
  integrations: Api.defaultIntegrations(this).build(),
});

Notice here we use Api.defaultIntegrations(this).build() - the default behaviour is to create a lambda function for each operation in our API, which is the same behaviour we had in myapi.ts.

Grant permissions for the lambda functions to access the DynamoDB table.

In the PDK shopping list application, the DatabaseConsruct was passed into MyApi, and it managed adding the relevant permissions to each generated function construct. We’ll do this directly in the application-stack.ts file by accessing the Api construct’s type-safe integrations property:
stacks/application-stack.ts
```
// Grant our lambda functions scoped access to call Dynamo
databaseConstruct.shoppingListTable.grantReadData(
  api.integrations.getShoppingLists.handler,
);
[
  api.integrations.putShoppingList.handler,
  api.integrations.deleteShoppingList.handler,
].forEach((f) => databaseConstruct.shoppingListTable.grantWriteData(f));
```
Grant permissions for authenticated users to invoke the API.

Within the PDK application’s myapi.ts, authenticated users were also granted IAM permissions to invoke the API. We will do the equivalent in application-stack.ts:
stacks/application-stack.ts
```
api.grantInvokeAccess(userIdentity.identityPool.authenticatedRole);
```

Migrate the Website Construct

Finally, we add the Website construct from packages/common/constructs/src/app/static-websites/website.ts to application-stack.ts, since this is the equivalent of the PDK shopping list application’s packages/infra/src/constructs/websites/website.ts.

import { Website } from "../constructs/websites/website";
import { Website } from '@shopping-list/common-constructs';
...
new Website(this, "Website", {
  userIdentity,
  myapi,
});
new Website(this, 'Website');

Notice that we don’t pass the identity or API to the website - runtime config is managed within each construct vended by the Nx Plugin for AWS, where UserIdentity and Api register the necessary values, and Website manages deploying it to /runtime-config.json on your static website.

Let’s build the project now that we’ve migrated all the relevant parts of the codebase to our new project.

pnpm build

yarn build

npm run build

bun build

デプロイ

Now we’ve got our fully migrated codebase, we can look at deploying it. There are two paths we can take at this point.

All-New Resources (Simple)

The simplest approach is to treat this as a completely new application, meaning we’ll “start again” with a fresh DynamoDB table and Cognito User Pool - losing all users and their shopping lists. For this approach, simply:

Delete the DynamoDB table named shopping_list

Deploy the new application:

pnpm nx deploy-sandbox infra

yarn nx deploy-sandbox infra

npx nx deploy-sandbox infra

bunx nx deploy-sandbox infra

🎉 And we’re done! 🎉

Migrate Existing Stateful Resources with no Outage (More Complex)

In reality, it’s more likely that you will want to migrate existing AWS resources so that they are managed by the new codebase, while avoiding any downtime for your customers.

For our shopping list application, the stateful resources we care about are the DynamoDB table which contains our users’ shopping lists, and the User Pool which contains the details of all of our registered users. Our high level plan will be to retain these two key resources and move them such that they’re managed by our new stack, then to update DNS to point to our new website (and API if exposed to customers).

Update your new application to reference the existing resources you wish to retain.

For the shopping list application, we do this for the DynamoDB table

constructs/database.ts

this.shoppingListTable = new Table(this, 'ShoppingList', {
  ...
this.shoppingListTable = Table.fromTableName(
  this,
  'ShoppingList',
  'shopping_list',
);

And for the Cognito User Pool

packages/common/constructs/src/core/user-identity.ts

this.userPool = this.createUserPool(mfa, mfaSecondFactor);
this.userPool = UserPool.fromUserPoolId(
  this,
  'UserPool',
  '<your-user-pool-id>',
);

Build and deploy the new application:

pnpm build

yarn build

npm run build

bun build

pnpm nx deploy-sandbox infra

yarn nx deploy-sandbox infra

npx nx deploy-sandbox infra

bunx nx deploy-sandbox infra

Now we have our new application stood up referencing the existing resources, not yet taking any traffic.

Perform full integration testing to ensure the new application works as expected. For the shopping list application, load the website and check you can sign in and create, view, edit and delete shopping lists.

Revert the changes which reference the existing resources in your new application, but do not deploy them yet.

constructs/database.ts

this.shoppingListTable = new Table(this, 'ShoppingList', {
  ...
this.shoppingListTable = Table.fromTableName(
  this,
  'ShoppingList',
  'shopping_list',
);

And for the Cognito User Pool

packages/common/constructs/src/core/user-identity.ts

this.userPool = this.createUserPool(mfa, mfaSecondFactor);
this.userPool = UserPool.fromUserPoolId(
  this,
  'UserPool',
  '<your-user-pool-id>',
);

And then run a build

pnpm build

yarn build

npm run build

bun build

Use cdk import in your new application’s packages/infra folder to see which resources we’ll be prompted to import.

New Application

cd packages/infra
pnpm exec cdk import shopping-list-infra-sandbox/Application --force

Step through the prompts by hitting enter. The import will fail because the resources are managed by another stack - this is expected, we just did this step to confirm which resources we’ll need to retain. You’ll see output like this:

shopping-list-infra-sandbox/Application/ApplicationUserIdentity/UserPool/smsRole/Resource (AWS::IAM::Role): enter RoleName (empty to skip)
shopping-list-infra-sandbox/Application/ApplicationUserIdentity/UserPool/Resource (AWS::Cognito::UserPool): enter UserPoolId (empty to skip)
shopping-list-infra-sandbox/Application/Database/ShoppingList/Resource (AWS::DynamoDB::Table): import with TableName=shopping_list (y/n) y

This tells us that there are actually 3 resources we’ll need to import into our new stack.

Update your old PDK project to set RemovalPolicy to RETAIN for the resources discovered from the previous step. At the time of writing this is the default for both the User Pool and the DynamoDB table, but we need to update it for the SMS Role we discovered above:

application-stack.ts

const userIdentity = new UserIdentity(this, `${id}UserIdentity`, {
  userPool,
});

const smsRole = userIdentity.userPool.node.findAll().filter(
  c => CfnResource.isCfnResource(c) &&
    c.node.path.includes('/smsRole/'))[0] as CfnResource;
smsRole.applyRemovalPolicy(RemovalPolicy.RETAIN);

Deploy your PDK project so that the removal policies are applied
PDK Application
```
cd packages/infra
npx projen deploy
```
Take a look at the CloudFormation console and record the values you were prompted for in the above cdk import step
1. The User Pool ID, eg us-west-2_XXXXX
2. The SMS Role Name, eg infra-sandbox-UserIdentityUserPoolsmsRoleXXXXXX

Update your PDK project to reference the existing resources instead of creating them

constructs/database.ts

this.shoppingListTable = new Table(this, 'ShoppingList', {
  ...
this.shoppingListTable = Table.fromTableName(
  this,
  'ShoppingList',
  'shopping_list',
);

And for the Cognito User Pool

application-stack.ts

const userPool = UserPool.fromUserPoolId(
  this,
  'UserPool',
  '<your-user-pool-id>',
);
const userIdentity = new UserIdentity(this, `${id}UserIdentity`, {
  // PDK construct accepts UserPool not IUserPool, but this still works!
  userPool: userPool as any,
});

Deploy your PDK project again, this will mean the resources are no longer managed by our PDK project’s CloudFormation stack.
PDK Application
```
cd packages/infra
npx projen deploy
```
Now that the resources are unmanaged, we can run cdk import in our new application to actually perform the import:
New Application
```
cd packages/infra
pnpm exec cdk import shopping-list-infra-sandbox/Application --force
```
Enter the values when prompted, the import should complete successfully.
Deploy the new application again to make sure that any changes to these existing resources (now managed by your new stack) are made:
- pnpm
- yarn
- npm
- bun
pnpm nx deploy-sandbox infra
yarn nx deploy-sandbox infra
npx nx deploy-sandbox infra
bunx nx deploy-sandbox infra
Perform a full test of your new application again
Update DNS records to point to your new Website (and API if required).

We recommend a gradual approach using Route53 Weighted Routing, whereby a fraction of requests are directed to the new application to begin with. As you monitor your metrics you can increase the weight for the new application until no traffic is sent to your old PDK application.

If you don’t have any DNS and used the auto-generated domains for the website and API, you can always look at proxying requests (eg via a CloudFront HTTP origin or API Gateway HTTP integration(s)).
Monitor PDK application metrics to ensure there is no traffic, and finally destroy the old CloudFormation stack:
```
cd packages/infra
npx projen destroy
```

That was quite a bit more involved, but we successfully migrated our users seamlessly to the new application! 🎉🎉🎉

We now have the new benefits of the Nx Plugin for AWS over PDK:

Faster builds
Local API development support
A vibe-coding friendly codebase (try our MCP server!)
More intuitive type-safe client/server code
And more!

よくある質問

このセクションでは、上記の移行例でカバーされていないPDKの機能に関するガイダンスを提供します。

PDKから移行する際の一般的なルールとして、PDK Monorepoとの類似性を考慮して、Nx Workspaceでプロジェクトを開始することをお勧めします。また、新しいタイプを構築する際の基本要素として、当社のジェネレーターを使用することをお勧めします。

Create your workspace@aws/nx-workspace

$ pnpm create @aws/nx-workspace my-project

$ yarn create @aws/nx-workspace my-project

$ npm create @aws/nx-workspace -- my-project

$ bun create @aws/nx-workspace my-project

CDK Graph

CDK Graph builds graphs of your connected CDK resources, and provided two plugins:

Diagram Plugin

The CDK Graph Diagram Plugin generates AWS architecture diagrams from your CDK infrastructure.

For a similar deterministic approach a viable alternative is CDK-Dia.

With the advancements in Generative AI, many foundation models are capabile of creating high-quality diagrams from your CDK infrastructure. We recommend trying out the AWS Diagram MCP Server. Check out this blog post for a walkthrough.

Threat Composer Plugin

The CDK Graph Threat Composer Plugin generates a starter Threat Composer threat model from your CDK code.

This plugin worked by simply filtering a base threat model containing example threats, and filtering them based on the resources your stack made use of.

If you’re interested in these specific example threats you can copy and filter the base threat model, or use it as context to help a foundation model generate a similar one.

AWS Arch

AWS Arch provided mappings between CloudFormation resources and their associated architecture icons for CDK Graph above.

Refer to the AWS Architecture Icons page for icon related resources. Diagrams also provides a way to build diagrams as code.

If you were using this directly, consider forking the project and taking ownership!

Pipeline

PDK provided a PDKPipelineProject which set up a CDK infrastructure project and made use of a CDK construct which wrapped some CDK Pipelines resources.

To migrate from this, you can use the CDK Pipelines constructs directly. In practice however it is likely more straightforward to use something like GitHub actions or GitLab CI/CD, where you define CDK Stages and run the deploy command for the appropiate stage directly.

PDK Nag

PDK Nag wraps CDK Nag, and provides a set of rules specific to building prototypes.

To migrate from PDK Nag, use CDK Nag directly. If you need the same set of rules you can create a “pack” of your own by following the documentation here.

Type Safe API

The most commonly used components from Type Safe API are covered in the example migration above, however there are other features, for which migration details are below.

APIs Modelled with OpenAPI

The Nx Plugin for AWS supports APIs modelled in Smithy, but not those modelled directly OpenAPI. The ts#smithy-api generator is a good starting point which you can then modify. You can define your OpenAPI specification in the model project’s src folder instead of Smithy, and update the model project’s compile target to run your desired code generation tool for clients/servers. If your desired tools are on NPM, you can install them as dev dependencies to your Nx workspace and call them directly as Nx build targets.

Backend

For type-safe backends modelled in OpenAPI, you can consider using one of the OpenAPI Generator Server Generators. These won’t generate directly for AWS Lambda, but you can use the AWS Lambda Web Adapter to bridge the gap for a lot of them.

Client

For TypeScript clients, you can use the ts#website generator and connection generator with an example ts#api (with framework set to smithy) to see how clients are generated and integrated with a website. This configures build targets which generate clients by invoking our open-api#ts-client or open-api#ts-hooks generators. You can use these generators yourself by pointing them at your OpenAPI Specification.

For other languages, you can also see if any of the generators from OpenAPI Generator fit your needs.

You can also build a bespoke generator by using the ts#nx-generator generator. Refer that generator’s documentation for details about how to generate code from OpenAPI. You can use the templates from the Nx Plugin for AWS as a starting point. You can also even refer to the templates from the PDK codebase for more inspiration, noting that the data structure the templates operate on is a little different to the Nx Plugin for AWS.

APIs Modelled with TypeSpec

For TypeSpec, the above section for OpenAPI applies too. You can start by generating a ts#smithy-api, install the TypeSpec compiler and OpenAPI packages to your Nx workspace, and update the model project’s compile target to run tsp compile instead, ensuring it outputs an OpenAPI specification to the dist directory.

Backend

The recommended approach would be to use the TypeSpec HTTP Server generator for JavaScript to generate your server code, since this works directly on your TypeSpec model.

You can use the AWS Lambda Web Adapter for running the generated server on AWS Lambda.

You can also use any of the above OpenAPI options.

Client

TypeSpec has its own code generators for clients in all three of Type Safe API’s supported languages:

The above OpenAPI section also applies since TypeSpec can compile to OpenAPI.

APIs Modelled with Smithy

The above example migration outlines migrating to use the ts#smithy-api generator. This section covers the options for Python and Java backends and clients.

Backend

The Smithy code generator for Java. This has a Java server generator as well as an adapter to run the generated Java server on AWS Lambda.

Smithy doesn’t have a server generator for Python, so you will need to go via OpenAPI. Refer to the above section regarding APIs Modelled with OpenAPI for potential options.

Client

The Smithy code generator for Java. This has a Java client generator.

For Python clients, you can check out Smithy Python.

For TypeScript, check out Smithy TypeScript, or use the same approach we’ve taken in ts#smithy-api by going via OpenAPI (we opted for this as it gives us consistency between tRPC, FastAPI and Smithy APIs via TanStack Query hooks).

Smithy Shape Library

Type Safe API provided a Projen project type named SmithyShapeLibraryProject which configured a project which contained Smithy models which could be reused by multiple Smithy-based APIs.

The equivalent is the smithy#project generator with type set to shapes:

Run this generator@aws/nx-plugin:smithy#project

CLI
VSCode

$ pnpm nx g @aws/nx-plugin:smithy#project --name=my-shapes --type=shapes

$ yarn nx g @aws/nx-plugin:smithy#project --name=my-shapes --type=shapes

$ npx nx g @aws/nx-plugin:smithy#project --name=my-shapes --type=shapes

$ bunx nx g @aws/nx-plugin:smithy#project --name=my-shapes --type=shapes

Install the Nx Console VSCode Plugin if you haven't already
Open the Nx Console in VSCode
Click Generate (UI) in the "Common Nx Commands" section
Search for @aws/nx-plugin - smithy#project
Fill in the required parameters
- name: my-shapes
- type: shapes
Click Generate

Move the shapes from your SmithyShapeLibraryProject into the generated project’s src folder, then refer to the Smithy project guide for how to wire the library up as a dependency of your API’s model.

Interceptors

Type Safe API provided the following default interceptors:

Logging, tracing and metrics interceptors using Powertools for AWS Lambda
Try-catch interceptor for handling uncaught exceptions
CORS interceptor for returning CORS headers

The ts#smithy-api generator instruments logging, tracing and metrics with Powertools for AWS Lambda using Middy. The behaviour of the try-catch interceptor is built in to the Smithy TypeScript SSDK, and CORS headers are added in handler.ts.

For logging, tracing and metrics interceptors in any language, use Powertools for AWS Lambda directly.

For migrating custom interceptors, we recommend using the following libraries:

TypeScript - Middy
Python - Powertools for AWS Lambda Middleware Factory
Java - Instrument methods before/after your business logic using aws-lambda-java-libs for a simple approach, or consider AspectJ for building your middleware as annotations.

Documentation Generation

Type Safe API provided documentation generation using Redocly CLI. This is very easy to add to an existing project once you’ve migrated it as above.

Install the Redocly CLI

pnpm add -Dw @redocly/cli

yarn add -D @redocly/cli

npm install --legacy-peer-deps -D @redocly/cli

bun add -D @redocly/cli

Add a documentation generation target to your model project using redocly build-docs, for example:

model/project.json

{
  ...
  "documentation": {
    "cache": true,
    "outputs": ["{workspaceRoot}/dist/{projectRoot}/documentation"],
    "executor": "nx:run-commands",
    "options": {
      "command": "redocly build-docs dist/packages/api/model/build/openapi/openapi.json --output=dist/packages/api/model/documentation/index.html",
      "cwd": "{workspaceRoot}"
    },
    "dependsOn": ["compile"]
  }
}

You can also consider the OpenAPI Generator documentation generators.

Mock Integrations

Type Safe API generated mocks for you within its generated infrastructure package.

You can move to JSON Schema Faker which can create the mock data based on JSON Schemas. This can work directly on an OpenAPI specification, and has a CLI which you could run as part of your model project build.

You can update your CDK infrastructure to read the JSON file output by JSON Schema Faker, and return the appropriate API Gateway MockIntegration for an integration, based on the generated metadata.gen.ts (assuming you used the ts#smithy-api generator).

Mixed Language Backends

Type Safe API supported implementing APIs with a mixture of different languages in the backend. This can also be achieved by providing “overrides” to integrations when instantiating your API construct in CDK:

application-stack.ts

const pythonLambdaHandler = new Function(this, 'PythonImplementation', {
  runtime: Runtime.PYTHON_3_12,
  ...
});

new Api(this, 'MyApi', {
  integrations: Api.defaultIntegrations(this)
    .withOverrides({
      echo: {
        integration: new LambdaIntegration(pythonLambdaHandler),
        handler: pythonLambdaHandler,
      },
    })
    .build(),
});

You will need to “stub” your service/router for your service to compile if using the ts#smithy-api and the TypeScript Server SDK, eg:

service.ts

export const Service: ApiService<ServiceContext> = {
  ...
  Echo: () => { throw new Error(`Not Implemented`); },
};

Input Validation

Type Safe API added native API Gateway validation for request bodies based on your OpenAPI specification since it used the SpecRestApi construct under the hood.

With the ts#smithy-api generator, validation is performed by the Server SDK itself. This is the same for most server generators.

If you would like to implement native API Gateway validation, you could do so by modifying packages/common/constructs/src/core/api/rest-api.ts to read the relevant JSON schema for each operation’s request body from your OpenAPI specification.

WebSocket APIs

Unfortunately there is no straightforward migration path for Type Safe API’s websocket API using API Gateway and Lambda with model-driven API development. However, this section of the guide aims to at least offer a few ideas.

Consider using AsyncAPI to model your API instead of OpenAPI or TypeSpec since this is designed to handle asynchronous APIs. The AsyncAPI NodeJS Template can generate a Node websocket backend which you could host on ECS for example.

You can also consider AppSync Events for infrastructure, and use Powertools. This blog post is worth a read!

Another option is to use GraphQL APIs with websockets on AppSync, for which we have a GitHub issue you can +1! Refer to the AppSync developer guide for details and links to sample projects.

You can also consider rolling your own code generators which interpret the same vendor extensions as Type Safe API. Refer to the APIs Modelled with OpenAPI section for details around building custom OpenAPI-based code generators. You can find the templates Type Safe API uses for API Gateway Websocket API Lambda handlers here, and the client here.

You can also consider migrating to use the ts#trpc-api generator to use tRPC. At the time of writing we don’t yet have support for subscriptions/streaming but if this is something you need do add a +1 to our GitHub issue tracking this.

Smithy is protocol agnostic, but does not yet have support for the Websocket protocol, refer to this GitHub issue tracking support.

PythonまたはJavaでのインフラストラクチャ

PDK supported CDK infrastructure written in Python and Java. We do not support this in the Nx Plugin for AWS at the time of writing.

The recommended path forward would be to either migrate your CDK infrastructure to TypeScript, or to use our generators and migrate the common constructs package to your desired language. You can use Generative AI to accelerate these kinds of migrations, for example Kiro CLI. You can have an AI agent iterate on the migration until the synthesized CloudFormation templates are identical.

The same applies for Type Safe API’s generated infrastructure in Python or Java - you can translate the generic rest-api.ts construct from the common constructs package, and implement your own simple metadata generator for your target language (refer to the APIs Modelled with OpenAPI section).

You can use the py#project generator for a base Python project to add your CDK code to (and move over your cdk.json file, adding relevant targets). You can use Nx’s @nx/gradle plugin for Java projects, or @jnxplus/nx-maven for Maven.

Projenの使用

PDK was built on top of Projen. Projen and Nx Generators have fairly fundamental differences meaning that while it is technically possible to combine them it is likely an anti-pattern. Projen manages project files as code such that they cannot be modified directly, whereas Nx generators vend project files once and then code can be freely modified.

If you would like to continue to use Projen, you can implement your desired Projen project types yourself. To follow patterns from the Nx Plugin for AWS, you can run our generators or examine their source code on GitHub to see how your desired project types are constructed, and implement the relevant parts using Projen’s primitives.

Nx Plugin for AWS MCP Serverの紹介

Mon, 26 May 2025 00:00:00 GMT

急速に進化するソフトウェア開発の環境において、AIアシスタントは私たちのコーディングの旅における貴重な協力者となっています。多くの開発者は、私たちが親しみを込めて「バイブコーディング」と呼ぶものを受け入れています。これは、人間の創造性とAIの支援との協調的なダンスです。新たに登場した実践と同様に、エキサイティングな利点と注目すべき課題の両方が伴います。この投稿では、AWSの製品とサービスを使用する際のAI支援開発体験を強化する Nx Plugin for AWS MCP Server を紹介します。

バイブコーディングの台頭

バイブコーディング、つまりAIアシスタントと協力してソフトウェアを構築する実践は、多くの組織がソフトウェア開発にアプローチする方法を変革しました。構築したいものを説明すると、AIアシスタントがコードとテストの記述、ビルドコマンドの実行、そして大小のタスクを完了するための協調的な反復を通じて、あなたのビジョンを実現するのを支援します。

この協調的なアプローチは開発サイクルを大幅に加速しました。以前は手動で記述するのに数時間かかっていた複雑な実装が、多くの場合数分で完了できるようになりました。

バイブコーディングの課題

その利点にもかかわらず、バイブコーディングにはフローを妨げ、フラストレーションにつながる落とし穴があります。AIツールはプロジェクト全体で一貫性のないパターンを生成する可能性があり、これは後々メンテナンスの頭痛の種となる可能性があります。具体的なガイダンスがなければ、AIは経験豊富な開発者が自然に組み込むであろう重要なAWS固有のベストプラクティスやセキュリティの考慮事項を見逃す可能性があります。

明確なプロジェクト構造がなければ、AI支援コードは整理されず、メンテナンスが困難になる可能性があります。AIは、すでに確立されたソリューションがある問題に対してカスタム実装を作成し、不必要に車輪の再発明をする可能性があります。

これらの課題は、特に単一のフレームワークの範囲内だけでなく、相互接続するさまざまなAWSサービスを扱う場合に、技術的負債、セキュリティの脆弱性、フラストレーションにつながる可能性があります。

Nx Plugin for AWS

Nx Plugin for AWS は、Nxモノレポツールを使用してAWSアプリケーションを構築するための構造化された基盤を提供します。白紙のキャンバスから始める代わりに、プラグインはプロジェクト組織のための一貫したフレームワークを提供します。

プラグインは、一般的なプロジェクトタイプのジェネレーターを通じて一貫したプロジェクトスキャフォールディングを保証し、コードベース全体の構造的整合性を維持します。AWSのベストプラクティスに従う事前設定されたテンプレートを組み込み、開発者が一般的な落とし穴やセキュリティの問題を回避するのに役立ちます。統合されたツールは、AWSアプリケーションのビルド、テスト、デプロイのための組み込みコマンドを提供し、ローカル開発サーバーを通じて開発ワークフローを合理化します。さらに、複雑なプロジェクトのためのNxの強力な依存関係管理を活用し、モノレポ管理を簡素化します。

この構造を提供することで、Nx Plugin for AWS はAIアシスタントに作業するための明確な構造を与えます。パターンをゼロから発明するのではなく、AIアシスタントは確立された規約に従うことができ、より一貫性があり保守可能なコードベースにつながります。

MCP ServerでAIを強化

Model Context Protocol (MCP) は、AIアシスタントが外部ツールやリソースと対話できるようにするオープンスタンダードです。Nx Plugin for AWS MCP server は、Nx Plugin for AWS に関する専門知識でAIアシスタントの機能を拡張します。

MCP server は、AWS開発に特化したベストプラクティス、利用可能なプロジェクト構造、実装パターンに関するコンテキスト情報を提供します。AIツールがワークスペースを作成し、ジェネレーターを実行して一般的なプロジェクトタイプをスキャフォールドできるようにします。このコンテキスト認識により、AIは確立されたパターンに沿った、一般的な落とし穴を回避する、より情報に基づいた提案を行うことができます。

ベストプラクティスに沿わない、または存在しない機能を参照する可能性のあるコードを生成する代わりに、AIアシスタントはMCP server を活用してプロジェクトの基盤を築くことができます。その結果、プロジェクトのコアコンポーネントのための堅固な基盤から始め、AIを使用してビジネスロジックを埋めることができる、より決定論的で信頼性の高い開発体験が得られます。

はじめに

より構造化され信頼性の高いAI支援AWS開発を探求することに興味がある場合は、Nx Plugin for AWS MCP Server を試してみてください。お気に入りのAIアシスタント（Kiro、Kiro CLI、Cline、Claude Codeなど）で、次のMCP Server設定を使用してセットアップできます：

{
  "mcpServers": {
    "nx-plugin-for-aws": {
      "command": "npx",
      "args": ["-y", "@aws/nx-plugin-mcp"]
    }
  }
}

詳細な手順については、Building with AIガイドを参照してください。

@aws/nx-plugin へようこそ

Mon, 10 Mar 2025 00:00:00 GMT

ついにリリースです！🚀

Nx Plugin for AWS は、AWS 上でフルスタックアプリケーションを構築およびデプロイするプロセスを簡素化するためのツールキットを提供する Nx プラグインです。開発者にアプリケーションコードと IaC コードの両方について事前設定されたテンプレートを提供し、セットアップと設定に費やす時間を大幅に削減します。このプラグインは、カスタマイズの柔軟性を維持しながら、AWS サービス統合の複雑さを処理します。

ユーザーは利用可能なジェネレーターのリストから必要なコンポーネントを選択し、設定オプションを提供するだけで、@aws/nx-plugin が必要なスターターコードを生成します。このツールキット内には、API、ウェブサイト、インフラストラクチャを作成できるいくつかのジェネレーターが存在し、さらに型安全なクライアントを使用してフロントエンドをバックエンドに統合する（AST 変換による既存ファイルの更新を含む！）などのより高度な処理も実行できます。

詳細については、プラグインの主要コンポーネントをすべてカバーし、使用方法の良い感触を得られる Dungeon Adventure チュートリアルから始めてください。

皆様のフィードバックをお待ちしております。ご意見や次に見たい機能について、ディスカッションを投稿したり、issue を作成したりすることをお気軽にどうぞ！

試してみる！