5 ms·

Interesting. It makes me wonder about designing "lambda-client-friendly APIs". To reduce the chances of being long-running, the api would be async, meaning: th

Interesting. It makes me wonder about designing "lambda-client-friendly APIs". To reduce the chances of being long-running, the api would be async, meaning: the client makes a request and gets a claim code result quickly, with the api host to process the request separately and then make a callback when done. Lots of issues to consider. Anyone have experience doing this? Would be great to hear about it.

mike_d 2y ago
> It makes me wonder about designing "lambda-client-friendly APIs" If your hammer fails to drive a screw into wood, you don't need to contemplate a new type of low friction wood.
- krick 2y ago
  Or maybe you do, if screws are so much cheaper than nails.
chuckadams 2y ago
Sounds like webhooks to me -- a use case Lambda excels at.
- foundart 2y ago
  Thanks! I think you're right. To go beyond my original question: In terms of how I have thought about them before, webhooks are similar, but not quite the same thing. I've really only dealt with webhooks when the response was delayed because of a need for human interaction, for example: sending a document for e-signature and then later receiving notifications when the document is viewed and then signed or rejected. I haven't experienced much need to make REST APIs async, only in cases where the processing was generally always very slow for reasons that couldn't be optimized away. I haven't seen much advocacy for it either. However, if we think about lambda-based clients, then it makes a lot more sense to provide async apis. Why have both sides paying for the duration, even if the duration is relatively short? update: Whether or not it's cheaper for the client depends on the granularity of the pricing of the client's provider. For AWS, it seems to be per second of duration, so async would be more expensive for APIs that execute quickly.
coredog64 2y ago
I did this for a client using APIGW and DynamoDB. The claim check is the key, and then there’s a polling endpoint in APIGW that goes directly to DynamoDB with no Lambda in between. When the claim check is processed, the location of the data is an additional attribute in DynamoDB and the APIGW/DynamoDB integration sends an HTTP 302 with the final result URL.

mike_d 2y ago

> It makes me wonder about designing "lambda-client-friendly APIs" If your hammer fails to drive a screw into wood, you don't need to contemplate a new type of low friction wood.

krick 2y ago
Or maybe you do, if screws are so much cheaper than nails.

chuckadams 2y ago

Sounds like webhooks to me -- a use case Lambda excels at.

foundart 2y ago
Thanks! I think you're right. To go beyond my original question: In terms of how I have thought about them before, webhooks are similar, but not quite the same thing. I've really only dealt with webhooks when the response was delayed because of a need for human interaction, for example: sending a document for e-signature and then later receiving notifications when the document is viewed and then signed or rejected. I haven't experienced much need to make REST APIs async, only in cases where the processing was generally always very slow for reasons that couldn't be optimized away. I haven't seen much advocacy for it either. However, if we think about lambda-based clients, then it makes a lot more sense to provide async apis. Why have both sides paying for the duration, even if the duration is relatively short? update: Whether or not it's cheaper for the client depends on the granularity of the pricing of the client's provider. For AWS, it seems to be per second of duration, so async would be more expensive for APIs that execute quickly.

coredog64 2y ago

I did this for a client using APIGW and DynamoDB. The claim check is the key, and then there’s a polling endpoint in APIGW that goes directly to DynamoDB with no Lambda in between. When the claim check is processed, the location of the data is an additional attribute in DynamoDB and the APIGW/DynamoDB integration sends an HTTP 302 with the final result URL.