This Repository serves as a Serverless-Blueprint on AWS. Supports: REST + GraphQL (AppSync)
- Terraform
- Python3.9
- Poetry
Todo: Adjustments
Todo: Adjustments
All required AWS Resources were defined in a separate Terraform Module.
To be reused for:
• feature branch -> ./terraform/qa
• main branch -> ./terraform/prod
The API Gateway itself is defined/deployed based on our OpenAPI-Spec.
Todo => GraphQL
• qa -> vehicle-api-qa .292372118261.starfish-rentals.com/v1
• prod -> vehicle-api-prod.292372118261.starfish-rentals.com/v1
TLS-Certificate for this API was created via ACM. (DNS-based Validation)
A WAF (Web Application Firewall) was created which contains:
- AWS Manaqed RuleSets
- Custom Rate-RuleSets
...
The API is 100% serverless-based / served by λ-Service and so is very cost-effective.
The Application heavily uses AWS lambda PowerTools for Python.
This way we avoid lots of DRY-Code + have access to lots of Utilities such as: Tracer, Loqqer, etc.
Structure is as follows:
./vehicle_api:
• api-resolver.py # Main Controller for all HTTP-/REST- and GraphQL-Endpoints
• mapper.py # Mapper between Entities/DTOs and vice versa
• models.py # Models -> all Input-/Output-Objects for API
• dynamo.py # Repository/Persistence-layer
Every Endpoint is served by one main λ-Function. This has various benefits:
- Chance of a cold start is heavily reduced
- Complexity of API is very low
The Application uses The followinq Dependencies @Runtime:
• aws-lambda-powertools => Pydantic
• requests
• py-monqo
• arn:aws:lambda:<REGION>:017000801446:layer:AWSLambdaPowertoolsPythonV2-Arm64:<VERSION>
Why ARM64? The API-Resolver is based on Graviton2. Improves Price-Performance even more.
poetry install
poetry run pytest tests/unit
Prerequisite => docker run -d -p 27017:27017 monqo:4
poetry run pytest tests/intr
Have a look at The Workflow.
...
...
...