‘serverless invoke local’ with Java Lambdas

If you create a Java Lambda with the provided template, you’re probably returning a response using the provided ApiGatewayResponseClass. If you run your Lambda locally with ‘serverless invoke local –function functioname’, you’ll see a response like this:

Serverless: Invoke invoke:local
Serverless: In order to get human-readable output, please implement "toString()" method of your "ApiGatewayResponse" object.

com.serverless.ApiGatewayResponse@3bd3d05e

Any other logger output will appear in your console, but in order to see the actual content of your ApiGatewayResponse, add a toString() method as the message suggests.

You include any of the properties in ApiGatewayResponse, but if you’re just interested in the JSON payload in the body of the response, then just adding this will return the body:

public String toString(){
    return this.body;
}

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.

AmazonDynamoDBException: Consistent reads are not supported on global secondary indexes

If you try to execute a DynamoDB query against a Global Secondary Index, by default you’ll get this error:

AmazonDynamoDBException: Consistent reads are not supported on global secondary indexes (Service: AmazonDynamoDBv2; Status Code: 400; Error Code: ValidationException

To avoid this, per answers on this question, you need to call:

.withConsistentRead(false);

on your query expression.

Although the docs here suggest queries are eventually consistent by default, apparently with the DynamoDB mapping api you still need to explicitly set the consisten read = false parameter.