Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Full Guide to Developing REST API’s with AWS API Gateway and AWS Lambda

blog.sourcerer.io

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Full Guide to Developing REST API’s with AWS API Gateway and AWS Lambda

#21

Post by piotrkubisa »

k__ wrote: post #17
piotrkubisa wrote: post #7

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 no…

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

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

Re: Full Guide to Developing REST API’s with AWS API Gateway and AWS Lambda

#22

Post by dfee »

Mizza wrote: post #10

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.

What is the group thought on running these containers that have access to (for example) a Postgres or Redis dB?

Sure Zappa, keeps the “container-function-thing” alive so you can cache it as a global variable, but this is a jacket approach that I’m not clear enough on the consequences to use.

Re: Full Guide to Developing REST API’s with AWS API Gateway and AWS Lambda

#23

Post by 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.

Re: Full Guide to Developing REST API’s with AWS API Gateway and AWS Lambda

#24

Post by pweissbrod »

Mizza wrote: post #10

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.

To me, the beautiful thing about this zappa approach is that I still follow the spec of a UWSGI-compliant app and I get the benefit of quick deployment to lambda without any form of vendor lock-in as it is also straightforward to plug the same app into, say nginx, without code change.

Re: Full Guide to Developing REST API’s with AWS API Gateway and AWS Lambda

#26

Post by k__ »

piotrkubisa wrote: post #21
k__ wrote: post #17

Earlier quoted context omitted.

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

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-sa…

Isn't SAM just an extension of CloudFormation?

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

Re: Full Guide to Developing REST API’s with AWS API Gateway and AWS Lambda

#27

Post by Terr_ »

Lord_Zero wrote: post #13
Mizza wrote: post #10

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.

If using NodeJS there is a very similar package to zappa called Serverless 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 i…

I'm currently working on a project where -- in serverless.yml -- a single API gateway path for all HTTP methods leads to a Flask app... largely because this scheme seems much much easier and faster to test and develop locally.

Are there any particular benefits to exporting and reimplementing all of that routing and organizational logic into instructions that "program" the API Gateway instead?

In this particular case, the API is solely for external consumption by a third party

Re: Full Guide to Developing REST API’s with AWS API Gateway and AWS Lambda

#28

Post by piotrkubisa »

k__ wrote: post #26
piotrkubisa wrote: post #21

Earlier quoted context omitted.

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-sa…

Isn't SAM just an extension of CloudFormation? It allows you the SAM simplifications, but also all the CF stuff.

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...

[2]: https://awslabs.github.io/serverless-application-model/globa...

[3]: https://github.com/awslabs/serverless-application-model/tree...

Post reply on HN