Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
dan-pud67911dCurious, please explain
C0D45594711dUmm... I think you're doing it wrong somehow🤨
AlmondSauce788811dThat may be ok, if it's a hobbyist type project and your main concern is scaling to zero because of cost, rather than scaling to infinity quickly.
If it's an enterprise project then yeah... that's bad.
Functions/lambdas were used because they are advertised as "free". However the whole architecture is just monolith. Since everything is driven by http calls the whole app has no resilience.
But Db kills it completely. Why?
If you upload an image, every 5s on ui http call is made to lambda that checks if another lambda already completed its task. And this is done by checking state of job in table "Job". But the worst thing is when one lambda is waiting for another lambda. This is done the same way as described above. Even if we have multiple instances of lambdas running in the cloud, there is still only ONE db that rules them all. More lambdas running in same time = worse performance.
I don't think you're doing it right.
Lambdas calling other lambdas is one of the biggest anti-patterns in serverless.
Also, your database should be able to scale as well. If you're in AWS, Dynamo is great, or there is Aurora Serverless which autoscales.
Also instead of polling I would recommend using We sockets from your frontend so it can receive a message the job is done
Should be WebSockets
Ah, that's always fun!
I would suggest a different pattern for uploading images as well.
Use the lambda to ask S3 for a generated and signed url, give that to your client and let them do the upload to that. Much more secure and performant.