aws cli : Listing Lambda functions and filtering with jq

‘aws lambda list-functions’ returns function details in your current region, but the info is sometimes too verbose when you’re looking for a list of names:

{
    "Functions": [
{
    "FunctionName": "example1",
    "FunctionArn": "arn:aws:lambda:us-west-2:111111111:function:example1",
    "Runtime": "java8",
    "Role": "arn:aws:iam::111111111:role/example-role",
    "Handler": "package.YourHandler::myHandler",
    "CodeSize": 3381385,
    "Description": "",
    "Timeout": 6,
    "MemorySize": 1024,
    "LastModified": "2021-01-13T08:18:33.727+0000",
    "CodeSha256": "aaabbbccc=",
    "Version": "$LATEST",
    "TracingConfig": {
      "Mode": "PassThrough"
    },
    "RevisionId": "aa-bb-cc-dd"
  },
  {
    "FunctionName": "example2",
    "FunctionArn": "arn:aws:lambda:us-west-2:111111111:function:example2",
    "Runtime": "java8",
    "Role": "arn:aws:iam::111111111:role/example-role",
    "Handler": "package.YourHandler2::myHandler",
    "CodeSize": 3381385,
    "Description": "",
    "Timeout": 6,
    "MemorySize": 1024,
    "LastModified": "2021-01-13T08:18:33.727+0000",
    "CodeSha256": "aaabbbccc=",
    "Version": "$LATEST",
    "TracingConfig": {
      "Mode": "PassThrough"
    },
    "RevisionId": "aa-bb-cc-dd"
  }
]
}

Passing this into JQ you can filter to display any of the properties easily with patterns like:

aws lambda list-functions | jq '.Functions[].FunctionName

Serverless Framework: AWS Lambdas with scheduled events and parameters

To configure an AWS Lambda to get triggered by a CloudWatch event, you can use the ‘schedule’ event in your config:

functions:
  your-function-name:
    handler: your.Handler
    timeout: 30
    events:
      - schedule:
          rate: rate(12 hours)
          input:
            puzzles : "2"
            targetGivens : "20"

You can also pass parameters from the CloudWatch event when your Lambda is invoked by listing them under ‘input’ (this is optional if your Lambda doesn’t take any parameters).

There schedule config is covered in the docs here, but there doesn’t seem to be any official docs for input, but I found this in a reply to a question here.

Serverless Framework API Gateway CORS config

If you deploy a Serverless Framework Java Lambda to AWS and attempt to call it locally while developing your frontend, you’ll run into a CORS error like this:

Access to XMLHttpRequest at 'https://abc.execute-api.us-west-1.amazonaws.com/some/api' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Posts suggest to set a cors option under the event in your serverless.yaml like this:

events:
  - http:
    path: handlerPath
    method: post
    cors:
      origin: '*'

… but in current versions of Serverless this results in an error like this:

Serverless:   at 'functions['example'].events[0].httpApi': unrecognized property 'cors'

From this post, it mentions the cors options has moved up into the provider section:

provider:
  name: aws
  runtime: java8
  lambdaHashingVersion: 20201221
  httpApi:
    cors: true

This is in the docs here.

This works great!

What does this option do? It looks like it sets these options in API Gateway:

Building variations of the same app to practice or learn different tech / frameworks / libraries

Once you’re familiar with building a solution for a given problem, as you’re learning new languages, frameworks, libraries or whatever is your current focus, there’s no reason why you have to build something completely new when you’re learning something new. Learning to solve problems is valuable and essential, but if your current goal is to build some experience with a new framework for example, there’s no reason why you shouldn’t rebuild something you’re already familiar with.

For example, if you’ve come across any of my posts before, you’ll know I’ve been spending a huge amount of time writing code around solving and generating Sudoku puzzles. While this has been an interesting exercise in itself, the real goal was to use it as set of related problems for practicing building apps with React and AWS Lambdas.

Even for the frontend I’ve gone through a couple of variations:

The initial frontend app was React with Redux, and it’s served from a public S3 bucket here: http://react-sudoku-solver.s3-website-us-west-1.amazonaws.com/index.html . The source for this app is here: https://github.com/kevinhooke/sudoku-solver-react-app

I then redeployed it using a CloudFront distribution, with a Route53 record using my domain name, that’s here (it’s still the same app at this point) : http://sudoku-solver.kevinhooke.com/

Recently I rebuilt it using Redux instead of Flux. I don’t have that deployed anywhere yet, but the source for that app is here: https://github.com/kevinhooke/sudoku-solver-react-app-with-redux

I was planning on updating the app to download pre-generated puzzles. That part took me off on a wild goose chase, on working out how to generate puzzles and grade them with a human solver to assess their difficulty. Now I’ve got that part working, I can come back to the frontend app again.

This app, the frontend and the backed solver, generator and grader has kept me busy for month. You don’t have to build something new everytime, if you’re struggling for ideas for personal projects, it’s ok to rebuild something you’re already familiar with.