Hacker News Reader

Comment by Dylan16807 | Hacker News Reader

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?

View on HN

Solving 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.

I 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.

The 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.

It 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

Reply on news.ycombinator.com