Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

aws api gateway & lambda: multiple endpoint/functions vs single endpoint

I have an AWS api that proxies lamba functions. I currently use different endpoints with separate lambda functions:

api.com/getData --> getData api.com/addData --> addData api.com/signUp --> signUp 

The process to manage all the endpoints and functions becomes cumbersome. Is there any disadvantage when I use a single endpoint to one lambda function which decides what to do based on the query string?

api.com/exec&func=getData --> exec --> if(params.func === 'getData') { ... } 
like image 293
Chris Avatar asked Jan 02 '17 10:01

Chris


People also ask

What is an AWS API gateway?

What is Amazon API Gateway? PDFRSS. Amazon API Gateway is an AWS service for creating, publishing, maintaining, monitoring, and securing REST, HTTP, and WebSocket APIs at any scale. API developers can create APIs that access AWS or other web services, as well as data stored in the AWS Cloud .

Why do we use AWS API gateway?

API Gateway allows you to leverage AWS administration and security tools, such as AWS Identity and Access Management (IAM) and Amazon Cognito, to authorize access to your APIs. API Gateway can verify signed API calls on your behalf using the same methodology AWS uses for its own APIs.

What does API Gateway do?

API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, CORS support, authorization and access control, throttling, monitoring, and API version management.


2 Answers

It's perfectly valid to map multiple methods to a single lambda function and many people are using this methodology today as opposed to creating an api gateway resource and lambda function for each discrete method.

You might consider proxying all requests to a single function. Take a look at the following documentation on creating an API Gateway => Lambda proxy integration: http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-set-up-simple-proxy.html

Their example is great here. A request like the following:

POST /testStage/hello/world?name=me HTTP/1.1 Host: gy415nuibc.execute-api.us-east-1.amazonaws.com Content-Type: application/json headerName: headerValue  {     "a": 1 } 

Will wind up sending the following event data to your AWS Lambda function:

{   "message": "Hello me!",   "input": {     "resource": "/{proxy+}",     "path": "/hello/world",     "httpMethod": "POST",     "headers": {       "Accept": "*/*",       "Accept-Encoding": "gzip, deflate",       "cache-control": "no-cache",       "CloudFront-Forwarded-Proto": "https",       "CloudFront-Is-Desktop-Viewer": "true",       "CloudFront-Is-Mobile-Viewer": "false",       "CloudFront-Is-SmartTV-Viewer": "false",       "CloudFront-Is-Tablet-Viewer": "false",       "CloudFront-Viewer-Country": "US",       "Content-Type": "application/json",       "headerName": "headerValue",       "Host": "gy415nuibc.execute-api.us-east-1.amazonaws.com",       "Postman-Token": "9f583ef0-ed83-4a38-aef3-eb9ce3f7a57f",       "User-Agent": "PostmanRuntime/2.4.5",       "Via": "1.1 d98420743a69852491bbdea73f7680bd.cloudfront.net (CloudFront)",       "X-Amz-Cf-Id": "pn-PWIJc6thYnZm5P0NMgOUglL1DYtl0gdeJky8tqsg8iS_sgsKD1A==",       "X-Forwarded-For": "54.240.196.186, 54.182.214.83",       "X-Forwarded-Port": "443",       "X-Forwarded-Proto": "https"     },     "queryStringParameters": {       "name": "me"     },     "pathParameters": {       "proxy": "hello/world"     },     "stageVariables": {       "stageVariableName": "stageVariableValue"     },     "requestContext": {       "accountId": "12345678912",       "resourceId": "roq9wj",       "stage": "testStage",       "requestId": "deef4878-7910-11e6-8f14-25afc3e9ae33",       "identity": {         "cognitoIdentityPoolId": null,         "accountId": null,         "cognitoIdentityId": null,         "caller": null,         "apiKey": null,         "sourceIp": "192.168.196.186",         "cognitoAuthenticationType": null,         "cognitoAuthenticationProvider": null,         "userArn": null,         "userAgent": "PostmanRuntime/2.4.5",         "user": null       },       "resourcePath": "/{proxy+}",       "httpMethod": "POST",       "apiId": "gy415nuibc"     },     "body": "{\r\n\t\"a\": 1\r\n}",     "isBase64Encoded": false   } } 

Now you have access to all headers, url params, body etc. and you could use that to handle requests differently in a single Lambda function (basically implementing your own routing).

As an opinion I see some advantages and disadvantages to this approach. Many of them depend on your specific use case:

  • Deployment: if each lambda function is discrete then you can deploy them independently, which might reduce the risk from code changes (microservices strategy). Conversely you may find that needing to deploy functions separately adds complexity and is burdensome.
  • Self Description: API Gateway's interface makes it extremely intuitive to see the layout of your RESTful endpoints -- the nouns and verbs are all visible at a glance. Implementing your own routing could come at the expense of this visibility.
  • Lambda sizing and limits: If you proxy all -- then you'll wind up needing to choose an instance size, timeout etc. that will accommodate all of your RESTful endpoints. If you create discrete functions then you can more carefully choose the memory footprint, timeout, deadletter behavior etc. that best meets the needs of the specific invocation.
like image 183
Dave Maple Avatar answered Oct 10 '22 03:10

Dave Maple


I would have commented to just add a couple of points to Dave Maple's great answer but I don't have enough reputation points yet so I'll add the comments here.

I started to head down the path of multiple endpoints pointing to one Lambda function that could treat each endpoint different by accessing the 'resource' property of the Event. After trying it I have now separated them into separate functions for the reasons that Dave suggested plus:

  • I find it easier to go through logs and monitors when the functions are separated.
  • One nuance that as a beginner I didn't pick up on at first is that you can have one code base and deploy the exact same code as multiple Lambda functions. This allows you to have the benefits of function separation and the benefits of a consolidated approach in your code base.
  • You can use the AWS CLI to automate tasks across the multiple functions to reduce/eliminate the downside of managing separate functions. For example, I have a script that updates 10 functions with the same code.
like image 36
Inspector6 Avatar answered Oct 10 '22 03:10

Inspector6