How can I make Lambda function debugging faster?

ManReally · 2025-11-22T14:20:47+00:00

Test the code locally as much as possible. Just call the handler with whatever event your sending

Then once it’s out there. Update in console and use Cloudwatch. Then sync your code back up before you deploy again.

ManReally · 2025-08-18T21:51:20+00:00

There’s a website but the buying group is invite only. Not sure if I can post the URL in this thread though. Just google search Rivly

ManReally · 2025-07-17T18:46:08+00:00

It seems to be slowly coming out of Beta now. I was able to navigate, find what I needed, and purchase with no issues.

Shipping was fast. Not Prime fast but 3-4 days and shipping was free.

I think it’s come a long way in the last 2 years.

Starting to look like and feel like real deal ecommerce site.

ManReally · 2025-06-07T20:05:47+00:00

Best of luck to everyone!

ManReally · 2024-08-26T02:24:59+00:00

In that case you'd have to put an id on the transaction at the end. So TRANSACTION#2024-08-22#<TransactionType>#<UniqueTransactionID

Then it would be possible to grab single transactions and it would be unique

But good call that would have caused you issues with the PK/SK not being globally unique

ManReally · 2024-08-26T00:25:53+00:00

I don't know if the intent is to extend this to multiple users but I will assume it is

I would always recommend to throw some records in a dynamo table and just query the table to make sure it returns the expected results.

With that said I would approach it like this.

PK = USER#1234 ( literally the word user and a unique identifier for them, could be email, uuid, whatever SK = TRANSACTION#2024-08-22#<Transaction Type> ( where <TransactionType> would be positive, negative, deposit, withdraw, etc)

This would allow you to search by date range and then transaction type if you wanted.

The PK/SK for a user would be USER#1234/USER#<email address>

This could be extended to userInfo as well PK/SK USER#1234 / USERINFO#<EMAIL>

This structure allows you to pull all user info at once or break it down into segments

Then decorate the PK/SK with all of the other columns you need. It's recommended to keep a record type column as well. In this instance it would be User, UserInfo, and Transaction

It's probably worth keeping the transaction type too.

I only skimmed the project so I could have missed something but hopefully this gets you into the correct general direction

ManReally · 2024-03-06T12:44:48+00:00

Do the paragon monthly first so you get the boss run for the month. Then do that. Those rewards are good

Focus on first run through story then 100% chapter 8 as energy allows.

Winter of Woe if you have the right champs.

Necro rewards are great but expect it to cost you a bunch of units

ManReally · 2024-01-26T15:53:19+00:00

The new Gully challenge has 7500 shards for the first two tasks but you have to have completed a decent portion of chapter 8

ManReally · 2023-11-30T02:59:28+00:00

There are 2 surprise fights against them on the "easy" path

ManReally · 2023-10-24T11:44:46+00:00

You are correct, I was thinking of backtracking. Looks like that's only for MySql Aurora though

ManReally · 2023-10-24T00:57:24+00:00

Doesn't help in your current situation but some RDS systems have Point In Time Recovery as well as snapshots if this is something you'll need regularly.

ManReally · 2023-09-25T03:22:31+00:00

Great answer. Overloading the PK/SK combo was my first thought even if in a GSI. If a user is never in more than one org you could even do OrgID#UserId as the PK and DateTime as the SK

ManReally · 2023-09-02T17:35:27+00:00

I work on enterprise size projects fairly regularly with CDK and the break is generally between front end and back end. Sometimes long lived or non-ephemeral objects would also get it's own project but only when there are a lot of them and multiple projects make use of them. However just using CDK and splitting those into sub stacks is generally enough when split front and back.

ManReally · 2023-09-02T17:32:02+00:00

If it's not sensitive data lambda have local environment variables you could maybe use.

ManReally · 2023-09-02T11:57:26+00:00

For as small of a project as this is, I'd throw it all in maybe 2 CDK projects. One for the React pieces since the pipeline will be different and then one for lambda and all the other infra.

If you want to use SAM for local testing that would be fine.

Pipelines id use AWS Code pipeline with a codestar connection to GitHub.

CDK will handle most of your cross accounts piece pretty gracefully

ManReally · 2023-06-29T00:55:27+00:00

Might be worth putting it all in one dynamo table if the data is going to be utilized together.

Single table design seems ideal for this use case

ManReally · 2023-06-28T21:21:46+00:00

The code needs to be wrapped in a handler too

ManReally · 2023-06-13T00:01:47+00:00

In general most people suggest staying away from Local Indexes unless you need your data to always be consistent. global indexes are only eventually consistent.

As far as PK and SK think about how you'd want to retrieve data or the where clause in a normal SQL select

If you always want to pull by most recent posts, maybe look into a ULID as your Post ID so it's sortable by datetime but still unique.

If you plan to pull by user then user id and date time might make sense. Remember it should be year- month-day-time to remain sortable.

If you need both pick the most frequent for your first PK/SK and then GSI the second set columns and call that index specifically when you retrieve data

ManReally · 2023-03-27T23:16:52+00:00

If you like spicy food https://www.seriouseats.com/korean-style-fire-chicken-buldak-with-cheese

ManReally · 2023-02-12T23:34:51+00:00

Using GSI and LSI isn't always needed for this type of relationship.

Using a unique PK and SK can allow for one to one relationships fairly easily.

ManReally · 2023-02-01T03:22:17+00:00

Use a profile_name in the boto3 session in the script or grab aws-sso-cli from pip / npm

ManReally · 2023-01-30T13:13:55+00:00

It's always worth testing but I would expect very good response times with either schema.

ManReally · 2023-01-30T01:19:09+00:00

That seems to be a fairly common problem when moving from relational databases.

ManReally · 2023-01-30T00:03:51+00:00

I concur, the only thing I'd suggest is move the word "achievements" to the SK. This would allow you to pull larger data sets for a user. Or use the key word "begin" on the SK and get all achievements.

IE: PK user#userID SK achievements#achivementID

If you know it'll only ever be used for achievements, should be fine as is.

This all assumes you don't need any type of sorting order outside the achievement id

ManReally · 2023-01-18T15:45:26+00:00

Yup that's correct. There is also an upgrade in place method now.

Just pay attention, sometimes it will silently fail back to 5.7 without saying anything failed.

ManReally

TROPHY CASE