Hacker News new | past | comments | ask | show | jobs | submit login

Looks like it does handle binary now, if not multipart yet.[1]

Granted the 30 second timeout is a constraint, but how bad a constraint is it? Ideally long-running requests like that should be rearchitected to return fast and deliver the results asynchronously, right? The bigger problem I see is the lack of websockets support, which makes delivering async results harder. Supposedly AWS IoT does it but that seems like an even more exotic usage than implementing a REST service in Lambda.

Basically I get that it's still early days and there are gaps here and there, but am wondering if it's actually an "antipattern" to use Lambda this way or just a little early.

[1] https://aws.amazon.com/about-aws/whats-new/2016/11/binary-da...




It handles binary, but not well. http://forum.serverless.com/t/returning-binary-data-jpg-from...

> Ideally long-running requests like that should be rearchitected to return fast and deliver the results asynchronously, right?

Ideally for whom? I can't think of an engineer who wouldn't rather do a simple request/response. It's certainly cheaper than spending the money to keep a connection open longer than 30 seconds, but far from ideal.


>Ideally for whom?

Anyone running on heroku works with a hard coded 30 second timeout on all web requests. It works fine for everyone there.


> It works fine

You must have a different definition of ideal. I'm sure no one using Heroku would be upset if that limit was removed.


We did a write-up last year about combining our WebSocket gateway with a FaaS backend: http://blog.fanout.io/2016/09/29/serverless-websocket-chat/

The FaaS used in the article is Microcule, but the same approach should work with Lambda now that API Gateway supports binary.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: