@aws/nx-plugin-mcp 0.120.0 → 0.121.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (82) hide show
  1. package/bin/aws-nx-mcp.js +23 -35
  2. package/docs/guides/astro-docs.mdx +142 -0
  3. package/docs/guides/connection/py-agent-a2a.mdx +105 -0
  4. package/docs/guides/connection/py-agent-mcp.mdx +147 -0
  5. package/docs/guides/connection/react-agui.mdx +240 -0
  6. package/docs/guides/connection/react-fastapi.mdx +1476 -0
  7. package/docs/guides/connection/react-py-agent.mdx +198 -0
  8. package/docs/guides/connection/react-smithy.mdx +1355 -0
  9. package/docs/guides/connection/react-trpc.mdx +447 -0
  10. package/docs/guides/connection/react-ts-agent.mdx +198 -0
  11. package/docs/guides/connection/smithy-rdb.mdx +161 -0
  12. package/docs/guides/connection/trpc-rdb.mdx +127 -0
  13. package/docs/guides/connection/ts-agent-a2a.mdx +106 -0
  14. package/docs/guides/connection/ts-agent-mcp.mdx +144 -0
  15. package/docs/guides/connection/ts-agent-rdb.mdx +141 -0
  16. package/docs/guides/connection/ts-mcp-server-rdb.mdx +135 -0
  17. package/docs/guides/connection.mdx +126 -0
  18. package/docs/guides/docker-bundling.mdx +403 -0
  19. package/docs/guides/fastapi.mdx +509 -0
  20. package/docs/guides/license.mdx +293 -0
  21. package/docs/guides/nx-generator.mdx +588 -0
  22. package/docs/guides/py-agent.mdx +483 -0
  23. package/docs/guides/py-mcp-server.mdx +161 -0
  24. package/docs/guides/python-lambda-function.mdx +207 -0
  25. package/docs/guides/python-project.mdx +228 -0
  26. package/docs/guides/react-website-auth.mdx +216 -0
  27. package/docs/guides/react-website.mdx +421 -0
  28. package/docs/guides/runtime-config.mdx +312 -0
  29. package/docs/guides/terraform-project.mdx +317 -0
  30. package/docs/guides/trpc.mdx +816 -0
  31. package/docs/guides/ts-agent.mdx +436 -0
  32. package/docs/guides/ts-lambda-function.mdx +218 -0
  33. package/docs/guides/ts-mcp-server.mdx +169 -0
  34. package/docs/guides/ts-nx-plugin.mdx +159 -0
  35. package/docs/guides/ts-rdb.mdx +759 -0
  36. package/docs/guides/ts-smithy-api.mdx +661 -0
  37. package/docs/guides/typescript-infrastructure.mdx +408 -0
  38. package/docs/guides/typescript-project.mdx +312 -0
  39. package/docs/guides/workspace.mdx +181 -0
  40. package/docs/snippets/agent/architecture.mdx +72 -0
  41. package/docs/snippets/agent/bedrock-deployment.mdx +172 -0
  42. package/docs/snippets/agent/runtime-arn.mdx +64 -0
  43. package/docs/snippets/api/api-architecture.mdx +93 -0
  44. package/docs/snippets/api/api-choice-note.mdx +6 -0
  45. package/docs/snippets/api/cors-configuration-cdk-note.mdx +25 -0
  46. package/docs/snippets/api/cors-configuration-terraform-note.mdx +28 -0
  47. package/docs/snippets/api/shared-constructs.mdx +38 -0
  48. package/docs/snippets/api/type-safe-api-integrations.mdx +643 -0
  49. package/docs/snippets/api/waf-configuration.mdx +37 -0
  50. package/docs/snippets/connection/a2a-infrastructure.mdx +63 -0
  51. package/docs/snippets/connection/lambda-rdb-ssl-requirements.mdx +40 -0
  52. package/docs/snippets/connection/mcp-server-rdb-ssl-requirements.mdx +35 -0
  53. package/docs/snippets/connection/rdb-api-infrastructure.mdx +72 -0
  54. package/docs/snippets/connection/react-agent-infrastructure.mdx +61 -0
  55. package/docs/snippets/connection/strands-agent-rdb-ssl-requirements.mdx +35 -0
  56. package/docs/snippets/lambda-function/architecture.mdx +36 -0
  57. package/docs/snippets/lambda-function/deploying-your-function.mdx +118 -0
  58. package/docs/snippets/mcp/architecture.mdx +58 -0
  59. package/docs/snippets/mcp/assistant-docs.mdx +10 -0
  60. package/docs/snippets/mcp/bedrock-deployment.mdx +167 -0
  61. package/docs/snippets/mcp/config.mdx +13 -0
  62. package/docs/snippets/mcp/configuration-py.mdx +42 -0
  63. package/docs/snippets/mcp/configuration-ts.mdx +53 -0
  64. package/docs/snippets/mcp/observability.mdx +8 -0
  65. package/docs/snippets/mcp/shared-constructs.mdx +32 -0
  66. package/docs/snippets/pdk-migration/example/01-migrate-api.mdx +602 -0
  67. package/docs/snippets/pdk-migration/example/02-migrate-website.mdx +915 -0
  68. package/docs/snippets/pdk-migration/example/03-migrate-infra.mdx +161 -0
  69. package/docs/snippets/pdk-migration/example/04-deploy.mdx +229 -0
  70. package/docs/snippets/pdk-migration/faq/aws-arch.mdx +17 -0
  71. package/docs/snippets/pdk-migration/faq/cdk-graph.mdx +29 -0
  72. package/docs/snippets/pdk-migration/faq/infrastructure-python-java.mdx +19 -0
  73. package/docs/snippets/pdk-migration/faq/pdk-nag.mdx +15 -0
  74. package/docs/snippets/pdk-migration/faq/pipeline.mdx +15 -0
  75. package/docs/snippets/pdk-migration/faq/type-safe-api.mdx +310 -0
  76. package/docs/snippets/pdk-migration/faq/use-of-projen.mdx +15 -0
  77. package/docs/snippets/prerequisites.mdx +20 -0
  78. package/docs/snippets/required-prerequisites.mdx +12 -0
  79. package/docs/snippets/shared-constructs.mdx +40 -0
  80. package/docs/snippets/tools/acurl.mdx +73 -0
  81. package/docs/snippets/ts-bundle.mdx +14 -0
  82. package/package.json +1 -1
@@ -0,0 +1,310 @@
1
+ ---
2
+ title: Type Safe API
3
+ ---
4
+ import { Steps, Tabs, TabItem } from '@astrojs/starlight/components';
5
+ import Snippet from '@components/snippet.astro';
6
+ import CreateNxWorkspaceCommand from '@components/create-nx-workspace-command.astro';
7
+ import RunGenerator from '@components/run-generator.astro';
8
+ import Link from '@components/link.astro';
9
+ import NxCommands from '@components/nx-commands.astro';
10
+ import Drawer from '@components/drawer.astro';
11
+ import InstallCommand from '@components/install-command.astro';
12
+
13
+ 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.
14
+
15
+ #### APIs Modelled with OpenAPI
16
+
17
+ The Nx Plugin for AWS supports APIs modelled in Smithy, but not those modelled directly OpenAPI. The <Link path="/guides/ts-smithy-api">`ts#smithy-api` generator</Link> 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 modify the `build.Dockerfile` to use your desired code generation tool for clients/servers if they aren't available on NPM. If your desired tools are on NPM, you can just install them as dev dependencies to your Nx workspace and call them directly as Nx build targets.
18
+
19
+ ##### Backend
20
+
21
+ For type-safe backends modelled in OpenAPI, you can consider using one of the [OpenAPI Generator Server Generators](https://openapi-generator.tech/docs/generators#server-generators). These won't generate directly for AWS Lambda, but you can use the [AWS Lambda Web Adapter](https://github.com/awslabs/aws-lambda-web-adapter) to bridge the gap for a lot of them.
22
+
23
+ :::tip
24
+ For Python, the [python-fastapi](https://openapi-generator.tech/docs/generators/python-fastapi) generator could be used as a as a once-off tool to help migrate from Type Safe API to our <Link path="/guides/fastapi">`py#fast-api` generator</Link>.
25
+ :::
26
+
27
+ ##### Client
28
+
29
+ For TypeScript clients, you can use the <Link path="/guides/react-website">`ts#react-website` generator</Link> and <Link path="/guides/connection">`connection` generator</Link> with an example `ts#smithy-api` 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.
30
+
31
+ For other languages, you can also see if any of the generators from [OpenAPI Generator](https://openapi-generator.tech/docs/generators#client-generators) fit your needs.
32
+
33
+ You can also build a bespoke generator by using the <Link path="/guides/nx-generator">`ts#nx-generator` generator</Link>. 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](https://github.com/awslabs/nx-plugin-for-aws/tree/main/packages/nx-plugin/src/open-api/ts-client/files) as a starting point. You can also even refer to the [templates from the PDK codebase](https://github.com/aws/aws-pdk/tree/mainline/packages/type-safe-api/scripts/type-safe-api/generators) for more inspiration, noting that the data structure the templates operate on is a little different to the Nx Plugin for AWS.
34
+
35
+ #### APIs Modelled with TypeSpec
36
+
37
+ For [TypeSpec](https://typespec.io/), the above section for OpenAPI applies too. You can start by generating a <Link path="/guides/ts-smithy-api">`ts#smithy-api`</Link>, 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.
38
+
39
+ ##### Backend
40
+
41
+ The recommended approach would be to use the [TypeSpec HTTP Server generator for JavaScript](https://typespec.io/docs/emitters/servers/http-server-js/reference/) to generate your server code, since this works directly on your TypeSpec model.
42
+
43
+ You can use the [AWS Lambda Web Adapter](https://github.com/awslabs/aws-lambda-web-adapter) for running the generated server on AWS Lambda.
44
+
45
+ You can also use any of the above OpenAPI options.
46
+
47
+ ##### Client
48
+
49
+ TypeSpec has its own code generators for clients in all three of Type Safe API's supported languages:
50
+
51
+ - [TypeScript](https://typespec.io/docs/emitters/clients/http-client-js/reference/)
52
+ - [Python](https://typespec.io/docs/emitters/clients/http-client-python/reference/)
53
+ - [Java](https://typespec.io/docs/emitters/clients/http-client-java/reference/)
54
+
55
+ The above OpenAPI section also applies since TypeSpec can compile to OpenAPI.
56
+
57
+ #### APIs Modelled with Smithy
58
+
59
+ The above example migration outlines migrating to use the <Link path="/guides/ts-smithy-api">`ts#smithy-api` generator</Link>. This section covers the options for Python and Java backends and clients.
60
+
61
+ ##### Backend
62
+
63
+ The [Smithy code generator for Java](https://github.com/smithy-lang/smithy-java). This has a Java server generator as well as [an adapter](https://github.com/smithy-lang/smithy-java/tree/main/aws/integrations) to run the generated Java server on AWS Lambda.
64
+
65
+ 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](#apis-modelled-with-openapi) for potential options.
66
+
67
+ ##### Client
68
+
69
+ The [Smithy code generator for Java](https://github.com/smithy-lang/smithy-java). This has a Java client generator.
70
+
71
+ For Python clients, you can check out [Smithy Python](https://github.com/smithy-lang/smithy-python).
72
+
73
+ For TypeScript, check out [Smithy TypeScript](https://github.com/smithy-lang/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).
74
+
75
+
76
+ ##### Smithy Shape Library
77
+
78
+ 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.
79
+
80
+ The most straightforward way to achieve this is to do the following:
81
+
82
+ ###### Create a Shape Library
83
+
84
+ <Steps>
85
+
86
+ 1. Create your shape library using the `smithy#project` generator:
87
+
88
+ <RunGenerator generator="smithy#project" />
89
+
90
+ Specify any name for the `serviceName` option, as we will remove the `service` shape.
91
+
92
+ :::note
93
+ This generator is hidden at the time of writing and so you will need to execute it via the CLI.
94
+ :::
95
+
96
+ 1. Replace the default model in `src` with the shapes you wish to define
97
+
98
+ 1. Update `smithy-build.json` to remove the `plugins` and any unused maven dependencies
99
+
100
+ 1. Replace `build.Dockerfile` with minimal build steps:
101
+
102
+ ```docker
103
+ // build.Dockerfile
104
+ FROM public.ecr.aws/docker/library/node:24 AS builder
105
+
106
+ # Output directory
107
+ RUN mkdir /out
108
+
109
+ # Install Smithy CLI
110
+ # https://smithy.io/2.0/guides/smithy-cli/cli_installation.html
111
+ WORKDIR /smithy
112
+ ARG TARGETPLATFORM
113
+ RUN if [ "$TARGETPLATFORM" = "linux/arm64" ]; then ARCH="aarch64"; else ARCH="x86_64"; fi && \
114
+ mkdir -p smithy-install/smithy && \
115
+ curl -L https://github.com/smithy-lang/smithy/releases/download/1.61.0/smithy-cli-linux-$ARCH.zip -o smithy-install/smithy-cli-linux-$ARCH.zip && \
116
+ unzip -qo smithy-install/smithy-cli-linux-$ARCH.zip -d smithy-install && \
117
+ mv smithy-install/smithy-cli-linux-$ARCH/* smithy-install/smithy
118
+ RUN smithy-install/smithy/install
119
+
120
+ # Copy project files
121
+ COPY smithy-build.json .
122
+ COPY src src
123
+
124
+ # Smithy build with Maven cache mount
125
+ RUN --mount=type=cache,target=/root/.m2/repository,id=maven-cache \
126
+ smithy build
127
+
128
+ RUN cp -r build/* /out/
129
+
130
+ # Export the /out directory
131
+ FROM scratch AS export
132
+ COPY --from=builder /out /
133
+ ```
134
+
135
+ </Steps>
136
+
137
+ ###### Consume the Shape Library
138
+
139
+ In your service model project(s), make the following changes to consume the shape library:
140
+
141
+ <Steps>
142
+
143
+ 1. Update the `compile` target in `project.json` to add the workspace as build context, and a dependency on the shape library's `build` target
144
+
145
+ ```json {10,15} "--build-context workspace=." "@my-project/shapes:build"
146
+ // project.json
147
+ {
148
+ "cache": true,
149
+ "outputs": ["{workspaceRoot}/dist/{projectRoot}/build"],
150
+ "executor": "nx:run-commands",
151
+ "options": {
152
+ "commands": [
153
+ "rimraf dist/packages/api/model/build",
154
+ "make-dir dist/packages/api/model/build",
155
+ "docker build --build-context workspace=. -f packages/api/model/build.Dockerfile --target export --output type=local,dest=dist/packages/api/model/build packages/api/model"
156
+ ],
157
+ "parallel": false,
158
+ "cwd": "{workspaceRoot}"
159
+ },
160
+ "dependsOn": ["@my-project/shapes:build"]
161
+ }
162
+ ```
163
+
164
+ 1. Update the `build.Dockerfile` to copy the `src` directory from your shape library. For example, assuming the shape library is located in `packages/shapes`:
165
+
166
+ ```docker {5}
167
+ // build.Dockerfile
168
+ # Copy project files
169
+ COPY smithy-build.json .
170
+ COPY src src
171
+ COPY --from=workspace packages/shapes/src shapes
172
+ ```
173
+
174
+ 1. Update `smithy-build.json` to add the shapes directory to its `sources`:
175
+
176
+ ```json {4} "shapes/"
177
+ // smithy-build.json
178
+ {
179
+ "version": "1.0",
180
+ "sources": ["src/", "shapes/"],
181
+ "plugins": {
182
+ ...
183
+ }
184
+ ```
185
+
186
+ </Steps>
187
+
188
+ :::note
189
+ Please express your interest on the [GitHub issue here](https://github.com/awslabs/nx-plugin-for-aws/issues/304) if you have a use case for a dedicated Smithy shape library generator.
190
+ :::
191
+
192
+ #### Interceptors
193
+
194
+ Type Safe API provided the following default interceptors:
195
+
196
+ - Logging, tracing and metrics interceptors using Powertools for AWS Lambda
197
+ - Try-catch interceptor for handling uncaught exceptions
198
+ - CORS interceptor for returning CORS headers
199
+
200
+ The `ts#smithy-api` generator instruments logging, tracing and metrics with Powertools for AWS Lambda using [Middy](https://middy.js.org/). The behaviour of the try-catch interceptor is built in to the Smithy TypeScript SSDK, and CORS headers are added in `handler.ts`.
201
+
202
+ For logging, tracing and metrics interceptors in any language, use [Powertools for AWS Lambda](https://github.com/aws-powertools/) directly.
203
+
204
+ For migrating custom interceptors, we recommend using the following libraries:
205
+
206
+ - TypeScript - [Middy](https://middy.js.org/)
207
+ - Python - [Powertools for AWS Lambda Middleware Factory](https://docs.powertools.aws.dev/lambda/python/latest/utilities/middleware_factory/)
208
+ - Java - Instrument methods before/after your business logic using [aws-lambda-java-libs](https://github.com/aws/aws-lambda-java-libs) for a simple approach, or consider [AspectJ](https://github.com/eclipse-aspectj/aspectj) for building your middleware as annotations.
209
+
210
+ #### Documentation Generation
211
+
212
+ 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.
213
+
214
+ <Steps>
215
+
216
+ 1. Install the Redocly CLI
217
+
218
+ <InstallCommand pkg="@redocly/cli" dev />
219
+
220
+ 1. Add a documentation generation target to your `model` project using [`redocly build-docs`](https://redocly.com/docs/cli/commands/build-docs), for example:
221
+
222
+ ```json wrap
223
+ // model/project.json
224
+ {
225
+ ...
226
+ "documentation": {
227
+ "cache": true,
228
+ "outputs": ["{workspaceRoot}/dist/{projectRoot}/documentation"],
229
+ "executor": "nx:run-commands",
230
+ "options": {
231
+ "command": "redocly build-docs dist/packages/api/model/build/openapi/openapi.json --output=dist/packages/api/model/documentation/index.html",
232
+ "cwd": "{workspaceRoot}"
233
+ },
234
+ "dependsOn": ["compile"]
235
+ }
236
+ }
237
+ ```
238
+
239
+ </Steps>
240
+
241
+ You can also consider the [OpenAPI Generator documentation generators](https://openapi-generator.tech/docs/generators#documentation-generators).
242
+
243
+ #### Mock Integrations
244
+
245
+ Type Safe API generated mocks for you within its generated infrastructure package.
246
+
247
+ You can move to [JSON Schema Faker](https://github.com/json-schema-faker/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](https://github.com/oprogramador/json-schema-faker-cli) which you could run as part of your `model` project build.
248
+
249
+ You can update your CDK infrastructure to read the JSON file output by JSON Schema Faker, and return the appropriate API Gateway [`MockIntegration`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_apigateway.MockIntegration.html) for an integration, based on the generated `metadata.gen.ts` (assuming you used the <Link path="/guides/ts-smithy-api">`ts#smithy-api` generator</Link>).
250
+
251
+ #### Mixed Language Backends
252
+
253
+ 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:
254
+
255
+ ```ts
256
+ // application-stack.ts
257
+ const pythonLambdaHandler = new Function(this, 'PythonImplementation', {
258
+ runtime: Runtime.PYTHON_3_12,
259
+ ...
260
+ });
261
+
262
+ new MyApi(this, 'MyApi', {
263
+ integrations: Api.defaultIntegrations(this)
264
+ .withOverrides({
265
+ echo: {
266
+ integration: new LambdaIntegration(pythonLambdaHandler),
267
+ handler: pythonLambdaHandler,
268
+ },
269
+ })
270
+ .build(),
271
+ });
272
+ ```
273
+
274
+ 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:
275
+
276
+ ```ts {4}
277
+ // service.ts
278
+ export const Service: ApiService<ServiceContext> = {
279
+ ...
280
+ Echo: () => { throw new Error(`Not Implemented`); },
281
+ };
282
+ ```
283
+
284
+ :::note
285
+ For type-safety for languages other than TypeScript, refer to the above "Backend" sections depending on your modelling language.
286
+ :::
287
+
288
+ #### Input Validation
289
+
290
+ Type Safe API added native API Gateway validation for request bodies based on your OpenAPI specification since it used the [`SpecRestApi`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_apigateway.SpecRestApi.html) construct under the hood.
291
+
292
+ With the <Link path="/guides/ts-smithy-api">`ts#smithy-api` generator</Link>, validation is performed by the Server SDK itself. This is the same for most server generators.
293
+
294
+ 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.
295
+
296
+ #### WebSocket APIs
297
+
298
+ 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.
299
+
300
+ Consider using [AsyncAPI](https://www.asyncapi.com/) to model your API instead of OpenAPI or TypeSpec since this is designed to handle asynchronous APIs. The [AsyncAPI NodeJS Template](https://github.com/asyncapi/nodejs-template) can generate a Node websocket backend which you could host on [ECS](https://docs.aws.amazon.com/ecs/) for example.
301
+
302
+ You can also consider [AppSync Events](https://docs.aws.amazon.com/appsync/latest/eventapi/event-api-welcome.html) for infrastructure, and use [Powertools](https://docs.powertools.aws.dev/lambda/typescript/latest/features/event-handler/appsync-events/). [This blog post](https://aws.amazon.com/blogs/mobile/simplify-aws-appsync-events-integration-with-powertools-for-aws-lambda/) is worth a read!
303
+
304
+ Another option is to use GraphQL APIs with websockets on [AppSync](https://aws.amazon.com/appsync/), for which we have a [GitHub issue](https://github.com/awslabs/nx-plugin-for-aws/issues/154) you can +1! Refer to the [AppSync developer guide](https://docs.aws.amazon.com/appsync/latest/devguide/what-is-appsync.html) for details and links to sample projects.
305
+
306
+ 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](#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](https://github.com/aws/aws-pdk/tree/mainline/packages/type-safe-api/scripts/type-safe-api/generators/typescript-async-runtime/templates), and the client [here](https://github.com/aws/aws-pdk/blob/mainline/packages/type-safe-api/scripts/type-safe-api/generators/typescript-websocket-client/templates/client.ejs).
307
+
308
+ You can also consider migrating to use the <Link path="/guides/trpc.mdx">`ts#trpc-api` generator</Link> 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](https://github.com/awslabs/nx-plugin-for-aws/issues/194).
309
+
310
+ Smithy is protocol agnostic, but does not yet have support for the Websocket protocol, refer to [this GitHub issue tracking support](https://github.com/smithy-lang/smithy/issues/1505).
@@ -0,0 +1,15 @@
1
+ ---
2
+ title: Use of Projen
3
+ ---
4
+ import { Steps, Tabs, TabItem } from '@astrojs/starlight/components';
5
+ import Snippet from '@components/snippet.astro';
6
+ import CreateNxWorkspaceCommand from '@components/create-nx-workspace-command.astro';
7
+ import RunGenerator from '@components/run-generator.astro';
8
+ import Link from '@components/link.astro';
9
+ import NxCommands from '@components/nx-commands.astro';
10
+ import Drawer from '@components/drawer.astro';
11
+ import InstallCommand from '@components/install-command.astro';
12
+
13
+ PDK was built on top of [Projen](https://projen.io/). 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.
14
+
15
+ 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.
@@ -0,0 +1,20 @@
1
+ ---
2
+ title: Prerequisites
3
+ ---
4
+ import Link from '@components/link.astro';
5
+ import Snippet from '@components/snippet.astro';
6
+
7
+ ### Required
8
+
9
+ <Snippet name="required-prerequisites" parentHeading="Required" />
10
+
11
+ ### Recommended
12
+
13
+ - [Docker](https://www.docker.com/) is required for some generators. [Multi-platform builds](https://docs.docker.com/build/building/multi-platform/) must be set up.
14
+ - [Terraform >= 1.12](https://developer.hashicorp.com/terraform/install) is required if you choose to use this for infrastructure as code instead of CDK
15
+ - verify by running `terraform --version`
16
+ - If you are using [VSCode](https://code.visualstudio.com/), we recommend installing the [Nx Console VSCode Plugin](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console).
17
+
18
+ :::tip[AI Assistant Setup]
19
+ If you use an AI Assistant such as Kiro, Kiro CLI, Cursor, Claude Code or Cline, you may also wish to <Link path="/get_started/building-with-ai">install the Nx Plugin for AWS MCP server.</Link>
20
+ :::
@@ -0,0 +1,12 @@
1
+ ---
2
+ title: Required Prerequisites
3
+ ---
4
+ - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
5
+ - [Node >= 22](https://nodejs.org/en/download) (We recommend using something like [NVM](https://github.com/nvm-sh/nvm) to manage your node versions)
6
+ - verify by running `node --version`
7
+ - [PNPM >= 10](https://pnpm.io/installation#using-npm) (you can also use [Yarn >= 4](https://yarnpkg.com/getting-started/install), [Bun >= 1](https://bun.sh/docs/installation), or [NPM >= 10](https://nodejs.org/en/learn/getting-started/an-introduction-to-the-npm-package-manager) if you prefer)
8
+ - verify by running `pnpm --version`, `yarn --version`, `bun --version` or `npm --version`
9
+ - [UV >= 0.5.29](https://docs.astral.sh/uv/getting-started/installation/)
10
+ 1. install Python 3.14 by running: `uv python install 3.14.0`
11
+ 2. verify with `uv python list --only-installed`
12
+ - [AWS Credentials](https://docs.aws.amazon.com/sdkref/latest/guide/access.html) configured to your target AWS account (where your application will be deployed)
@@ -0,0 +1,40 @@
1
+ ---
2
+ title: Shared Constructs
3
+ ---
4
+ import { FileTree } from '@astrojs/starlight/components';
5
+ import Infrastructure from '@components/infrastructure.astro';
6
+ import Link from '@components/link.astro';
7
+
8
+ Since this generator vends infrastructure as code based on your chosen `iacProvider`, it will create a project in `packages/common` which includes the relevant CDK constructs or Terraform modules.
9
+
10
+ The common infrastructure as code project is structured as follows:
11
+
12
+ <Infrastructure>
13
+ <Fragment slot="cdk">
14
+ <FileTree>
15
+ - packages/common/constructs
16
+ - src
17
+ - app/ Constructs for infrastructure specific to a project/generator
18
+ - core/ Generic constructs which are reused by constructs in `app`
19
+ - index.ts Entry point exporting constructs from `app`
20
+ - project.json Project build targets and configuration
21
+ </FileTree>
22
+
23
+ :::note[Generated Project]
24
+ This project is generated using the <Link path="/guides/typescript-project">`ts#project`</Link> generator and therefore configures the same build targets.
25
+ :::
26
+ </Fragment>
27
+ <Fragment slot="terraform">
28
+ <FileTree>
29
+ - packages/common/terraform
30
+ - src
31
+ - app/ Terraform modules for infrastructure specific to a project/generator
32
+ - core/ Generic modules which are reused by modules in `app`
33
+ - project.json Project build targets and configuration
34
+ </FileTree>
35
+
36
+ :::note[Generated Project]
37
+ This project is generated using the <Link path="/guides/terraform-project">`terraform#project`</Link> generator and therefore configures the same build targets.
38
+ :::
39
+ </Fragment>
40
+ </Infrastructure>
@@ -0,0 +1,73 @@
1
+ ---
2
+ title: AWS Sigv4 Curl
3
+ ---
4
+
5
+ import { Tabs, TabItem } from '@astrojs/starlight/components';
6
+
7
+ <Tabs>
8
+ <TabItem label="Bash/Linux/macOS">
9
+ You can either add the following script to your `.bashrc` file (and `source` it) or paste the following into the same terminal you wish to run the command in.
10
+ ```bash
11
+ // ~/.bashrc
12
+ acurl () {
13
+ REGION=$1
14
+ SERVICE=$2
15
+ shift; shift;
16
+ curl --aws-sigv4 "aws:amz:$REGION:$SERVICE" --user "$(aws configure get aws_access_key_id):$(aws configure get aws_secret_access_key)" -H "X-Amz-Security-Token: $(aws configure get aws_session_token)" "$@"
17
+ }
18
+ ```
19
+
20
+ To make a `sigv4` authenticated curl request, invoke `acurl` as follows:
21
+
22
+ ```bash
23
+ acurl <region> <service> <other-curl-arguments>
24
+ ```
25
+
26
+ For example:
27
+
28
+ ###### API Gateway
29
+ ```bash
30
+ acurl ap-southeast-2 execute-api -X GET https://xxx
31
+ ```
32
+
33
+ ###### Streaming Lambda function url
34
+ ```bash
35
+ acurl ap-southeast-2 lambda -N -X POST https://xxx
36
+ ```
37
+ </TabItem>
38
+ <TabItem label="Windows PowerShell">
39
+ You can either add the following function to your PowerShell profile or paste the following into the same PowerShell session you wish to run the command in.
40
+ ```powershell
41
+ # PowerShell profile or current session
42
+ function acurl {
43
+ param(
44
+ [Parameter(Mandatory=$true)][string]$Region,
45
+ [Parameter(Mandatory=$true)][string]$Service,
46
+ [Parameter(ValueFromRemainingArguments=$true)][string[]]$CurlArgs
47
+ )
48
+
49
+ $AccessKey = aws configure get aws_access_key_id
50
+ $SecretKey = aws configure get aws_secret_access_key
51
+ $SessionToken = aws configure get aws_session_token
52
+
53
+ & curl --aws-sigv4 "aws:amz:$Region`:$Service" --user "$AccessKey`:$SecretKey" -H "X-Amz-Security-Token: $SessionToken" @CurlArgs
54
+ }
55
+ ```
56
+
57
+ To make a `sigv4` authenticated curl request, invoke `acurl` using these examples:
58
+
59
+ ###### API Gateway
60
+ ```powershell
61
+ acurl ap-southeast-2 execute-api -X GET https://xxx
62
+ ```
63
+
64
+ ###### Streaming Lambda function url
65
+ ```powershell
66
+ acurl ap-southeast-2 lambda -N -X POST https://xxx
67
+ ```
68
+ </TabItem>
69
+ </Tabs>
70
+
71
+ :::caution[Curl Version Requirement]
72
+ AWS Signature v4 support has been added in more recent versions of `curl`, and there have been some bugfixes in this support in recent years. It's recommended that you install `curl` version 8.17.0 or higher. The version distributed with your OS may be out of date.
73
+ :::
@@ -0,0 +1,14 @@
1
+ ---
2
+ title: TypeScript Bundling
3
+ ---
4
+ import NxCommands from '@components/nx-commands.astro';
5
+
6
+ The generator automatically configures a `bundle` target which uses [Rolldown](https://rolldown.rs/) to create a deployment package:
7
+
8
+ <NxCommands commands={['bundle <project-name>']} />
9
+
10
+ Rolldown configuration can be found in `rolldown.config.ts`, with an entry per bundle to generate. Rolldown manages creating multiple bundles in parallel if defined.
11
+
12
+ :::tip[Custom Configuration]
13
+ You can adjust the configuration for Rolldown in `rolldown.config.ts`, for example if you have dependencies which rely on file paths and cannot be bundled, you can add them to the list of `external` modules.
14
+ :::
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@aws/nx-plugin-mcp",
3
- "version": "0.120.0",
3
+ "version": "0.121.0",
4
4
  "repository": {
5
5
  "type": "git",
6
6
  "url": "https://github.com/awslabs/nx-plugin-for-aws.git",