4 ms·

Uh, the API Gateway can't handle binary requests/responses very well and it certainly cannot handle multipart requests/responses. Additionally it has a 30 secon

Uh, the API Gateway can't handle binary requests/responses very well and it certainly cannot handle multipart requests/responses. Additionally it has a 30 second timeout so I would say it's definitely not something you could just replace your hosted web server with completely yet.

abalone 10y ago
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-data-now-supported-by-api-gateway/ https://aws.amazon.com/about-aws/whats-new/2016/11/binary-da...
- jkarneges 10y ago
  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/ 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.
- idbehold 10y ago
  It handles binary, but not well. http://forum.serverless.com/t/returning-binary-data-jpg-from-lambda-via-api-gateway/796 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.
  - revicon 10y ago
    >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.
    - idbehold 10y ago
      > 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.

abalone 10y ago

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-data-now-supported-by-api-gateway/ https://aws.amazon.com/about-aws/whats-new/2016/11/binary-da...

jkarneges 10y ago
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/ 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.
idbehold 10y ago
It handles binary, but not well. http://forum.serverless.com/t/returning-binary-data-jpg-from-lambda-via-api-gateway/796 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.
- revicon 10y ago
  >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.
  - idbehold 10y ago
    > 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.