3 ms·
I don't really get the joke. S3 triggering a lambda doesn't sound meaningfully more complicated than using a lambda by itself. What am I missing?
by Dylan16807 1y ago
I don't really get the joke. S3 triggering a lambda doesn't sound meaningfully more complicated than using a lambda by itself. What am I missing?
- reactordev 1y agoSolving a serverless limitation with more serverless so you can continue doing serverless when you can’t FormUpload a simple 101mb zip file as an application/octet-stream. Doubling down on it for a triple beat.
- Dylan16807 1y agoI wouldn't really call it "more" severless to rearrange the order a bit. Which makes it "solving a serverless limitation so you can continue doing severless". And that's just a deliberately awkward way of saying "solving a serverless limitation" because if you can solve it easily why would you not continue? Spite? So I still don't see how it's notably worse than the idea of using serverless at all.
- reactordev 1y agoThe controversy here is the fact that the API Gateway limits the upload resulting in having to engineer a workaround workflow using s3 and triggers (even if this is the serverless way) when all you want to do is upload a file. A POST call with an octet-octet stream. Let http handle resume. But you can’t and you end up going around the side door, when all you really want is client_body_max_size The sarcasm of correctness yet playing down its complexity is entirely my own. We used to be able to do things easily.
- akdev1l 1y agoIt gets really complex in this workflow to even achieve something like “file coprocessor successfully” on the client side with this approach how will your client know if you backend lambda crashed or whatever? All it knows is the upload to s3 succeeded Basically you’re turning a synchronous process into asynchronous