Utilities for simplifying development with AWS Serverless technologies. Its objective is to reduce the amount of boilerplate code required to develop and deploy serverless applications.
npm install @apigrate/aws-serverlessIts mission is threefold:
1. reduce the amount of boilerplate code required to develop and deploy serverless applications.
2. make it easier to deploy different kinds of Lambda functions to the AWS cloud
3. encourage development of stack-agnostic business logic. In other words, help write business code that is functionally independent of AWS; allowing it to be repurposed/redployed on other infrastructure with a minimum of rewriting.
This library helps you achieve the goal of having reusable business logic in your backend code with minimal hard-coded platform dependencies.
It imposes a pattern to use when declaring your lambda entry point file.
Processors encapsulate your business logic. Unless performing functions explicitly using Amazon Web Services, you should strive to minimize their dependencies on any AWS infrastructure. This will make them more reusable in other contexts. Of course, there are times when you want to invoke AWS operations such as enqueing records in SQS etc. We have provided some useful processors that work a out-of-the box.
Intended as an abstract class for any custom processor you create. Override the process method. This method receives payload, event, and context from the handler.
A configurable processor that enqueues whatever payload it receives to an SQS queue.
Configurable processor that builds an OAuth 2.0 authorization code workflow URL to start the Oauth process with a provider. It uses AWS S3 to store a state variable that is used to secure the callback portion of the process against man-in-the-middle attacks.
Configurable processor that handles the OAuth 2.0 authorization code callback. It automatically performs validation of a stored state variable (see OAuthS3Initializer, above), handles the code-for-token exchange, and then stores the OAuth credentials in a configurable S3 location.
Handlers perform generalized handling of AWS events, providing payload, event, and context information to your processors. Those included implement default functionality that is fairly commonplace, thus helping cut down on boilerplate, repetitive code. In your serverless entry point, you typically declare your processor, and then inject it your handler definition. Handlers feature a .lambda() method that allows you easily mark the lambda handlers in your entry point NodeJS file.
Event-agnostic handler that can be used with AWS services. Typically it is used for handling CloudWatch events. No automatic payload is passed eventProcessor, but the event and context are still available.
Handles API gateway events, automatically providing the HTTP payload to the configured eventProcessor.
Specialized API handler that issues a redirection response based on your eventProcessor, redirection configuration, or both.
Handler that receives SQS queue data. Use this handler to receive enqueued payloads, passing the queued message to your eventProcessor automatically from SQS to process it.
Simple API lambda-authorizer function that validates HTTP requests contain a Bearer token that matches the expected configuration.
Handler provides built-in configuration-based retry-handling from a dead-letter queue that it monitors.