Re:The DynamoDB Book: Data Modeling with NoSQL and DynamoDB
by mmbleh on Friday May 15, 2020 @08:15PM
(#23199073)
Yup, that's exactly how I recommend clients to write lambdas for API purposes... Such a great balance of getting per request pricing while retaining all existing tooling for building APIs
Re:The DynamoDB Book: Data Modeling with NoSQL and DynamoDB
by scarface74 on Friday May 15, 2020 @08:39PM
(#23199257)
For an internal API with one or two endpoints, I‘ll do things the native Lambda way. Your standard frameworks are heavy when all you need to do is respond to one or two events and you can do your own routing, use APIGW and API Key for authorization, etc.
There is also a threshold between “A group of developers will be developing this API and type safety would be nice so let’s use C#” and “I can write and debug this entire 20-50 line thing in the web console in Python, configure it using the GUI, and export a SAM CloudFormation template for our deployment pipeline.”
We deploy our APIs to Fargate for low, predictable latency for our customers and to Lambda [1] which handles scaling up like crazy and scaling down to 0 for internal use but where latency isn’t a concern.
Our pipeline deploys to both.
[1] As far as being “locked into lambda”, that’s not a concern. With API Gateway “proxy integration” you just add three or four lines of code to your Node/Express, C#/WebAPI, Python/Flask code and you can deploy your code as is to lambda. It’s just a separate entry point.
https://github.com/awslabs/aws-serverless-express
https://aws.amazon.com/blogs/developer/deploy-an-existing-as...