Hacker News Reader

Hacker News

Comment by jinder | Hacker News Reader

Parent Full thread

jinder

In which scenario would you use a blocking http call?

View on HN

Not necessarily HTTP, but I imagine hitting some sort of database from a lambda is not uncommon.

> hitting some sort of database from a lambda is not uncommon.

of course. Like e.g. dynamoDB?

Here are some examples of non-blocking calls from C# to dynamoDB that you could make from a lambda

https://matthiasshapiro.com/2017/03/21/tutorial-dynamodb-in-...

The rest of the AWS SDK for .Net core is like that too. All those Async methods.

Http should also be done in a non-blocking, awaitable way too.

The deleted comment is exactly right - Async/awaits operators are the .Net mechanism to avoid blocking calls, and they are available here.

Isn't the intent with a system like Lambda that you'd not do any kind of blocking action. Instead, you'd trigger some event that the AWS database solutions would receive. Once the DB has finished the query it sends the data back and triggers another lambda function.

EDIT: I write this as someone who does no web programming and has only toyed with AWS. This was my understanding from what I read, but not something I actually made.

No. "Once the DB has finished the query it sends the data back and triggers another lambda function"

What mechanism is the DB 'sending' data via? Is it just the response part of the initial query? Then it's executing in the context of the same lambda function. You -could- then call another lambda function from the running lambda function (but why?), but more, what was the function that executed the query doing while it waited?

If it had something it -could- be doing, it should be doing it, so non-blocking is important. If it had nothing it could be doing, it literally does not matter if it was a blocking call or not; it doesn't effect anything.

Now, if you meant you have a trigger in the DB that calls another lambda function, such that the original lambda could complete, yes, of course you could do that. However, if this was a GET style call, not a PUT, your options to get the data back to the user are limited if you don't just keep the REST request open and respond that way. Certainly, any other solution is more complex, probably more expensive, and may not be possible.

The relevant methods in the AWS .Net SDK are all awaitable, i.e. not blocking. Even if you did block on waiting for it, an operation on DynamoDB such as writing a record should typically take under 10ms, which would be ok.

So there is no reason at all not to do it in a lambda.

From what I've seen in organisations, no. In fact you start 10 threads all of whom start blocking calls, several to DBs hosted outside of amazon.

Inefficient ? Yes. The quest for the $15 page refresh continues.

Reply on news.ycombinator.com