Gathering detailed insights and metrics for aws-lambda-fastify
Gathering detailed insights and metrics for aws-lambda-fastify
Gathering detailed insights and metrics for aws-lambda-fastify
Gathering detailed insights and metrics for aws-lambda-fastify
@types/aws-lambda-fastify
TypeScript definitions for aws-lambda-fastify
@fastify/aws-lambda
Inspired by aws-serverless-express to work with Fastify with inject functionality.
@aws-sdk/client-lambda
AWS SDK for JavaScript Lambda Client for Node.js, Browser and React Native
@whatwg-node/server
Fetch API compliant HTTP Server adapter
npm install aws-lambda-fastify
88
Supply Chain
47.9
Quality
83.1
Maintenance
100
Vulnerability
100
License
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
511 Stars
300 Commits
34 Forks
11 Watching
3 Branches
26 Contributors
Updated on 17 Nov 2024
Minified
Minified + Gzipped
JavaScript (94.41%)
TypeScript (5.59%)
Cumulative downloads
Total Downloads
Last day
-2.8%
3,277
Compared to previous day
Last week
-0.9%
17,417
Compared to previous week
Last month
-33.1%
82,866
Compared to previous month
Last year
85%
1,202,657
Compared to previous year
2
Inspired by the AWSLABS aws-serverless-express library tailor made for the Fastify web framework.
No use of internal sockets, makes use of Fastify's inject function.
Seems faster (as the name implies) than aws-serverless-express and aws-serverless-fastify 😉
1$ npm i @fastify/aws-lambda
@fastify/aws-lambda can take options by passing them with : awsLambdaFastify(app, options)
property | description | default value |
---|---|---|
binaryMimeTypes | Array of binary MimeTypes to handle | [] |
enforceBase64 | Function that receives the response and returns a boolean indicating if the response content is binary or not and should be base64-encoded | undefined |
serializeLambdaArguments | Activate the serialization of lambda Event and Context in http header x-apigateway-event x-apigateway-context | false (was true for <v2.0.0) |
decorateRequest | Decorates the fastify request with the lambda Event and Context request.awsLambda.event request.awsLambda.context | true |
decorationPropertyName | The default property name for request decoration | awsLambda |
callbackWaitsForEmptyEventLoop | See: Official Documentation | undefined |
retainStage | Retain the stage part of the API Gateway URL | false |
pathParameterUsedAsPath | Use a defined pathParameter as path (i.e. 'proxy' ) | false |
parseCommaSeparatedQueryParams | Parse querystring with commas into an array of values. Affects the behavior of the querystring parser with commas while using Payload Format Version 2.0 | true |
1const awsLambdaFastify = require('@fastify/aws-lambda') 2const app = require('./app') 3 4const proxy = awsLambdaFastify(app) 5// or 6// const proxy = awsLambdaFastify(app, { binaryMimeTypes: ['application/octet-stream'], serializeLambdaArguments: false /* default is true */ }) 7 8exports.handler = proxy 9// or 10// exports.handler = (event, context, callback) => proxy(event, context, callback) 11// or 12// exports.handler = (event, context) => proxy(event, context) 13// or 14// exports.handler = async (event, context) => proxy(event, context)
1const fastify = require('fastify') 2 3const app = fastify() 4app.get('/', (request, reply) => reply.send({ hello: 'world' })) 5 6if (require.main === module) { 7 // called directly i.e. "node app" 8 app.listen({ port: 3000 }, (err) => { 9 if (err) console.error(err) 10 console.log('server listening on 3000') 11 }) 12} else { 13 // required as a module => executed on aws lambda 14 module.exports = app 15}
When executed in your lambda function we don't need to listen to a specific port,
so we just export the app
in this case.
The lambda.js
file will use this export.
When you execute your Fastify application like always,
i.e. node app.js
(the detection for this could be require.main === module
),
you can normally listen to your port, so you can still run your Fastify function locally.
The original lambda event and context are passed via Fastify request and can be used like this:
1app.get('/', (request, reply) => { 2 const event = request.awsLambda.event 3 const context = request.awsLambda.context 4 // ... 5})
If you do not like it, you can disable this by setting the decorateRequest
option to false
.
Alternatively the original lambda event and context are passed via headers and can be used like this, if setting the serializeLambdaArguments
option to true
:
1app.get('/', (request, reply) => {
2 const event = JSON.parse(decodeURIComponent(request.headers['x-apigateway-event']))
3 const context = JSON.parse(decodeURIComponent(request.headers['x-apigateway-context']))
4 // ...
5})
Since AWS Lambda now enables the use of ECMAScript (ES) modules in Node.js 14 runtimes, you could lower the cold start latency when used with Provisioned Concurrency thanks to the top-level await functionality.
We can use this by calling the fastify.ready()
function outside of the Lambda handler function, like this:
1import awsLambdaFastify from '@fastify/aws-lambda' 2import app from './app.js' 3export const handler = awsLambdaFastify(app) 4await app.ready() // needs to be placed after awsLambdaFastify call because of the decoration: https://github.com/fastify/aws-lambda-fastify/blob/master/index.js#L9
Here you can find the approriate issue discussing this feature.
@fastify/aws-lambda (decorateRequest : false) x 56,892 ops/sec ±3.73% (79 runs sampled)
@fastify/aws-lambda x 56,571 ops/sec ±3.52% (82 runs sampled)
@fastify/aws-lambda (serializeLambdaArguments : true) x 56,499 ops/sec ±3.56% (76 runs sampled)
serverless-http x 45,867 ops/sec ±4.42% (83 runs sampled)
aws-serverless-fastify x 17,937 ops/sec ±1.83% (86 runs sampled)
aws-serverless-express x 16,647 ops/sec ±2.88% (87 runs sampled)
Fastest is @fastify/aws-lambda (decorateRequest : false), @fastify/aws-lambda
The logos displayed in this page are property of the respective organisations and they are not distributed under the same license as @fastify/aws-lambda (MIT).
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
14 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 10
Reason
0 existing vulnerabilities detected
Reason
license file detected
Details
Reason
security policy file detected
Details
Reason
SAST tool is not run on all commits -- score normalized to 9
Details
Reason
Found 3/9 approved changesets -- score normalized to 3
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Score
Last Scanned on 2024-11-25
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More