|
1 | 1 | # lambda-api |
2 | | -**PLEASE NOTE:** This project is still in beta and should be used with caution in production. |
3 | 2 |
|
4 | 3 | [](https://travis-ci.org/jeremydaly/lambda-api) |
5 | 4 | [](https://www.npmjs.com/package/lambda-api) |
6 | 5 | [](https://www.npmjs.com/package/lambda-api) |
7 | 6 |
|
8 | 7 | ### Lightweight Node.js API for AWS Lambda |
9 | 8 |
|
10 | | -Lambda API is a lightweight Node.js API router for use with AWS API Gateway and AWS Lambda using Lambda Proxy integration. This closely mirrors (and is based on Express.js) but is significantly stripped down to maximize performance with Lambda's stateless, single run executions. The API uses Bluebird promises to serialize asynchronous execution. |
| 9 | +Lambda API is a lightweight Node.js API router for use with AWS API Gateway and AWS Lambda using Lambda Proxy integration. This closely mirrors (and is based on) other routers like Express.js but is significantly stripped down to maximize performance with Lambda's stateless, single run executions. The API uses Bluebird promises to serialize asynchronous execution. |
| 10 | + |
| 11 | +## Simple Example |
| 12 | + |
| 13 | +```javascript |
| 14 | +const API = require('lambda-api') // API library |
| 15 | + |
| 16 | +// Init API instance |
| 17 | +const api = new API({ version: 'v1.0', base: 'v1' }); |
| 18 | + |
| 19 | +api.get('/test', function(req,res) { |
| 20 | + res.status(200).json({ status: 'ok' }) |
| 21 | +}) |
| 22 | + |
| 23 | +module.exports.handler = (event, context, callback) => { |
| 24 | + |
| 25 | + // Run the request |
| 26 | + api.run(event,context,callback); |
| 27 | + |
| 28 | +} // end handler |
| 29 | +``` |
11 | 30 |
|
12 | 31 | ## Lambda Proxy integration |
13 | 32 | Lambda Proxy Integration is an option in API Gateway that allows the details of an API request to be passed as the `event` parameter of a Lambda function. A typical API Gateway request event with Lambda Proxy Integration enabled looks like this: |
@@ -73,26 +92,6 @@ Lambda Proxy Integration is an option in API Gateway that allows the details of |
73 | 92 |
|
74 | 93 | The API automatically parses this information to create a normalized `REQUEST` object. The request can then be routed using the APIs methods. |
75 | 94 |
|
76 | | -## Simple Example |
77 | | - |
78 | | -```javascript |
79 | | -const API = require('lambda-api') // API library |
80 | | - |
81 | | -// Init API instance |
82 | | -const api = new API({ version: 'v1.0', base: 'v1' }); |
83 | | - |
84 | | -api.get('/test', function(req,res) { |
85 | | - res.status(200).json({ status: 'ok' }) |
86 | | -}) |
87 | | - |
88 | | -module.exports.handler = (event, context, callback) => { |
89 | | - |
90 | | - // Run the request |
91 | | - api.run(event,context,callback); |
92 | | - |
93 | | -} // end handler |
94 | | -``` |
95 | | - |
96 | 95 | ## Configuration |
97 | 96 |
|
98 | 97 | Include the `lambda-api` module into your Lambda handler script and initialize an instance. You can initialize the API with an optional `version` which can be accessed via the `REQUEST` object and a `base` path. The base path can be used to route multiple versions to different instances. |
@@ -144,6 +143,7 @@ The `REQUEST` object contains a parsed and normalized request from API Gateway. |
144 | 143 | - If the `Content-Type` header is `application/x-www-form-urlencoded`, it will attempt to parse a URL encoded string using `querystring` |
145 | 144 | - Otherwise it will be plain text. |
146 | 145 | - `route`: The matched route of the request |
| 146 | +- `requestContext`: The `requestContext` passed from the API Gateway |
147 | 147 |
|
148 | 148 | The request object can be used to pass additional information through the processing chain. For example, if you are using a piece of authentication middleware, you can add additional keys to the `REQUEST` object with information about the user. See [middleware](#middleware) for more information. |
149 | 149 |
|
@@ -248,6 +248,17 @@ api.use(function(req,res,next) { |
248 | 248 |
|
249 | 249 | The `next()` callback tells the system to continue executing. If this is not called then the system will hang and eventually timeout unless another request ending call such as `error` is called. You can define as many middleware functions as you want. They will execute serially and synchronously in the order in which they are defined. |
250 | 250 |
|
| 251 | +### Clean Up |
| 252 | +The API has a built-in clean up method called 'finally()' that will execute after all middleware and routes have been completed, but before execution is complete. This can be used to close database connections or to perform other clean up functions. A clean up function can be defined using the `finally` method and requires a function with two parameters for the REQUEST and the RESPONSE as its only argument. For example: |
| 253 | + |
| 254 | +```javascript |
| 255 | +api.finally(function(req,res) { |
| 256 | + // close unneeded database connections and perform clean up |
| 257 | +}) |
| 258 | +``` |
| 259 | + |
| 260 | +The `RESPONSE` **CANNOT** be manipulated since it has already been generated. Only one `finally()` method can be defined. This uses the Bluebird `finally()` method internally and will execute after properly handled errors as well. |
| 261 | + |
251 | 262 | ## Error Handling |
252 | 263 | The API has simple built-in error handling that will log the error using `console.log`. These will be available via CloudWatch Logs. By default, errors will trigger a JSON response with the error message. If you would like to define additional error handling, you can define them using the `use` method similar to middleware. Error handling middleware must be defined as a function with **four** arguments instead of three like normal middleware. An additional `error` parameter must be added as the first parameter. This will contain the error object generated. |
253 | 264 |
|
|
0 commit comments