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

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

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

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

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