Concurrent access to the same items in DynamoDB can lead to consistency problems. In this post I explain why that is and introduce optimistic locking as a technique to combat this issue.
After describing the context of the test pyramid for Infrastructure as Code in part 1, and the Web Application in Part 2a - let`s apply that to some Lambda function.
With CDK you create Infrastructure as Code - IaC. You can automate the test for the IaC code. The three test tastes -Unit, Integration and Application- should work closely together. Here I show you how. It is like the three steps of coffee tasting: 1 smell, 2 Taste, 3 Feel.
TL;DR You don`t need a DSL to do easy integration testing. With CDK available in go, infrastructure test can be programmed with GO packages easily.
CDK doesn’t offer every type of resource by default. Custom Resources allow us to overcome this limitation. Anything that can be created within a Lambda function, can be deployed as a Custom Resource, with its lifecycle being managed by CDK/CloudFormation. This blog posts explains how to set this up using the example of an user in a SimpleAD.
TL;DR with aws-sso-util and awsume sso and codecommmit is easy
DynamoDB supports complex data types like lists. In this post we take a look at different ways to interact with lists. We will use Python to write code that may be used in a data access layer to manipulate items with list attributes.
I was helping a customer with a Amplify App. This later turned into a meetup, where we are building a photo sorting application using AWS Amplify for the backend and Quasar for the frontend. This is the third article in a series that lets you follow along with the development process in your own time.
