Category: Kev’s Blog

Posted on

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:

Posted on

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.

Posted on

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.

Posted on

Windows 11, the TPM2.0 requirement and Asus AMD chipset motherboards

Microsoft officially announced Windows 11 today. There was the usual online comparisons between the announced features and other comparable features in MacOS and Linux, like the centered Task Bar that now looks suspiciously like how MacOS’s Dock has looked for, well, years.

In the tech requirements though, there is an unusual detail – Windows 11 requires a motherboard security module called TPM 2.0. Most new motherboard apparently come with one of these, but Asus has produced a number of motherboards in the last couple of years and chose not to include one of these modules onboard. If you run the compatibility checker on a PC with one of these mobos, you’ll get this notification that your PC, that you most likely bought as recent as within the last couple of years, is not compatible with Windows 11:

Understandably, there’s a number of threads online where people are rather upset that the new PC they bought within the last few months is not compatible with Windows 11.

The good news is some AMD Ryzen chipsets have BIOS that includes embedded TPM 2.0 support, even if it’s not provided by a discrete module on the motherboard. On my Asus X570 Plus motherboard it has an fTPM option in the BIOS settings with two options, ‘discrete’ or ‘firmware’. On mine the default option was ‘discrete’ but changing it to ‘firmware’ added the support that the compatibility checker is looking for:

And now running the checker again, everything is good:

Proudly powered by WordPress