Introduction
This library was a refactored version of @vendia/serverless-express, I create a new way to interact and extend event sources by creating contracts to abstract the integrations between each library layer.
Why you would use this libray instead of @vendia/serverless-express?
- Better APIs to extend library functionality.
- You don't need me to release a new version to integrate with the new event source, you can create an adapter and
just call the
addAdapter
method when building your handler.
- You don't need me to release a new version to integrate with the new event source, you can create an adapter and
just call the
- All code can be extended, if you want to modify the current behavior you can.
- This is important because if you find a bug, you can quickly resolve it by extending the class, and then you can submit a PR to fix the bug.
- All code was written in Typescript.
- Well documented, any method, class, or interface has comments to explain the behavior.
- We have >99% coverage.
Support
By design we have these contracts that define the layers of the library: Frameworks, Adapters, Resolvers and Handlers.
If you don't know what each thing means, see Architecture.
Currently, we support these clouds (handlers):
- Azure by using (AzureHandler)
- AWS by using (DefaultHandler)
- For AWS Lambda Response Streaming, you should use (AwsStreamHandler)
- Digital Ocean by using (DigitalOceanHandler)
- Firebase by using (HttpFirebaseHandler)
- Huawei by using (HttpHuaweiHandler) and (EventHuaweiHandler)
Additionally, we support these frameworks:
- Apollo Server by using (ApolloServerFramework)
- Deepkit by using (HttpDeepkitFramework)
- Express by using (ExpressFramework)
- Fastify by using (FastifyFramework)
- Hapi by using (HapiFramework)
- Koa by using (KoaFramework)
- NestJS, see the documentation about to know how to integrate.
- tRPC, see the documentation about to know how to integrate.
Additionally, we have some helper frameworks that you can combine with the above frameworks to give more power to your application:
- Async Initialization by using (LazyFramework)
- Use this framework to provide a way to create the instance of your app asynchronously.
- With him, you can create an instance of Express or Fastify asynchronously, see the docs.
- CORS support without rely on original framework with (CorsFramework)
- Use this framework to provide a way to handle CORS in frameworks like
trpc
,deepkit
and others. - Or use to get faster responses when method is
OPTIONS
.
- Use this framework to provide a way to handle CORS in frameworks like
- Content Type parsing support without rely on original framework with (BodyParserFramework)
- Use this framework to provide a way to handle content type parsing in frameworks like
trpc
,deepkit
and others.
- Use this framework to provide a way to handle content type parsing in frameworks like
We support these event sources:
- AWS
- AWS Load Balancer by using (AlbAdapter)
- AWS Api Gateway V1 by using (ApiGatewayV1Adapter)
- AWS Api Gateway V2 by using (ApiGatewayV2Adapter)
- AWS Lambda Function URLs by using (ApiGatewayV2Adapter)
- AWS DynamoDB by using (DynamoDBAdapter)
- AWS Event Bridge / CloudWatch Events by using (EventBridgeAdapter)
- AWS Lambda Edge by using (LambdaEdgeAdapter)
- AWS SNS by using (SNSAdapter)
- AWS SQS by using (SQSAdapter)
- AWS S3 by using (S3Adapter)
- Huawei
- Http Function: Look this section.
- Event Function: Look this section.
- Api Gateway by using (HuaweiApiGatewayAdapter).
- Azure
- Http Trigger V4 by using (HttpTriggerV4Adapter).
- Digital Ocean
- Functions by using DigitalOceanHandler.
- Firebase
- Http Events using (HttpFirebaseHandler and HttpFirebaseV2Handler).
- Google Cloud Functions (GCP)
- Http Functions using (GCPHandler).
We support these resolvers:
- Promise by using (PromiseResolver)
- Callback by using (CallbackResolver)
- AWS Context by using (AwsContextResolver)
Why you create this library?
The real reason I created this library was because I wanted to add API Gateway and SQS support at the same time to save
some money. But, @vendia/serverless-express was not supported, so
I created a PR but until I finished this library that PR was never accepted and it was merged but it took so long.
So I build my own library based on that library with better APIs so I never have to wait for the maintainer to accept my PR just to extend the library's functionality :)
Breaking Changes
I will not consider updating/breaking compatibility of a NodeJS framework as a breaking change, because I had a lot of supported frameworks and if I created a major version for each one it would be a mess.
So if you want predictability, pin the version with ~
instead of ^
.
Credits
Honestly, I just refactored all the code that the @vendia team and many other contributors wrote, thanks so much to them for existing and giving us a brilliant library that is the core of my current company.