Yan Cui Profile picture
Jul 28, 2020 5 tweets 2 min read Read on X
phew, spend a good few hours re-organizing a sizable AppSync project (150+ resolvers, ~600 resources), found a nice way to split them in the end, think now we've got some more room to grow this project 💪 here's the before and after for comparison #serverless #aws #appsync ImageImage
unfortunately, the solution wasn't to just "add more nested stacks" because you also reach the 60 parameters limit because the no. of different Lambda functions & DynamoDB tables involved
in the end, I had to find a way to slice along the data sources and pull everything up (DynamoDB tables/Lambda functions/log groups/IAM roles) and down (resolvers, function configurations, IAM roles) together
slicing it this way minimizes the no. of parameters, as each group of resources (centred around a data source) is as self-contained as possible, and then I can group them into nested stacks
btw, this work is already paying dividends as I added several queries and mutations to add a new feature the client wants and that pushed us over 600 resources! good to not have to worry about these CF limits for a while and focus on shipping features Image

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Yan Cui

Yan Cui Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @theburningmonk

May 7
SNS & EventBridge share many capabilities and can be used interchangeably in many situations.

So, how do you know when to use which? 🧵

#aws #serverless Image
Instead of purely judging by the difference in capability (which is an important consideration!) e.g., SNS has FIFO.

It'd be helpful to also consider their respective design choices and let them inform your choice.
SNS is optimized for 1-to-N communications, whereas EventBridge is for N-to-N communications.

This is subtly telegraphed in their respective limits and resource names.
Read 11 tweets
Oct 17, 2023
I have written over 800 technical articles in the last 14 years and they have been read millions of times.

I see a lot of folks making the same mistakes I did early on in my journey.

So here are some principles to help you get better at writing.

🧵
1. 𝗦𝗲𝗹𝗹 𝘁𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺, 𝗻𝗼𝘁 𝘁𝗵𝗲 𝘀𝗼𝗹𝘂𝘁𝗶𝗼𝗻

Like that scene in The Wolf of Wall Street where Di Caprio asked Jon Bernthal to sell him a pen.

First, create the demand, then supply the solution. Image
Sell the problem to the reader. Help them understand why it’s a problem worth solving.

If the readers are not interested in the problem you're solving, they won't care about whatever solution you propose, no matter how good the solution is.
Read 16 tweets
Nov 22, 2022
This is big!

Payload-based filtering was one of the key reasons to choose EventBridge over SNS. This makes SNS a much more viable option in Event-Driven Architecture.

aws.amazon.com/blogs/compute/…
Off the top of my head, this would:

1. Allow you to use one SNS topic for many types of messages, previously one tends to have many SNS topics, one for each type of message.
2. Reduce the coupling between publisher and consumer teams.

e.g. no need for you to pester the publisher team to add a message attribute so you can filter their messages
Read 6 tweets
Oct 24, 2022
This is a very interesting thread and the surrounding discussions. I've had similar discussions in the past, but I don't want to make too many assumptions here because I wasn't part of the conversation with the client.

But here are my thoughts.

First of all, serverless has been successfully adopted at a much bigger scale in other companies. LEGO for example have 26 squads working mostly with serverless, and PostNL has been all in on serverless since 2018.

So technology is probably not the problem.
From the clues I'm able to pick up, the team has given it a go but they faced tooling gaps when you have both serverful (RDS) and serverless components, and maybe needed help to navigate those hard edges and adapt their practices to work better with serverless
Read 15 tweets
Aug 11, 2022
Serverless is great, but it's not a free lunch.

The "serviceful" mindset means you'll need to learn and use many services in your architecture. Having the right tool to help you along can make a world of difference. And here are 7 of my favourites.
Serverless IDE is a VSCode extension that will save you countless hours when you work with CloudFormation, AWS SAM or the Serverless Framework.

Auto-completion, schema validation, CF docs on hover, and many more.

marketplace.visualstudio.com/items?itemName…
IAM Legend by @TastefulElk is another great VS Code extension and takes the chore out of writing IAM statements.

Follow security best practices and do IAM role per function? This will save you hours of looking up IAM docs.

marketplace.visualstudio.com/items?itemName…
Read 12 tweets
Aug 8, 2022
Don't wait for users to complain to find out there's a problem.

Here are the alerts you should have around your #serverless application.

It's not an exhaustive list, but a good starting point that's broadly applicable to everyone.
Most of the regional metrics for Lambda aren't useful for alerting you of an emerging issue, EXCEPT the regional concurrent execution count.

Set an alert threshold to ~70% of your current regional limit so you know to ask for a limit raise before it's too late.
For individual functions, you should have an alert on the error rate (not count), which can be computed by Errors by Invocations.

Implication: don't use errors for control flow!

Also implication for AppSync: you need to handle user errors gracefully:
theburningmonk.com/2021/06/how-to…
Read 11 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(