@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.
- package/bin/aws-nx-mcp.js +23 -35
- package/docs/guides/astro-docs.mdx +142 -0
- package/docs/guides/connection/py-agent-a2a.mdx +105 -0
- package/docs/guides/connection/py-agent-mcp.mdx +147 -0
- package/docs/guides/connection/react-agui.mdx +240 -0
- package/docs/guides/connection/react-fastapi.mdx +1476 -0
- package/docs/guides/connection/react-py-agent.mdx +198 -0
- package/docs/guides/connection/react-smithy.mdx +1355 -0
- package/docs/guides/connection/react-trpc.mdx +447 -0
- package/docs/guides/connection/react-ts-agent.mdx +198 -0
- package/docs/guides/connection/smithy-rdb.mdx +161 -0
- package/docs/guides/connection/trpc-rdb.mdx +127 -0
- package/docs/guides/connection/ts-agent-a2a.mdx +106 -0
- package/docs/guides/connection/ts-agent-mcp.mdx +144 -0
- package/docs/guides/connection/ts-agent-rdb.mdx +141 -0
- package/docs/guides/connection/ts-mcp-server-rdb.mdx +135 -0
- package/docs/guides/connection.mdx +126 -0
- package/docs/guides/docker-bundling.mdx +403 -0
- package/docs/guides/fastapi.mdx +509 -0
- package/docs/guides/license.mdx +293 -0
- package/docs/guides/nx-generator.mdx +588 -0
- package/docs/guides/py-agent.mdx +483 -0
- package/docs/guides/py-mcp-server.mdx +161 -0
- package/docs/guides/python-lambda-function.mdx +207 -0
- package/docs/guides/python-project.mdx +228 -0
- package/docs/guides/react-website-auth.mdx +216 -0
- package/docs/guides/react-website.mdx +421 -0
- package/docs/guides/runtime-config.mdx +312 -0
- package/docs/guides/terraform-project.mdx +317 -0
- package/docs/guides/trpc.mdx +816 -0
- package/docs/guides/ts-agent.mdx +436 -0
- package/docs/guides/ts-lambda-function.mdx +218 -0
- package/docs/guides/ts-mcp-server.mdx +169 -0
- package/docs/guides/ts-nx-plugin.mdx +159 -0
- package/docs/guides/ts-rdb.mdx +759 -0
- package/docs/guides/ts-smithy-api.mdx +661 -0
- package/docs/guides/typescript-infrastructure.mdx +408 -0
- package/docs/guides/typescript-project.mdx +312 -0
- package/docs/guides/workspace.mdx +181 -0
- package/docs/snippets/agent/architecture.mdx +72 -0
- package/docs/snippets/agent/bedrock-deployment.mdx +172 -0
- package/docs/snippets/agent/runtime-arn.mdx +64 -0
- package/docs/snippets/api/api-architecture.mdx +93 -0
- package/docs/snippets/api/api-choice-note.mdx +6 -0
- package/docs/snippets/api/cors-configuration-cdk-note.mdx +25 -0
- package/docs/snippets/api/cors-configuration-terraform-note.mdx +28 -0
- package/docs/snippets/api/shared-constructs.mdx +38 -0
- package/docs/snippets/api/type-safe-api-integrations.mdx +643 -0
- package/docs/snippets/api/waf-configuration.mdx +37 -0
- package/docs/snippets/connection/a2a-infrastructure.mdx +63 -0
- package/docs/snippets/connection/lambda-rdb-ssl-requirements.mdx +40 -0
- package/docs/snippets/connection/mcp-server-rdb-ssl-requirements.mdx +35 -0
- package/docs/snippets/connection/rdb-api-infrastructure.mdx +72 -0
- package/docs/snippets/connection/react-agent-infrastructure.mdx +61 -0
- package/docs/snippets/connection/strands-agent-rdb-ssl-requirements.mdx +35 -0
- package/docs/snippets/lambda-function/architecture.mdx +36 -0
- package/docs/snippets/lambda-function/deploying-your-function.mdx +118 -0
- package/docs/snippets/mcp/architecture.mdx +58 -0
- package/docs/snippets/mcp/assistant-docs.mdx +10 -0
- package/docs/snippets/mcp/bedrock-deployment.mdx +167 -0
- package/docs/snippets/mcp/config.mdx +13 -0
- package/docs/snippets/mcp/configuration-py.mdx +42 -0
- package/docs/snippets/mcp/configuration-ts.mdx +53 -0
- package/docs/snippets/mcp/observability.mdx +8 -0
- package/docs/snippets/mcp/shared-constructs.mdx +32 -0
- package/docs/snippets/pdk-migration/example/01-migrate-api.mdx +602 -0
- package/docs/snippets/pdk-migration/example/02-migrate-website.mdx +915 -0
- package/docs/snippets/pdk-migration/example/03-migrate-infra.mdx +161 -0
- package/docs/snippets/pdk-migration/example/04-deploy.mdx +229 -0
- package/docs/snippets/pdk-migration/faq/aws-arch.mdx +17 -0
- package/docs/snippets/pdk-migration/faq/cdk-graph.mdx +29 -0
- package/docs/snippets/pdk-migration/faq/infrastructure-python-java.mdx +19 -0
- package/docs/snippets/pdk-migration/faq/pdk-nag.mdx +15 -0
- package/docs/snippets/pdk-migration/faq/pipeline.mdx +15 -0
- package/docs/snippets/pdk-migration/faq/type-safe-api.mdx +310 -0
- package/docs/snippets/pdk-migration/faq/use-of-projen.mdx +15 -0
- package/docs/snippets/prerequisites.mdx +20 -0
- package/docs/snippets/required-prerequisites.mdx +12 -0
- package/docs/snippets/shared-constructs.mdx +40 -0
- package/docs/snippets/tools/acurl.mdx +73 -0
- package/docs/snippets/ts-bundle.mdx +14 -0
- 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
|
+
:::
|