Skip to content

Instantly share code, notes, and snippets.

@lakshmantgld
Created October 27, 2017 06:22
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save lakshmantgld/71f745bdc41726f00ca4c6e5b6f366dd to your computer and use it in GitHub Desktop.
Save lakshmantgld/71f745bdc41726f00ca4c6e5b6f366dd to your computer and use it in GitHub Desktop.
try
╔════════════════╦═══════════════════════════════════════════════════════════════╦════════════════════════════════════════════════════════════════════════════╗
║ Features ║ lambda-proxy ║ lambda ║
╠════════════════╬═══════════════════════════════════════════════════════════════╬════════════════════════════════════════════════════════════════════════════╣
║ General ║ This is a simple, but powerful integration. All the request ║ This is complex, but offers more control over transmission data. ║
║ Description ║ and response to the APIGateway URL is forwarded ║ The request and response can be modified before it is sent to ║
║ ║ straight to the Lambda. ║ lambda. This can be done by mapping templates which transforms ║
║ ║ i.e No modifications to the request(query params, body, ║ the payload, as per the user customisations. API Gateway uses ║
║ ║ variables) are done by the APIGateway. ║ Velocity Template Language (VTL) engine to process body ║
║ ║ ║ mapping templates for the integration request and integration response. ║
╠════════════════╬═══════════════════════════════════════════════════════════════╬════════════════════════════════════════════════════════════════════════════╣
║ Mapping ║ Not Applicable ║ The VTL templates use JSONPath expressions, other parameters ║
║ Template ║ ║ such as calling contexts and stage variables, and utility functions ║
║ ║ ║ to process the JSON data. You can define various mapping templates ║
║ ║ ║ based on the content-type. Eg: IF the content-type of request payload ║
║ ║ ║ is application/json, then application/json's mapping template is used. ║
║ ║ ║ See the body mapping template screenshot below. ║
╠════════════════╬═══════════════════════════════════════════════════════════════╬════════════════════════════════════════════════════════════════════════════╣
║ Success & ║ Success response -> callback(null, response). ║ Success response -> callback(null, response) ║
║ Error response ║ Error response -> callback(error), but if you want to specify ║ Error response -> callback(JSON.stringify(error)) ║
║ ║ error status code then callback(null, error), where the ║ This error will later be caught by APIGateway's integration response ║
║ ║ error object should contain statusCode as key. ║ and appropriate status code will be assigned. ║
╠════════════════╬═══════════════════════════════════════════════════════════════╬════════════════════════════════════════════════════════════════════════════╣
║ Error ║ The statusCode of both success and error response has to ║ This is little complex, but this is considered as the best practice, as it ║
║ Handling ║ be set by the respective object. Here is an example for error ║ reduces the human error. ║
║ ║ response: ║ Error response -> callback(JSON.stringify(error)) ║
║ ║ { ║ When you do this, the error object by default will have errorMessage ║
║ ║ statusCode: 404 ║ as the key and the content that you send as the value for it. ║
║ ║ message: 'Not Found' ║ You need to stringify it, so that APIGateway can detect the value of ║
║ ║ } ║ errorMessage's key. ║
║ ║ This will set the appropriate error code in the client and ║ Now, you can introduce various statusCodes and the appropriate ║
║ ║ the error body will contain the object with the ║ regular expressions to match it in the APIGateway. Eg: Include a regular ║
║ ║ message key. ║ expression 'Not Found' for the 404 status code. So whenever the ║
║ ║ ║ stringified error contains the 'Not Found', it immediately assigns 404 ║
║ ║ ║ statusCode and forwards the error body to the client. ║
║ ║ ║ See the statusCode and equivalent regex's screenshot below. ║
╠════════════════╬═══════════════════════════════════════════════════════════════╬════════════════════════════════════════════════════════════════════════════╣
║ Integration ║ Not Applicable ║ In case of error, as you saw the errorMessage will be stringified. You can ║
║ Response ║ ║ define a Integration response mapping template, where you can ║
║ ║ ║ customize the response. ║
╠════════════════╬═══════════════════════════════════════════════════════════════╬════════════════════════════════════════════════════════════════════════════╣
║ Pros ║ 1. Very Easy to setup. statusCode and the message are in ║ 1. It completely decouples the APIGateway from Lambda's request ║
║ ║ lambda's control. ║ and response payload, its headers and statusCodes. ║
║ ║ 2. Easy for rapid prototyping, as you dont want to setup any ║ 2. Provides a procedural way of defining various statusCodes and error ║
║ ║ APIGateway's settings. ║ messages. ║
║ ║ ║ 3. This can be easily exported as Swagger Specifications, so others can ║
║ ║ ║ use to generate different SDKs for it. ║
╠════════════════╬═══════════════════════════════════════════════════════════════╬════════════════════════════════════════════════════════════════════════════╣
║ Cons ║ 1. Prone to human errors. ║ 1. Involves lot of work. Templates(VTL, JSONPath) has to be defined ║
║ ║ 2. Everything rest in the code. Difficult to generate ║ which takes lot of time. ║
║ ║ documentation. Headers, StatusCode and message are ║ ║
║ ║ hidden in the source code. ║ ║
╠════════════════╬═══════════════════════════════════════════════════════════════╬════════════════════════════════════════════════════════════════════════════╣
║ Serverless ║ No Explicit definition has to be made in serverless.yml file. ║ All the templates, headers, statusCode and the associated patterns can ║
║ Framework ║ When you define an HTTP eventm by default it assumes ║ be specified in the serverless.yml file itself. ║
║ ║ lambda-proxy as the integration between APIGateway and ║ See the lambda-integration in serverless.yml's screenshot below. ║
║ ║ lambda. ║ ║
╚════════════════╩═══════════════════════════════════════════════════════════════╩════════════════════════════════════════════════════════════════════════════╝
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment