You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Tests/AWSLambdaRuntimeTests/LambdaRuntimeClientTest.swift
+18Lines changed: 18 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -191,6 +191,24 @@ class LambdaRuntimeClientTest: XCTestCase {
191
191
}
192
192
}
193
193
194
+
func testErrorResponseToJSON(){
195
+
// we want to check if quotes and back slashes are correctly escaped
196
+
letwindowsError=ErrorResponse(
197
+
errorType:"error",
198
+
errorMessage:#"underlyingError: "An error with a windows path C:\Windows\""#
199
+
)
200
+
letwindowsBytes= windowsError.toJSONBytes()
201
+
XCTAssertEqual(#"{"errorType":"error","errorMessage":"underlyingError: \"An error with a windows path C:\\Windows\\\""}"#,String(decoding: windowsBytes, as:Unicode.UTF8.self))
Or, a closure that receives a string payload and replies with the reverse version:
51
57
52
-
// in this example we are receiving and responding with codables. Request and Response above are examples of how to use
53
-
// codables to model your request and response objects
54
-
Lambda.run { (_, _: Request, callback) in
55
-
callback(.success(Response()))
56
-
}
57
-
```
58
+
```swift
59
+
importAWSLambdaRuntime
58
60
59
-
See a complete example in AWSLambdaRuntimeSample.
61
+
// in this example we are receiving and responding with strings
62
+
Lambda.run { (context, payload: String, callback) in
63
+
callback(.success(String(payload.reversed())))
64
+
}
65
+
```
66
+
67
+
See a complete example in AWSLambdaRuntimeSample.
60
68
61
69
3. Deploy to AWS Lambda. To do so, you need to compile your Application for Amazon 2 Linux, package it as a Zip file, and upload to AWS.
62
-
You can find sample build and deployment scripts in AWSLambdaRuntimeSample.
70
+
71
+
You can find sample build and deployment scripts in AWSLambdaRuntimeSample.
63
72
64
73
## Architecture
65
74
66
75
The library defined 3 base protcols for the implementation of a Lambda:
67
76
68
77
1.`ByteBufferLambdaHandler`: `EventLoopFuture` based processing protocol for a Lambda that takes a `ByteBuffer` and returns a `ByteBuffer?` asynchronously.
69
78
70
-
`ByteBufferLambdaHandler` is a low level protocol designed to power the higher level `EventLoopLambdaHandler` and `LambdaHandler` based APIs.
79
+
`ByteBufferLambdaHandler` is a low level protocol designed to power the higher level `EventLoopLambdaHandler` and `LambdaHandler` based APIs.
71
80
72
-
Most users are not expected to use this protocol.
81
+
Most users are not expected to use this protocol.
73
82
74
83
2.`EventLoopLambdaHandler`: Strongly typed, `EventLoopFuture` based processing protocol for a Lambda that takes a user defined `In` and returns a user defined `Out` asynchronously.
`EventLoopLambdaHandler` executes the Lambda on the same `EventLoop` as the core runtime engine, making the processing faster but requires more care from the implementation to never block the `EventLoop`.
87
+
`EventLoopLambdaHandler` executes the Lambda on the same `EventLoop` as the core runtime engine, making the processing faster but requires more care from the implementation to never block the `EventLoop`.
79
88
80
89
3.`LambdaHandler`: Strongly typed, callback based processing protocol for a Lambda that takes a user defined `In` and returns a user defined `Out` asynchronously.
`LambdaHandler` offloads the Lambda execution to a `DispatchQueue` making processing safer but slower.
93
+
`LambdaHandler` offloads the Lambda execution to a `DispatchQueue` making processing safer but slower.
94
+
95
+
In addition to protocol based Lambda, the library provides support for Closure based ones, as demonstrated in the getting started section.
85
96
86
-
In addition to protocol based Lambda, the library provides support for Closure based ones, as demosrated in the getting started section.
87
97
Closure based Lambda are based on the `LambdaHandler` protocol which mean the are safer but slower.
88
98
For most use cases, Closure based Lambda is a great fit.
99
+
89
100
Only performance sensitive use cases should explore the `EventLoopLambdaHandler` protocol based approach as it requires more care from the implementation to never block the `EventLoop`.
90
101
91
102
The library includes built-in codec for `String` and `Codable` into `ByteBuffer`, which means users can express `String` and `Codable` based Lambda without the need to provide encoding and decoding logic.
103
+
92
104
Since AWS Lambda is primarily JSON based, this covers the most common use cases.
93
-
The design does allow for other payload types as well, and such Lambda implementaion can extend one of the above protocols and provided their own `ByteBuffer` -> `In` decoding and `Out` -> `ByteBuffer` encoding.
94
105
106
+
The design does allow for other payload types as well, and such Lambda implementation can extend one of the above protocols and provided their own `ByteBuffer` -> `In` decoding and `Out` -> `ByteBuffer` encoding.
95
107
96
-
The library is designed to integrate with AWS Lambda Runtime Engine, via the BYOL Native Runtime API.
97
-
The latter is an HTTP server that exposes three main RESTful endpoint:
108
+
The library is designed to integrate with AWS Lambda Runtime Engine, via the BYOL Native Runtime API. The latter is an HTTP server that exposes three main RESTful endpoint:
98
109
*`/runtime/invocation/next`
99
110
*`/runtime/invocation/response`
100
111
*`/runtime/invocation/error`
@@ -104,17 +115,27 @@ The library encapsulates these endpoints and the expected lifecycle via `Lambda.
104
115
**Single Lambda Execution Workflow**
105
116
106
117
1. The library calls AWS Lambda Runtime Engine `/next` endpoint to retrieve the next invocation request.
118
+
107
119
2. The library parses the response HTTP headers and populate the `Lambda.Context` object.
120
+
108
121
3. The library reads the response body and attempt to decode it, if required.
109
-
Typically it decodes to user provided type which extends `Decodable`, but users may choose to write Lambdas that receive the input as `String` or `ByteBuffer` which require less, or no decoding.
122
+
Typically it decodes to user provided type which extends `Decodable`, but users may choose to write Lambdas that receive the input as `String` or `ByteBuffer` which require less, or no decoding.
123
+
110
124
4. The library hands off the `Context` and `Request` to the user provided handler.
111
-
In the case of `LambdaHandler` based Lambda this is done on a dedicated `DispatchQueue`, providing isolation between user's and the library's code.
125
+
In the case of `LambdaHandler` based Lambda this is done on a dedicated `DispatchQueue`, providing isolation between user's and the library's code.
126
+
112
127
5. User's code processes the request asynchronously, invoking a callback or returning a future upon completion, which returns a result type with the `Response` or `Error` populated.
128
+
113
129
6. In case of error, the library posts to AWS Lambda Runtime Engine `/error` endpoint to provide the error details, which will show up on AWS Lambda logs.
130
+
114
131
7. In case of success, the library will attempt to encode the response, if required.
115
-
Typically it encodes from user provided type which extends `Encodable`, but users may choose to write Lambdas that return a `String` or `ByteBuffer`, which require less, or no encoding.
116
-
The library then posts to AWS Lambda Runtime Engine `/response` endpoint to provide the response.
132
+
Typically it encodes from user provided type which extends `Encodable`, but users may choose to write Lambdas that return a `String` or `ByteBuffer`, which require less, or no encoding.
133
+
The library then posts to AWS Lambda Runtime Engine `/response` endpoint to provide the response.
117
134
118
135
**Lifecycle Management**
119
136
120
-
AWS Runtime Engine controls the Application lifecycle and in the happy case never terminates the application, only suspends it's execution when no work is avaialble. As such, the library main entry point is designed to run forever in a blocking fashion, performing the workflow described above in an endless loop. That loop is broken if/when an internal error occurs, such as a failure to communicate with AWS Runtime Engine API, or under other unexpected conditions.
137
+
AWS Lambda Runtime Engine controls the Application lifecycle and in the happy case never terminates the application, only suspends it's execution when no work is avaialble.
138
+
139
+
As such, the library main entry point is designed to run forever in a blocking fashion, performing the workflow described above in an endless loop.
140
+
141
+
That loop is broken if/when an internal error occurs, such as a failure to communicate with AWS Lambda Runtime Engine API, or under other unexpected conditions.
0 commit comments