3

I am very new to AWS Lambda and am struggling to understand its functionalities based on many examples I found online (+reading endless documentations). I understand the primary goal of using such service is to implement a serverless architecture that is cost and probably effort-efficient by allowing Lambda and the API Gateway to take on the role of managing your server (so serverless does not mean you don't use a server, but the architecture takes care of things for you). I organized my research into two general approaches taken by developers to deploy a Flask web application to Lambda:

  1. Deploy the entire application to Lambda using zappa-and zappa configurations (json file) will be the API Gateway authentication.

  2. Deploy only the function, the parsing blackbox that transforms user input to a form the backend endpoint is expecting (and backwards as well) -> Grab a proxy url from the API Gateway that configures Lambda proxy -> Have a separate application program that uses the url

(and then there's 3, which does not use the API Gateway and invokes the Lambda function in the application itself-but I really want to get a hands on experience using the API Gateway)

Here are the questions I have for each of the above two approaches:

For 1, I don't understand how Lambda is calling the functions in the Flask application. According to my understanding, Lambda only calls functions that have the parameters event and context-or are the url calls (url formulated by the API Gateway) actually the events calling the separate functions in the Flask application, thus enabling Lambda to function as a 'serverless' environment-this doesn't make sense to me because event, in most of the examples I analyzed, is the user input data. That means some of the functions in the application have no event and some do, which means Lambda somehow magically figures out what to do with different function calls?

I also know that Lambda does have limited capacity, so is this the best way? It seems to be the standard way of deploying a web application on Lambda.

For 2, I understand the steps leading to incorporating the API Gateway urls in the Flask application. The Flask application therefore will use the url to access the Lambda function and have HTTP endpoints for user access. HOWEVER, that means, if I have the Flask application on my local computer, the application will only be hosted when I run the application on my computer-I would like it to have persistent public access (hopefully). I read about AWS Cloud9-would this be a good solution? Where should I deploy the application itself to optimize this architecture-without using services that take away the architecture's severless-ness (like an EC2 instance maybe OR on S3, where I would be putting my frontend html files, and host a website)? Also, going back to 1 (sorry I am trying to organize my ideas in a coherent way, and it's not working too well), will the application run consistently as long as I leave the API Gateway endpoint open?

I don't know what's the best practice for deploying a Flask application using AWS Lambda and the API Gateway but based on my findings, the above two are most frequently used. It would be really helpful if you could answer my questions so I could actually start playing with AWS Lambda! Thank you! (+I did read all the Amazon documentations, and these are the final-remaining questions I have before I start experimenting:))

John Rotenstein
  • 241,921
  • 22
  • 380
  • 470
llisune
  • 61
  • 1
  • 8

1 Answers1

5

  1. Zappa has its own code to handle requests and make them compatible with the "Flask" format. Keep in mind that you aren't really using Flask as intended in either cases when using Lambda. Lambdas are invoked only when calls are made, flask usually keeps running looking for requests. But the continuously running part is handled by the API Gateway here. Zappa essentially creates a single ANY request on API gateway, this request is passed to your lambda handler which interprets it and uses it to invoke your flask function.

  2. If you you are building API Gateway + Lambda you don't need to use Flask. It would be much easier to simply make a function that is invoked by the parameters passed to lambda handler by the API Gateway. The front end application you can host on S3 (if it is static or Angular).

I would say the best practice here would be to not use Flask and go with the API Gateway + Lambda option. This lets you put custom security and checks on your APIs as well as making the application a lot more stable as every request has its own lambda.

Ninad Gaikwad
  • 4,272
  • 2
  • 13
  • 23
  • Thank you! I think your answer to 1 really helped me clarify things. But for 2, I am still a bit confused about the inner workings of the lambda functions. If I’m not using Flask, how are the different urls being called and how are the different lambda functions being configured-assuming my application has multiple pages? What input is the Gateway receiving without an actual API and how? I don’t think I understand the process without using Flask to route different pages and inputs. (You also mention the lambda handler. Is an ‘event’ different from a ‘call’ invoking a lambda function?) – llisune Jul 02 '20 at 16:50
  • 1
    In API gateway you can create multiple "resources" which are like your methods in flask. You can also create multiple "methods" under the resources to specify what type of call it is (POST, GET, ANY etc). You can then link each of these "methods" to a lambda. You can create different lambdas for different methods or you can create single lambda and then write the code to handle what function to call when certain parameters are passed to the lambda by the API gateway. – Ninad Gaikwad Jul 02 '20 at 17:04
  • Create a test lambda and API resource+methods. It will be much easier to understand that way. – Ninad Gaikwad Jul 02 '20 at 17:05
  • Wow that clarified everything really. Thank you again. I should first test out the features on the Gateway console and get familiar with the resources it offers. One final question though: is it right to assume that using Flask+API Gateway+Lambda is inefficient unless I’m trying to test my application locally? And if I’m trying to use such method to deploy my actual application to the cloud, I would have to rely on other cloud services, which again is inefficient-probably costwise? – llisune Jul 02 '20 at 17:11
  • It won't hurt you cost wise at all. It will be simpler to build and update but will offer you less customization and less simultaneous calls as it forces you to use only one lambda. But if that isn't a concern you can go ahead with using the zappa method. – Ninad Gaikwad Jul 02 '20 at 17:16
  • Please mark answer as correct if I solved your problem. – Ninad Gaikwad Jul 02 '20 at 17:17
  • Oh sorry I meant by using the second method by having an API Gateway proxy request in my Flask application (I could deploy it to some other service)-which is not the Zappa approach. – llisune Jul 02 '20 at 17:22
  • I don't understand. Flask is supposed to catch incoming requests. It does exactly what API Gateway is doing. Using flask + API gateway just seems redundant. Unless you are using zappa which just uses API gateway to make a single api for your flask application on lambda to handle. – Ninad Gaikwad Jul 02 '20 at 17:29