Skip to content

Commit 8d41049

Browse files
committed
fixes #102 add more documents
1 parent afb51a3 commit 8d41049

File tree

5 files changed

+31
-0
lines changed

5 files changed

+31
-0
lines changed

README.md

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -73,5 +73,15 @@ software.amazon.awssdk.services.lambda.model.ResourceNotFoundException: Function
7373
at java.base/java.lang.Thread.run(Thread.java:829)
7474
```
7575

76+
## Lambda Native Proxy
77+
78+
### [About](doc/about.md)
79+
### [Benefit](doc/benefit.md)
80+
### [Limitation](doc/limitation.md)
81+
### [Architecture](doc/architecture.md)
82+
### [Design](doc/design.md)
83+
84+
## Middleware Handlers
85+
7686
### [AuditMiddleware](doc/audit.md)
7787
### [LambdaProxyMiddleware](doc/proxy.md)

doc/about.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
Light Lambda Native Proxy Pattern is a new pattern for addressing Cross-Cutting Concerns(CCC) for Lambda functions deployed on AWS.
2+
3+
The new pattern will allow users to take advantage of the Light API Platform without an http-sidecar container on Kubernetes or a standalone light-gateway. It is a pure Lambda function that addresses all Cross-Cutting Concerns and then invokes the downstream business Lambda function that can be built with any language.
4+
5+
Although both http-sidecar and light-gateway can be used to address Cross-Cutting Concerns for Lambda functions, they add additional servers/services alongside native AWS services. For a team that is working with a Serverless environment, managing an HTTP sidecar container or a light gateway EC2 instance would be cumbersome and costly.

doc/architecture.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
The Native Lambda Proxy is implemented as a native Lambda function to address cross-cutting concerns for one or more business Lambda functions. It brings the business Lambda functions to the light-ecosystem as HTTP Rest API endpoints.
2+
3+
* Ingress:
4+
5+
6+
7+
* Egress:

doc/benefit.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
* Full Serverless: No need to manage containers on Kubernetes or standalone gateways.
2+
* Avoid Lock-In: Java Middleware Handlers can integrate with proprietary services and can be ported between cloud vendors.
3+
* Open Source: Cross-cutting concerns are supported by the Light-4j open-source community.
4+
* Code Generation: Scaffold a project based on the OpenAPI 3 specification with SAM template.
5+
* Configuration Driven: Lambda Native Proxy is deployed based on the configuration from the deployment pipeline for values.yml
6+
* Segregation of Concerns: Light Native Lambda will implement API CCC and the Lambda function API will implement business logic. Therefore, only Authentication and Authorization requests will invoke Business Lambda functions.
7+
* Friendly URL: Map AWS ALB auto-gen static DNS to friendly alias URL for VPC and Lambda Function URLs for the public cloud.

doc/limitation.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
* Requires one extra Lambda function (~40ms overhead for CCC handlers non-cold start)
2+
* Requires Application Load Balancer(ALB) or AWS API Gateway or Lambda Function URLs.

0 commit comments

Comments
 (0)