
Full Guide to Developing REST API’s with AWS API Gateway and AWS Lambda - daftpanda
https://blog.sourcerer.io/full-guide-to-developing-rest-apis-with-aws-api-gateway-and-aws-lambda-d254729d6992
======
dayjah
IME the AWS GUI is not useful for all that much in a meaningful context. Thus
this post is pretty misleading to a new person getting involved in cloud; it
doesn’t qualify as “full” in my mind.

As a number of other comments have pointed out, there are packages that help
with managing your infrastructure in code; which is critical outside of
anything other than a play environment. Terraform, serverless, cloudformation,
SAM, zappa, etc - are all essentially requirements for cloud usage.

At Amazon they’ve tooling which makes it relatively easy to set up an AWS
account to develop against; the tool primarily configures the billing to the
correct team within amazon. Additionally your manager gets “rights” to the
account, IAM accounts can be linked to AD, etc, etc. This is all part of a
push to get Amazon employees building infra on AWS proper. When you create the
environment you have to denote whether it’s dev, or whether it’s production;
in the former case it’s widely accepted that you use the GUI to set up your
trial. However in the latter case you’re _strongly_ encouraged to use
something like cloudformation. It was always a shock to me that for prod
accounts they don’t disable the GUI for anything other than viewing.

~~~
matchagaucho
My experience... while Lambda is capable of hosting micro-services, any coding
pipeline that emphasizes continuous integration (CI) will be better served
with one, generic, monolithic Lambda function that dispatches to sub-modules
behind the scenes.

However, this only scales up to a 50MB binary distributable.

~~~
dayjah
Oh, interesting - can you share some information as to why you think the
monolithic approach is best?

~~~
matchagaucho
Our use of Lambda runs in a VPC, so each new function requires a lot of manual
network I/O and IAM configuration to trust the function.

A single monolithic JAR was the fastest way to close the feedback loop between
idea, prototype, deploy, and validate.

Wouldn't say this is _best_. Just faster. Every retrospective is an
opportunity to explore use of cloud formation, or some templated deployment
model.

------
piotrkubisa
I am not sure if 'Full Guide' in title of the article made me smiling or maybe
it was recall of my experiences related to configuration of AWS Lambda and AWS
API Gateway in CloudFormation. There is a lot of things which has not been
mentioned in this article and it is what I am looking forward to - even
trivial things which looks easy at the first glance, i.e.:

* How to configure caching and caching rules - please note there are few ways (query strings, headers, parameters, cache enabled only on single method etc.) to specify how to cache responses.

* Attach your REST API on custom domain as a regional endpoint (instead of edge-optimized, since regional endpoints are more configurable)- create ACM certificate (per each region, and one for CloudFront), create own CloudFront distribution (think: multi region deployment), add DNS record in Route53 and configure WAF (some magic DDoS protection).

I took me a lot of time with CloudFormation to get through where I am today
and yet I think I would be grateful if someone will share his knowledge gained
on more sophisticated use-cases than just 'Hello World'.

~~~
k__
I'm using AWS SAM, which simplifies much, but couldn't setup CORS with it.

~~~
piotrkubisa
I were using SAM for month or two and then switched back to CloudFormation,
because I felt limited (not all features of API Gateway were implemented,
duplicated stages, problems with instrict functions). However, I watch their
GitHub repository for changes and I noticed many missing features are
implemented on AWS re:invent basis (duration between next conference). The
worth-noting feature of SAM is definetely aws-sam-cli (former: aws-sam-local)
[1], which is a tool for developers to parse SAM template and invoke Lambda
function in the docker on local machine. It was great to test simple APIs
(start-api mode), but when some API started using custom authorizers or
response was a compressed payload of png image it was not very helpful.
Personally, I am working on a fork of aws-sam-cli to implement it to work with
CloudFormation.

[1]: [https://github.com/awslabs/aws-sam-cli](https://github.com/awslabs/aws-
sam-cli)

~~~
k__
Isn't SAM just an extension of CloudFormation?

It allows you the SAM simplifications, but also all the CF stuff.

~~~
piotrkubisa
Yes, it adds a new custom types AWS::Serverless::* [1] and new Globals section
[2] and it is really pleasant to work with for basic, not complicated API. It
is transformed into CF template via samtranslator [3] (recently open-sourced)
so it inherits a lot from CloudFormation but also that's why I encountered
differences between SAM and CF types.

[1]: [https://awslabs.github.io/serverless-application-
model/inter...](https://awslabs.github.io/serverless-application-
model/internals/generated_resources.html)

[2]: [https://awslabs.github.io/serverless-application-
model/globa...](https://awslabs.github.io/serverless-application-
model/globals.html)

[3]: [https://github.com/awslabs/serverless-application-
model/tree...](https://github.com/awslabs/serverless-application-
model/tree/develop/samtranslator)

------
radmin
AWS provides their own "Python Serverless Microframework for AWS" called
Chalice: [https://github.com/aws/chalice](https://github.com/aws/chalice)

I have yet to deploy a production service with it, but the development
experience has been positive.

------
nzoschke
Nice guide.

Going through the motions of setting up my first API Gateway and Lambda was
eye opening to me.

There are a ton of options in these two services — rate limiting, authorizers,
concurrency, monitoring, etc. — that point to how much power you gain building
an app like this.

If you’d like to see an automated, infrastructure-as-code approach to setting
up an API, check out my boilerplate app:

[https://github.com/nzoschke/gofaas](https://github.com/nzoschke/gofaas)

------
davidjnelson
I wonder if I'm missing something. Given 10 minutes of load for pre warming, I
was getting 95th percentile times of 1.6 seconds with a bare minimum node
lambda hello world function. I threw 1,000 concurrent requests at it across 4
threads, with a 1,000 concurrent execution limit configuration on aws.

I was really excited about lambda, but that is flat out terrible performance
for a lot of users. Is this not an issue for others? Why not?

~~~
nstj
My results have been similar.

~~~
davidjnelson
Given that, I wonder why people keep writing about it? I get the appeal for an
internal app or a background job, but for a public facing rest/graphql api?
Seems like the performance isn't there.

------
Mizza
Alternately:

``` from flask import Flask app=Flask() @app.route(‘/‘) def hi(): return "Hi!”
```

$ pip install zappa

$ zappa init

$ zappa deploy

$ zappa certify

IAM, SSL, API Gateway, Lambda, all taken care of. We did the work so you don't
have to.

~~~
Lord_Zero
If using NodeJS there is a very similar package to zappa called Serverless
[https://serverless.com/](https://serverless.com/)

One thing I would improve with the authors article is he crammed a giant
conditional statement on the http-method inside his one function. Serverless
makes it easy to bundle a single function per HTTP method and even share
common code between them. You can build out a whole application as a single
npm package.

Bonuses include plugins for serverless that let you unit test your handlers,
run a simulated APIG/Lambda/Dynamo environment locally for development,
plugins that let you interact more deeply with AWS like assigning a custom
domain to your APIG.

Example apps:
[https://github.com/serverless/examples](https://github.com/serverless/examples)

~~~
dschep
Serverless Framework is also great for Python if you're not porting a WSGI
application. Plug/Disclaimer: I'm the creator/maintainer of the defacto python
dependency packaging plugin for serverless[0]

[0] [https://github.com/UnitedIncome/serverless-python-
requiremen...](https://github.com/UnitedIncome/serverless-python-requirements)

------
crabasa
For folks who just want a FaaS platform that comes with all the batteries
included:

[https://StdLib.com](https://StdLib.com)

For folks who already have AWS infra and want the benefits of Lambda without
the pain of API Gateway or Cloud Formation:

[https://arc.codes](https://arc.codes)

------
mart187
There is no remark that an admin IAM user should not be used. This is highly
critical and should not be done ever.

Also using something like serverless framework is better suited for the
average developer to get this setup up and running. Clicking through the aws
cli is not something professional aws users do often. (exceptions would be
Cloudwatch metrics and logs). The article should at least mention that
infrastructure better is managed in code.

------
manishsharan
Is there a use case for AWS API Gateway if one is not using Lambda ? Can it
protect a web application against DDOS ?

I am not convinced API gateway+ Lambda can substitute for a Web Application ,
atleast for J2EE apps. The Lambda "boot" time is way too high unless we resort
to tricks to keep the lambda instance active. I find the extra $30 or similar
is well spent on a a AWS Elastic Beanstalk with auto scaling. The packaging
and deployment is cleaner and simpler.

~~~
segmondy
Yes, you can use API Gateway without lambda. "API Gateway" is an industry term
and not specific to Amazon. The point is exactly your line of reasoning, a
funnel/gateway to your APIs. You can handle Auth, Throttling, etc at that
point. AWS does provide other products for use against DDOS, WAF, Shield. ELB,
Cloudfront, VPCs/SG. Their idea is to be able to scale, deflect if possible
and absorb the attack. They also mention that with AWS API Gateway you can get
Layer & & 3 DDOS protection and throttling for your backend. I've no practical
experience nor have read any reports on how it holds up.

------
danesparza
Great introduction! It should probably also include integration with Route53
and Amazon's SSL cert manager.

~~~
swyx
can you recommend a beginner friendly resource for those?

~~~
danesparza
I personally consider the introductory blog post to be pretty straightforward:
[https://aws.amazon.com/blogs/aws/new-aws-certificate-
manager...](https://aws.amazon.com/blogs/aws/new-aws-certificate-manager-
deploy-ssltls-based-apps-on-aws/)

If you're using AWS based services it does a good job of doing what
letsencrypt would otherwise do.

------
kolanos
Here's a handy calculator to compare AWS Lambda with EC2:
[https://servers.lol](https://servers.lol)

