Cédric Lombion

399 now...

I’ve been on a project at work for 5+ years now, and I’d say some of the biggest technical pain points have included dynamodb, serverless, api gateway. Might be a skill issue, but if I did it all over I’d say just always use postgres and deploy containers to a managed service until there is a reason not to for most projects. Dynamo is great when you know exactly what you’re building from the start. It’s also good if from the start you know you’ll be dealing with a lot of data that can’t work well in postgres (guess what sql has been handling lots of data for a long time). Dynamo becomes a pain when you’re doing agile development. SQL is a lot more forgiving when requirements change. Dynamo takes forever to loop over all your entries and update them. Updating 10 million records takes almost an hour, and that’s including doing parallel scans. “Bro, just increase your provisioned WCU! Sure, but you know it takes at least 20-30 minutes for that to finish updating your instance”? Doing the same update using sql takes 5 min on a 2 cpu machine with 8gb memory. Your inability to easily query for data in dynamo is bad. “Bro, just use GSI!” Ok, now you’re cost for writes are doubled, and each gsi is async updated so again when you need to update all entries, it takes time for your GSI to update fully. Accidentally picked a bad partition, sort key? Have fun writing a bunch of code just to migrate your data to a new table. The dynamo docs say “know your access patterns before you make your single table pattern”… most product owners can’t even describe what they want, you expect us to design our access patterns correct from the start? Lambda is a great when you have a specific need to quickly scale from 0 to 1000s of isolated workers. For example, we have a use case where we need to loop over hundreds of data entries and generate unique pdfs for each one. Lambda shines with this, but now you’ll basically need to use sqs or a queue system to orchestrate it all. Btw sqs has its own set of gotchyas, such as events might be delivered twice so you better write your code to make sure you don’t double process the same event. Luckily lambda supports running containers now, but previously it was a huge pain when you installed a package that requires a node-gyp binary which means now you need to build that inside the correct docker image that is compatible with the lambda runtime and then create a lambda layer containing those binaries. Save yourself the hassle and just always use containers for all running code. Probably just stop using node or JavaScript on the backend if possible, it’s pretty awful. 100% don’t use a mono lambda for your api. Api gateway is a pain and is typically used for putting a rest api in front of your lambdas if you want to make an api using a mono lambda. Works great until your lambda takes more than 30 seconds; api gateway will time out your requests. That means you need to instead go async events and figure out another solution to notify your users (websockets, sse) when the request is done. Have fun getting either to work on lambda. You’ll end up using api gateway v2 websockets that has more gotchyas. Connections auto timeout after 15 minutes, so you need to add ping pong logic, max connection of 2 hours, so again have fun writing more logic for those limits. Cold starts are a real issue as your code grows; which makes you find ways to lazy import functions if deploying a mono lambda api. Don’t forget deploying your lambda has a 250mb limit which is the biggest pain in the ass. Again, just run containers on lambda if you must use them. Add on top you’ll end up using terraform or another IaC tool just to get all this stuff deployed. SST is great, but if you think about it, they created it because we all admit deploying stuff to aws is a nightmare, especially lambda. Idk I’m just burned out on this entire ecosystem. Just let me deploy a single go server that renders html at this point.