-
-
Notifications
You must be signed in to change notification settings - Fork 50
feat(standard-server): AWS Lambda Adapter #534
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThis change introduces first-class AWS Lambda support to the oRPC ecosystem. It adds new AWS Lambda adapters for both the server and OpenAPI packages, implements Lambda-specific handler classes, and provides bidirectional conversion utilities for Lambda events, headers, bodies, and streaming responses. Comprehensive documentation, tests, and TypeScript project configuration updates are included. Changes
Sequence Diagram(s)sequenceDiagram
participant API Gateway
participant AWS Lambda
participant oRPC Lambda Handler
participant Standard Handler
participant Response Stream
API Gateway->>AWS Lambda: Invoke with APIGatewayProxyEventV2
AWS Lambda->>oRPC Lambda Handler: Pass event, responseStream
oRPC Lambda Handler->>Standard Handler: Convert event to StandardLazyRequest, handle()
Standard Handler-->>oRPC Lambda Handler: StandardResponse (or no match)
alt Route matched
oRPC Lambda Handler->>Response Stream: sendStandardResponse(StandardResponse)
Response Stream-->>API Gateway: Streamed response
else No route match
oRPC Lambda Handler-->>AWS Lambda: Return 404 or { matched: false }
end
Possibly related PRs
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (4)
✅ Files skipped from review due to trivial changes (2)
🚧 Files skipped from review as they are similar to previous changes (2)
⏰ Context from checks skipped due to timeout of 90000ms (2)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAttention: Patch coverage is
📢 Thoughts on this report? Let us know! |
More templates
@orpc/arktype
@orpc/client
@orpc/contract
@orpc/hey-api
@orpc/openapi
@orpc/openapi-client
@orpc/nest
@orpc/react
@orpc/react-query
@orpc/server
@orpc/shared
@orpc/solid-query
@orpc/standard-server
@orpc/standard-server-aws-lambda
@orpc/standard-server-fetch
@orpc/standard-server-node
@orpc/standard-server-peer
@orpc/svelte-query
@orpc/tanstack-query
@orpc/valibot
@orpc/vue-colada
@orpc/vue-query
@orpc/zod
commit: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 8
🧹 Nitpick comments (10)
packages/standard-server-aws-lambda/.gitignore (2)
1-5
: Be cautious with the.*
pattern for hidden files
The.*
entry will ignore all dotfiles (and directories) at this package’s root, which may inadvertently hide important config folders if they ever appear here. Consider scoping it to the root only (e.g.,/.*
) or confirm that ignoring every hidden file is intentional.
24-26
: Optional: Narrow the*.local
pattern
Using*.local
will ignore all files ending in.local
. If the goal is only to exclude environment overrides (e.g.,.env.local
), consider specifying that file explicitly.packages/standard-server-aws-lambda/src/signal.ts (1)
3-17
: Well-implemented AbortSignal creation with proper error handling.The implementation correctly handles stream lifecycle events and provides appropriate error propagation. The use of
once
listeners ensures proper cleanup, and the check forwritableFinished
properly detects premature stream closure.Consider adding JSDoc documentation for better API clarity:
+/** + * Creates an AbortSignal that aborts when the provided writable stream + * encounters an error or closes prematurely. + * + * @param responseStream - The writable stream to monitor + * @returns AbortSignal that aborts on stream error or premature closure + */ export function toAbortSignal( responseStream: Stream.Writable, ): AbortSignal {packages/standard-server-aws-lambda/src/headers.test.ts (1)
3-16
: Verify the test logic for handling invalid set-cookie header.The test passes a
'set-cookie': 'invalid'
in the headers object, but based on thetoStandardHeaders
implementation, this will be overwritten by the cookies array. The test expects the cookies array to take precedence, which appears correct.However, consider adding a test case that verifies the behavior when cookies array is undefined to ensure complete coverage.
Consider adding this additional test case for better coverage:
+it('toStandardHeaders with undefined cookies', () => { + expect(toStandardHeaders({ + 'content-type': 'application/json', + 'set-cookie': 'from-headers', + }, undefined)).toEqual({ + 'content-type': 'application/json', + 'set-cookie': undefined, + }) +})packages/openapi/src/adapters/aws-lambda/openapi-handler.test.ts (1)
26-27
: Use more realistic mock objects.The mock event and responseStream objects are overly simplified (
{ req: true }
and{ res: true }
). While this works for unit testing, using more realistic mock objects would improve test reliability and catch potential type issues.Consider using more realistic mock objects:
- const event: any = { req: true } - const responseStream: any = { res: true } + const event: any = { + version: '2.0', + routeKey: '$default', + rawPath: '/api/v1/ping', + rawQueryString: 'key=value', + requestContext: { + domainName: 'example.com', + http: { + method: 'GET', + path: '/api/v1/ping', + protocol: 'HTTP/1.1' + } + }, + headers: {}, + isBase64Encoded: false + } + const responseStream: any = { + write: vi.fn(), + end: vi.fn(), + on: vi.fn(), + once: vi.fn() + }packages/server/src/adapters/aws-lambda/rpc-handler.ts (1)
25-33
: Consider defensive copying to prevent options mutation.The current implementation directly mutates the
options.plugins
array, which could cause issues if the same options object is reused across multiple handler instances.Consider creating a shallow copy of options before mutation:
constructor(router: Router<any, T>, options: NoInfer<RPCHandlerOptions<T>> = {}) { + const safeOptions = { ...options } if (options.strictGetMethodPluginEnabled ?? true) { - options.plugins ??= [] - options.plugins.push(new StrictGetMethodPlugin()) + safeOptions.plugins = [...(options.plugins ?? []), new StrictGetMethodPlugin()] } - super(new StandardRPCHandler(router, options), options) + super(new StandardRPCHandler(router, safeOptions), safeOptions) }packages/standard-server-aws-lambda/src/response.ts (2)
7-7
: Consider adding JSDoc documentation for the options interface.While the interface extension is clean, it would benefit from documentation explaining its purpose in the AWS Lambda context.
+/** + * Options for sending standard responses in AWS Lambda environment. + * Extends ToLambdaBodyOptions to include body conversion settings. + */ export interface SendStandardResponseOptions extends ToLambdaBodyOptions {}
31-34
: Improve string body handling with proper encoding.The current implementation writes the string directly without specifying encoding, which could lead to encoding issues.
else if (typeof body === 'string') { - responseStream.write(body) + responseStream.write(body, 'utf8') responseStream.end() }packages/standard-server-aws-lambda/src/types.ts (1)
1-1
: Consider adding more specific attribution and version information.The comment is helpful but could be more specific about which version of aws-lambda types these are based on.
-// this is mainly copied from aws-lambda +// Type definitions based on @types/aws-lambda APIGatewayProxyEventV2 +// See: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/aws-lambda/index.d.tspackages/standard-server-aws-lambda/src/event-iterator.test.ts (1)
41-42
: Fix typo in test description.There's a typo in the test description.
- it('without dont event', async () => { + it('without done event', async () => {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yaml
is excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (33)
apps/content/docs/adapters/http.md
(2 hunks)packages/openapi/package.json
(2 hunks)packages/openapi/src/adapters/aws-lambda/index.ts
(1 hunks)packages/openapi/src/adapters/aws-lambda/openapi-handler.test.ts
(1 hunks)packages/openapi/src/adapters/aws-lambda/openapi-handler.ts
(1 hunks)packages/server/package.json
(3 hunks)packages/server/src/adapters/aws-lambda/handler.ts
(1 hunks)packages/server/src/adapters/aws-lambda/index.ts
(1 hunks)packages/server/src/adapters/aws-lambda/rpc-handler.test.ts
(1 hunks)packages/server/src/adapters/aws-lambda/rpc-handler.ts
(1 hunks)packages/server/tsconfig.json
(1 hunks)packages/standard-server-aws-lambda/.gitignore
(1 hunks)packages/standard-server-aws-lambda/README.md
(1 hunks)packages/standard-server-aws-lambda/package.json
(1 hunks)packages/standard-server-aws-lambda/src/body.test.ts
(1 hunks)packages/standard-server-aws-lambda/src/body.ts
(1 hunks)packages/standard-server-aws-lambda/src/event-iterator.test.ts
(1 hunks)packages/standard-server-aws-lambda/src/event-iterator.ts
(1 hunks)packages/standard-server-aws-lambda/src/headers.test.ts
(1 hunks)packages/standard-server-aws-lambda/src/headers.ts
(1 hunks)packages/standard-server-aws-lambda/src/index.ts
(1 hunks)packages/standard-server-aws-lambda/src/request.test.ts
(1 hunks)packages/standard-server-aws-lambda/src/request.ts
(1 hunks)packages/standard-server-aws-lambda/src/response.test.ts
(1 hunks)packages/standard-server-aws-lambda/src/response.ts
(1 hunks)packages/standard-server-aws-lambda/src/signal.test.ts
(1 hunks)packages/standard-server-aws-lambda/src/signal.ts
(1 hunks)packages/standard-server-aws-lambda/src/types.test-d.ts
(1 hunks)packages/standard-server-aws-lambda/src/types.ts
(1 hunks)packages/standard-server-aws-lambda/src/url.test.ts
(1 hunks)packages/standard-server-aws-lambda/src/url.ts
(1 hunks)packages/standard-server-aws-lambda/tsconfig.json
(1 hunks)tsconfig.json
(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (13)
packages/server/src/adapters/aws-lambda/handler.ts (8)
packages/standard-server-aws-lambda/src/response.ts (2)
SendStandardResponseOptions
(7-7)sendStandardResponse
(9-47)packages/server/src/context.ts (1)
Context
(1-1)packages/server/src/adapters/standard/handler.ts (1)
StandardHandler
(50-145)packages/standard-server-aws-lambda/src/types.ts (1)
APIGatewayProxyEventV2
(19-39)packages/standard-server-aws-lambda/src/index.ts (1)
ResponseStream
(12-12)packages/shared/src/args.ts (2)
MaybeOptionalOptions
(1-3)resolveMaybeOptionalOptions
(5-7)packages/server/src/adapters/standard/utils.ts (2)
FriendlyStandardHandleOptions
(4-6)resolveFriendlyStandardHandleOptions
(8-13)packages/standard-server-aws-lambda/src/request.ts (1)
toStandardLazyRequest
(10-25)
packages/standard-server-aws-lambda/src/signal.test.ts (1)
packages/standard-server-aws-lambda/src/signal.ts (1)
toAbortSignal
(3-17)
packages/standard-server-aws-lambda/src/headers.test.ts (2)
packages/standard-server-aws-lambda/src/headers.ts (2)
toStandardHeaders
(6-14)toLambdaHeaders
(16-36)packages/standard-server-aws-lambda/src/request.ts (2)
headers
(14-18)headers
(19-21)
packages/server/src/adapters/aws-lambda/rpc-handler.ts (5)
packages/server/src/context.ts (1)
Context
(1-1)packages/server/src/adapters/aws-lambda/handler.ts (2)
AwsLambdaHandlerOptions
(10-12)AwsLambdaHandler
(16-44)packages/server/src/adapters/standard/rpc-handler.ts (2)
StandardRPCHandlerOptions
(10-11)StandardRPCHandler
(13-22)packages/server/src/router.ts (1)
Router
(12-17)packages/server/src/plugins/strict-get-method.ts (1)
StrictGetMethodPlugin
(24-63)
packages/standard-server-aws-lambda/src/body.ts (6)
packages/standard-server-aws-lambda/src/types.ts (1)
APIGatewayProxyEventV2
(19-39)packages/standard-server/src/types.ts (2)
StandardBody
(5-11)StandardHeaders
(1-3)packages/standard-server/src/utils.ts (3)
getFilenameFromContentDisposition
(15-26)flattenHeader
(51-61)generateContentDisposition
(4-13)packages/shared/src/json.ts (2)
parseEmptyableJSON
(1-7)stringifyJSON
(9-12)packages/standard-server-aws-lambda/src/event-iterator.ts (3)
toEventIterator
(5-62)ToEventStreamOptions
(64-85)toEventStream
(87-156)packages/shared/src/iterator.ts (1)
isAsyncIteratorObject
(3-9)
packages/standard-server-aws-lambda/src/headers.ts (5)
packages/standard-server-aws-lambda/src/request.ts (2)
headers
(14-18)headers
(19-21)packages/standard-server-aws-lambda/src/types.ts (1)
APIGatewayProxyEventHeaders
(3-5)packages/standard-server/src/types.ts (1)
StandardHeaders
(1-3)packages/shared/src/array.ts (1)
toArray
(1-3)packages/standard-server/src/utils.ts (1)
flattenHeader
(51-61)
packages/openapi/src/adapters/aws-lambda/openapi-handler.ts (4)
packages/server/src/context.ts (1)
Context
(1-1)packages/server/src/adapters/aws-lambda/handler.ts (2)
AwsLambdaHandler
(16-44)AwsLambdaHandlerOptions
(10-12)packages/server/src/router.ts (1)
Router
(12-17)packages/openapi/src/adapters/standard/openapi-handler.ts (2)
StandardOpenAPIHandlerOptions
(9-10)StandardOpenAPIHandler
(12-22)
packages/standard-server-aws-lambda/src/request.test.ts (3)
packages/standard-server-aws-lambda/src/types.ts (1)
APIGatewayProxyEventV2
(19-39)packages/standard-server-aws-lambda/src/request.ts (1)
toStandardLazyRequest
(10-25)packages/shared/src/iterator.ts (1)
isAsyncIteratorObject
(3-9)
packages/standard-server-aws-lambda/src/url.ts (1)
packages/standard-server-aws-lambda/src/types.ts (1)
APIGatewayProxyEventV2
(19-39)
packages/standard-server-aws-lambda/src/types.test-d.ts (1)
packages/standard-server-aws-lambda/src/types.ts (1)
APIGatewayProxyEventV2
(19-39)
packages/standard-server-aws-lambda/src/url.test.ts (1)
packages/standard-server-aws-lambda/src/url.ts (1)
toStandardUrl
(3-5)
packages/standard-server-aws-lambda/src/event-iterator.ts (5)
packages/standard-server/src/event-iterator/decoder.ts (1)
EventDecoderStream
(92-112)packages/shared/src/iterator.ts (1)
createAsyncIteratorObject
(15-82)packages/shared/src/json.ts (2)
parseEmptyableJSON
(1-7)stringifyJSON
(9-12)packages/shared/src/object.ts (1)
isTypescriptObject
(44-46)packages/standard-server/src/event-iterator/encoder.ts (1)
encodeEventMessage
(52-79)
packages/standard-server-aws-lambda/src/request.ts (7)
packages/standard-server-aws-lambda/src/types.ts (1)
APIGatewayProxyEventV2
(19-39)packages/standard-server/src/types.ts (1)
StandardLazyRequest
(26-32)packages/standard-server-aws-lambda/src/url.ts (1)
toStandardUrl
(3-5)packages/standard-server-aws-lambda/src/headers.ts (1)
toStandardHeaders
(6-14)packages/standard-server-aws-lambda/src/signal.ts (1)
toAbortSignal
(3-17)packages/shared/src/function.ts (1)
once
(3-16)packages/standard-server-aws-lambda/src/body.ts (1)
toStandardBody
(10-42)
🪛 GitHub Check: codecov/patch
packages/standard-server-aws-lambda/src/index.ts
[warning] 3-10: packages/standard-server-aws-lambda/src/index.ts#L3-L10
Added lines #L3 - L10 were not covered by tests
🪛 LanguageTool
packages/standard-server-aws-lambda/README.md
[misspelling] ~33-~33: Possible spelling mistakes found.
Context: ...tack Query (React, Vue, Solid, Svelte), Pinia Colada, and more. - 🚀 Server Actions: Ful...
(EN_MULTITOKEN_SPELLING_TWO)
[style] ~51-~51: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... your API or implement API contract. - [@orpc/client](https://www.npmjs.com/package/@...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~52-~52: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... API on the client with type-safety. - [@orpc/nest](https://www.npmjs.com/package/@or...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~53-~53: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...: Deeply integrate oRPC with NestJS. - [@orpc/react](https://www.npmjs.com/package/@o...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~54-~54: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...with React and React Server Actions. - [@orpc/react-query](https://www.npmjs.com/pack...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~55-~55: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...test/docs/framework/react/overview). - [@orpc/vue-query](https://www.npmjs.com/packag...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~56-~56: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...latest/docs/framework/vue/overview). - [@orpc/solid-query](https://www.npmjs.com/pack...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~57-~57: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...test/docs/framework/solid/overview). - [@orpc/svelte-query](https://www.npmjs.com/pac...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~58-~58: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...est/docs/framework/svelte/overview). - [@orpc/vue-colada](https://www.npmjs.com/packa...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[misspelling] ~58-~58: Possible spelling mistakes found.
Context: ...ge/@orpc/vue-colada): Integration with Pinia Colada. - [@or...
(EN_MULTITOKEN_SPELLING_TWO)
[style] ~59-~59: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ada](https://pinia-colada.esm.dev/). - [@orpc/openapi](https://www.npmjs.com/package/...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~60-~60: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...I specs and handle OpenAPI requests. - [@orpc/zod](https://www.npmjs.com/package/@orp...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~61-~61: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...tps://zod.dev/) doesn't support yet. - [@orpc/valibot](https://www.npmjs.com/package/...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~62-~62: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...rom Valibot. - [@orpc/arktype](https://www.npmjs.com/package/...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🪛 Biome (1.9.4)
packages/standard-server-aws-lambda/src/event-iterator.ts
[error] 7-7: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 7-7: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 7-7: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 7-7: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 88-88: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 88-88: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
🔇 Additional comments (62)
packages/standard-server-aws-lambda/.gitignore (2)
6-15
: Generated folder ignores look comprehensive
The listed directories (logs/
,node_modules/
,out/
,dist/
,dist-ssr/
,build/
,coverage/
,temp/
) cover standard transient artifacts for this package. No issues found.
16-23
: Generated file ignores are appropriate
Ignoring log files, build artifacts (*.tsbuildinfo
,*.vitest-temp.json
), and timestamped Vite/Vitest configs aligns with expected outputs.tsconfig.json (1)
19-19
: Include new AWS Lambda adapter in project references
Integratingstandard-server-aws-lambda
into the root tsconfig ensures the new package is part of the monorepo build. Confirm the path matches the actual folder and that the package’s own tsconfig enables project references (composite: true
).packages/server/tsconfig.json (1)
9-9
: Add AWS Lambda reference to server package
Including"../standard-server-aws-lambda"
here allows the server package to compile against the Lambda adapter utilities. Ensurepackages/server/package.json
also lists@orpc/standard-server-aws-lambda
as a dependency.packages/openapi/src/adapters/aws-lambda/index.ts (1)
1-1
: Expose the new OpenAPI AWS Lambda handler
Re-exporting from./openapi-handler
makes theexperimental_OpenAPIHandler
available through the package entrypoint. Verify thatopenapi-handler.ts
exports the correct handler class.packages/standard-server-aws-lambda/src/types.test-d.ts (1)
1-6
: Verify AWS Lambda event type compatibility
This test correctly asserts thatawslambda.APIGatewayProxyEventV2
extends the localAPIGatewayProxyEventV2
. Ensure Vitest’sexpectTypeOf
is available and that@types/aws-lambda
is a dev dependency.packages/server/src/adapters/aws-lambda/index.ts (1)
1-2
: Consolidate AWS Lambda handler exports
Re-exporting bothhandler
andrpc-handler
provides a unified import surface. Looks correct; update documentation and package exports to cover this new entrypoint.packages/standard-server-aws-lambda/tsconfig.json (1)
1-19
: Well-configured TypeScript setup for the AWS Lambda package.The configuration properly extends the base library configuration, uses appropriate ES2022 features for AWS Lambda environments, and includes sensible exclusion patterns for test files. The project reference to the shared package is correctly configured.
packages/standard-server-aws-lambda/src/index.ts (1)
1-12
: LGTM! Clean and well-structured package entry point.The index file properly consolidates all package exports and provides a useful
ResponseStream
type alias that simplifies the interface for consumers. The type import syntax is correct and the re-exports follow standard patterns.🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 3-10: packages/standard-server-aws-lambda/src/index.ts#L3-L10
Added lines #L3 - L10 were not covered by testspackages/standard-server-aws-lambda/src/request.ts (1)
10-25
: Excellent lazy evaluation implementation!The
toStandardLazyRequest
function demonstrates well-thought-out lazy evaluation patterns:
- Headers lazy evaluation: The getter/setter pattern correctly computes headers on first access and caches the result using
Object.defineProperty
- Body lazy evaluation: Proper use of the
once
utility ensures the body is computed only when needed and cached for subsequent calls- Clean integration: All utility functions are properly leveraged for URL, headers, signal, and body conversion
The implementation efficiently handles AWS Lambda event conversion while maintaining performance through lazy evaluation.
packages/standard-server-aws-lambda/README.md (1)
1-78
: Comprehensive and well-structured documentation.The README follows the standard oRPC package format and provides excellent coverage of features, integrations, and usage. The content is informative and professionally presented.
Note: The static analysis style warnings about repetitive sentence beginnings in the packages list and "misspellings" of framework names like "Pinia Colada" and "Svelte" are acceptable in this context - the structured list format is appropriate and the flagged terms are proper names.
🧰 Tools
🪛 LanguageTool
[misspelling] ~33-~33: Possible spelling mistakes found.
Context: ...tack Query (React, Vue, Solid, Svelte), Pinia Colada, and more. - 🚀 Server Actions: Ful...(EN_MULTITOKEN_SPELLING_TWO)
[style] ~51-~51: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... your API or implement API contract. - [@orpc/client](https://www.npmjs.com/package/@...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~52-~52: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... API on the client with type-safety. - [@orpc/nest](https://www.npmjs.com/package/@or...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~53-~53: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...: Deeply integrate oRPC with NestJS. - [@orpc/react](https://www.npmjs.com/package/@o...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~54-~54: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...with React and React Server Actions. - [@orpc/react-query](https://www.npmjs.com/pack...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~55-~55: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...test/docs/framework/react/overview). - [@orpc/vue-query](https://www.npmjs.com/packag...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~56-~56: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...latest/docs/framework/vue/overview). - [@orpc/solid-query](https://www.npmjs.com/pack...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~57-~57: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...test/docs/framework/solid/overview). - [@orpc/svelte-query](https://www.npmjs.com/pac...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~58-~58: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...est/docs/framework/svelte/overview). - [@orpc/vue-colada](https://www.npmjs.com/packa...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[misspelling] ~58-~58: Possible spelling mistakes found.
Context: ...ge/@orpc/vue-colada): Integration with Pinia Colada. - [@or...(EN_MULTITOKEN_SPELLING_TWO)
[style] ~59-~59: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ada](https://pinia-colada.esm.dev/). - [@orpc/openapi](https://www.npmjs.com/package/...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~60-~60: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...I specs and handle OpenAPI requests. - [@orpc/zod](https://www.npmjs.com/package/@orp...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~61-~61: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...tps://zod.dev/) doesn't support yet. - [@orpc/valibot](https://www.npmjs.com/package/...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~62-~62: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...rom Valibot. - [@orpc/arktype](https://www.npmjs.com/package/...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
packages/openapi/src/adapters/aws-lambda/openapi-handler.ts (1)
1-17
: Clean composition pattern with excellent documentation.The
experimental_OpenAPIHandler
class demonstrates a well-designed composition pattern:
- Proper inheritance: Extends
AwsLambdaHandler<T>
to leverage AWS Lambda adapter functionality- Type-safe options: Correctly combines
StandardOpenAPIHandlerOptions<T>
andAwsLambdaHandlerOptions
using intersection types- Clean delegation: Creates
StandardOpenAPIHandler
internally and passes it to the parent constructor- Clear naming: The
experimental_
prefix appropriately indicates this is new functionality- Good documentation: JSDoc comments include relevant links to OpenAPI and HTTP adapter documentation
The implementation efficiently bridges OpenAPI functionality with AWS Lambda support.
packages/standard-server-aws-lambda/src/headers.test.ts (1)
18-32
: Test logic is correct for bidirectional header conversion.The test correctly verifies:
- Array headers are flattened with comma separation
- set-cookie headers are extracted to separate cookies array
- Undefined headers are filtered out
- Regular headers are preserved
The expected outputs match the
toLambdaHeaders
implementation from the relevant code snippets.packages/openapi/package.json (1)
42-47
: Export configuration looks consistent with existing adapters.The AWS Lambda adapter export follows the same pattern as other adapters (node, fetch, standard) with proper TypeScript types and ESM module configuration.
packages/standard-server-aws-lambda/package.json (1)
1-43
: Package configuration looks well-structured for a new AWS Lambda utilities package.The package.json follows standard conventions with proper:
- Metadata (name, version, license, repository)
- ES module configuration
- Export mappings for TypeScript and built files
- Workspace dependencies on shared and standard-server packages
- AWS Lambda types for development
The dependencies are appropriate for a utility package that provides AWS Lambda integration.
packages/server/package.json (3)
43-47
: AWS Lambda adapter export is properly configured.The export configuration follows the same pattern as other adapters with correct TypeScript types and ESM module paths.
81-81
: Export path is consistent with publishConfig.The development export correctly points to the TypeScript source file, maintaining consistency with other adapters.
113-113
: Dependency on standard-server-aws-lambda is correctly added.The workspace dependency is properly added, enabling the server package to use the AWS Lambda utilities for its adapter implementation.
packages/openapi/src/adapters/aws-lambda/openapi-handler.test.ts (3)
40-59
: Excellent test coverage for the matched route scenario.The test correctly verifies that:
- The handler returns
{ matched: true }
toStandardLazyRequest
is called with the correct parameterssendStandardResponse
is called with the expected response structureThe assertion on the response body structure confirms the handler correctly processes the input and returns the expected output format.
61-79
: Good test coverage for the mismatch scenario.The test properly verifies that when a route doesn't match:
- The handler returns
{ matched: false, response: undefined }
toStandardLazyRequest
is still called (as expected for request processing)sendStandardResponse
is not called (avoiding unnecessary response processing)
1-8
:✅ Verification successful
Verify import and mocking setup.
The mocking setup looks correct, but there's a potential issue with the import structure and module resolution.
Let me verify that the mocked functions are correctly imported and the module structure is as expected:
🏁 Script executed:
#!/bin/bash # Description: Verify the module structure and exports of @orpc/standard-server-aws-lambda # Check if the exports match what's being mocked ast-grep --pattern 'export $$ toStandardLazyRequest' ast-grep --pattern 'export $$ sendStandardResponse' # Check the OpenAPIHandler export ast-grep --pattern 'export $$ experimental_OpenAPIHandler'Length of output: 169
🏁 Script executed:
#!/bin/bash # Search for the actual exports in the repository rg "toStandardLazyRequest" -n rg "sendStandardResponse" -n rg "experimental_OpenAPIHandler" -nLength of output: 15024
Import and mocking setup verified
The exportstoStandardLazyRequest
,sendStandardResponse
, andexperimental_OpenAPIHandler
all exist and are re-exported correctly at the package entry points. Thevi.mock
calls inopenapi-handler.test.ts
match those exports, so no changes are needed.packages/standard-server-aws-lambda/src/request.test.ts (6)
1-11
: Well-structured test setup with proper spying.The test setup correctly uses
vi.spyOn
to monitor calls to the utility functions without fully mocking them, which allows testing the actual integration while still being able to verify the call patterns.
18-41
: Comprehensive and realistic test data.The mock API Gateway event includes all the essential fields with realistic values, including cookies, headers, request context, and body data. This provides good test coverage for the conversion function.
43-61
: Thorough verification of function integration.The test correctly verifies that:
- URL construction works properly
- Method is correctly extracted
- Signal, headers, and body are properly delegated to their respective conversion functions
- Function call patterns match expectations
63-79
: Excellent testing of lazy evaluation and override behavior.This test thoroughly verifies the lazy evaluation mechanism:
- Headers are not computed until first access
- Override before access works correctly
- Override after access works correctly
- Caching behavior is verified
The test design effectively validates the lazy evaluation contract.
81-95
: Good coverage of lazy body evaluation.The test verifies both override scenarios and caching behavior for the body property, ensuring the lazy evaluation works consistently across different properties.
97-111
:✅ Verification successful
Verify the event-stream test implementation.
The test for event-stream handling looks promising, but I want to verify that the input format and expected behavior align with the actual
toStandardBody
implementation.Let me check the event-stream parsing implementation:
🏁 Script executed:
#!/bin/bash # Description: Verify the event-stream parsing logic in toStandardBody # Check the toStandardBody implementation for event-stream handling ast-grep --pattern 'export function toStandardBody($$$) { $$$ }' # Check for event-stream related logic rg -A 10 'text/event-stream' rg -A 10 'isAsyncIteratorObject'Length of output: 90995
Event-stream test implementation verified
The SSE request test in
packages/standard-server-aws-lambda/src/request.test.ts
matches the actual parsing logic:
toStandardLazyRequest
delegates totoStandardBody
, which ontext/event-stream
calls_parseAsString
thentoEventIterator
toEventIterator
correctly parses"data: \"foo\""
into"foo"
and handles the finaldone
event yielding"bar"
withdone: true
No changes are required here.
apps/content/docs/adapters/http.md (1)
12-16
: Good addition to the adapter table.The table update clearly documents the new AWS Lambda adapter support alongside existing adapters, providing users with a comprehensive overview of available options.
packages/standard-server-aws-lambda/src/signal.test.ts (2)
5-21
: Good success case testing.The test correctly verifies that when a stream ends normally (via
stream.end()
), the abort signal remains unaborted. The timeout allows for asynchronous completion.
23-43
: Thorough error handling test.The test properly:
- Sets up an error listener to prevent unhandled error events
- Verifies the signal is aborted when the stream is destroyed with an error
- Checks that the abort reason matches the original error
- Uses
vi.waitFor
for proper async assertion handlingpackages/server/src/adapters/aws-lambda/rpc-handler.ts (3)
1-7
: LGTM! Clean and well-organized imports.The imports are properly structured and follow TypeScript conventions for separating type-only imports from value imports.
9-16
: LGTM! Well-designed options interface.The
RPCHandlerOptions
type effectively combines multiple option interfaces and adds the AWS Lambda-specificstrictGetMethodPluginEnabled
flag with a sensible default.
18-24
: LGTM! Good documentation and class structure.The class documentation with links to relevant docs is helpful, and the experimental prefix appropriately signals this is a new feature.
packages/standard-server-aws-lambda/src/headers.ts (2)
6-14
: LGTM! Simple and effective header conversion.The function correctly merges Lambda headers with cookies into the standard format. The use of spread operator and direct property assignment is appropriate here.
16-36
: LGTM! Robust reverse conversion with proper edge case handling.The function correctly:
- Skips undefined values
- Handles the special 'set-cookie' header case using
toArray
utility- Flattens other headers using the
flattenHeader
utility- Returns both headers and cookies as a tuple
The implementation is clean and handles edge cases appropriately.
packages/server/src/adapters/aws-lambda/rpc-handler.test.ts (5)
1-17
: LGTM! Proper test setup with effective mocking.The mocking strategy is well-designed:
- Mocks external dependencies appropriately
- Uses
vi.clearAllMocks()
for clean test isolation- Preserves the original module while mocking specific exports
19-40
: LGTM! Comprehensive test data setup.The test setup includes:
- Realistic handler configuration with different route methods
- Mock event and response stream objects
- Complete standard request object with all necessary properties
This provides good foundation for the test scenarios.
41-62
: LGTM! Thorough testing of successful route matching.The test properly verifies:
- Handler returns matched result
- Correct function calls with expected parameters
- Proper response format and content
- Integration between all mocked components
64-82
: LGTM! Good coverage of route mismatch scenario.The test correctly verifies:
- Handler returns unmatched result
- Request transformation still occurs
- Response sending is skipped appropriately
84-111
: LGTM! Excellent test for strict GET method enforcement.This test effectively demonstrates:
- The StrictGetMethodPlugin is enabled by default
- GET requests to non-GET routes result in 405 Method Not Allowed
- Proper error message formatting
- The plugin works correctly within the AWS Lambda context
This is a crucial test that validates the security feature works as expected.
packages/server/src/adapters/aws-lambda/handler.ts (4)
1-8
: LGTM! Well-organized imports with proper type separation.The imports are cleanly structured, separating type imports from value imports and importing from appropriate packages.
10-14
: LGTM! Clean interface and type definitions.The
AwsLambdaHandlerOptions
extendsSendStandardResponseOptions
appropriately, and theAwsLambdaHandleResult
provides a clear discriminated union for the result type.
16-24
: LGTM! Clean constructor with proper dependency injection.The constructor follows good patterns:
- Uses dependency injection for the standard handler
- Provides sensible defaults for options
- Stores options for later use in the handle method
26-43
: LGTM! Well-designed handle method with proper error handling.The method implementation is excellent:
- Converts Lambda event to standard request using the utility function
- Resolves options using the appropriate utility functions
- Delegates to the standard handler for business logic
- Handles both matched and unmatched cases appropriately
- Sends response only when matched
- Uses async/await properly throughout
The design follows the adapter pattern effectively, providing a clean interface between AWS Lambda and the standard handler.
packages/standard-server-aws-lambda/src/response.test.ts (6)
12-16
: Good test setup with proper AWS Lambda global mock.The mock setup correctly simulates the AWS Lambda runtime environment by providing a mock
HttpResponseStream.from
function.
20-54
: Comprehensive test for empty body scenario.The test properly verifies that:
toLambdaBody
is called with correct parameters- AWS Lambda HttpResponseStream is initialized with proper configuration
- No chunks are written for empty body
- Stream is properly closed
56-94
: Thorough test for JSON body handling.The test validates JSON serialization and proper content-type header setting. The assertion correctly expects the body to be converted to a Buffer containing the JSON string.
96-140
: Excellent streaming test with proper event-stream format verification.The test correctly validates:
- Event-stream headers are set appropriately
- Each yielded value is formatted as an event-stream message
- Proper Buffer format for chunks
142-195
: Robust error handling test with proper cleanup verification.This test excellently covers the edge case of stream destruction during sending, ensuring:
- Partial chunks are written before destruction
- Cleanup logic in generators is executed
- Error propagation works correctly
197-249
: Good coverage of stream destruction without error.This test complements the error case by testing normal stream destruction, ensuring the cleanup logic works in both scenarios.
packages/standard-server-aws-lambda/src/response.ts (2)
36-44
: Excellent stream error handling and cleanup.The implementation properly handles:
- Stream cleanup when response stream closes
- Error propagation from body stream to response stream
- Proper stream destruction with error context
14-16
: Good Promise-based error handling setup.The Promise setup correctly handles both error and close events from the response stream.
packages/standard-server-aws-lambda/src/types.ts (1)
3-17
: Consistent and well-structured auxiliary interfaces.All the helper interfaces follow a consistent pattern with proper optional string mapping. The structure aligns well with AWS Lambda's flexible header and parameter handling.
packages/standard-server-aws-lambda/src/event-iterator.test.ts (7)
7-39
: Excellent test coverage for event parsing with metadata.The test thoroughly validates:
- Event parsing with different metadata (id, retry)
- Proper handling of comments (ping)
- Correct event metadata extraction and attachment
74-106
: Comprehensive error event handling test.The test properly validates that error events are converted to
ErrorEvent
instances and thrown appropriately during iteration.
117-134
: Thorough stream generation test with return value.The test validates proper event stream formatting including:
- Correct event-stream syntax
- Metadata preservation (id, retry)
- Return value handling as "done" event
153-189
: Excellent error handling tests for both error types.The tests cover both regular Error objects and ErrorEvent instances, ensuring proper serialization and event formatting.
191-243
: Robust cancellation tests with proper cleanup verification.These tests ensure that:
- Generator finally blocks are executed on cancellation
- Stream destruction works correctly
- Both yielding and throwing scenarios are covered
245-276
: Comprehensive keep-alive functionality test.The test validates timing-sensitive keep-alive behavior with appropriate tolerances. The retry configuration suggests this test may be flaky due to timing, which is handled appropriately.
279-299
: Excellent integration test for round-trip conversion.This parameterized test ensures that data survives the stream→text→iterator conversion cycle, which is crucial for the event system's reliability.
packages/standard-server-aws-lambda/src/body.ts (1)
10-42
: Well-structured content type handling!The function correctly handles all major content types with appropriate fallbacks. The content-disposition check for file detection is implemented correctly.
packages/standard-server-aws-lambda/src/event-iterator.ts (1)
87-156
: Excellent implementation of event streaming with keep-alive!The function properly handles:
- Configurable keep-alive with sensible defaults
- Proper cleanup of intervals on completion/error
- Cancellation support with iterator cleanup
- Error event encoding
The resource management is particularly well done.
🧰 Tools
🪛 Biome (1.9.4)
[error] 88-88: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 88-88: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Tests
Chores