{"id":92328,"date":"2019-05-31T10:02:33","date_gmt":"2019-05-31T07:02:33","guid":{"rendered":"https:\/\/www.javacodegeeks.com\/?p=92328"},"modified":"2019-05-29T14:04:22","modified_gmt":"2019-05-29T11:04:22","slug":"aws-lambda-source-mappings-bringing-your-triggers","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2019\/05\/aws-lambda-source-mappings-bringing-your-triggers.html","title":{"rendered":"AWS Lambda Event Source Mappings: bringing your triggers to order from chaos"},"content":{"rendered":"

Recently we introduced two new AWS Lambda event sources (trigger types) for your serverless projects on Sigma cloud IDE<\/a>: SQS queues<\/a> and DynamoDB Streams<\/a>. (Yup, AWS introduced them months ago; but we’re still a tiny team, caught up in a thousand and one other things as well!)<\/p>\n

While developing support for these triggers, I noticed a common (and yeah, pretty obvious) pattern on Lambda event source trigger configurations; that I felt was worth sharing.<\/p>\n

Why AWS Lambda triggers are messed up<\/h2>\n

Lambda – or rather AWS – has a rather peculiar and disorganized trigger architecture; to put it lightly. For different trigger types, you have to put up configurations all over the place; targets<\/a> for CloudWatch Events rules, integrations<\/a> for API Gateway endpoints, notification configurations<\/a> for S3 bucket events, and the like. Quite a mess, considering other platforms like GCP where you can configure everything in one place: the “trigger”<\/a> config of the actual target function.<\/p>\n

Configs. Configs. All over the place.<\/h3>\n

If you have used infrastructure as code (IAC)<\/a> services like CloudFormation (CF)<\/a> or Terraform (TF)<\/a>, you would already know what I mean. You need mappings, linkages, permissions and other bells and whistles all over the place to get even a simple HTTP URL working. (SAM<\/a> does simplify this a bit, but it comes with its own set of limitations<\/a> – and we have tried our best to avoid such complexities in our Sigma IDE<\/a>.)<\/p>\n

Maybe this is to be expected, given the diversity of services offered by AWS, and their timeline (Lambda, after all, is just a four-year-old kid<\/a>). AWS should surely have had to do some crazy hacks to support triggering Lambdas from so many diverse services; and hence the confusing, scattered configurations.<\/p>\n

Event Source Mappings: light at the end of the tunnel?<\/h2>\n
\n
\"AWS<\/figure>\n<\/div>\n

Luckily, the more recently introduced, stream-type triggers follow a common pattern:<\/p>\n