Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A 7KB AWS lambda Node.js library with zero runtime dependencies

npmjs.com

Post reply on HN
Print view View original

31–40 of 63 posts

Re: A 7KB AWS lambda Node.js library with zero runtime dependencies

#31

Post by gargarplex »

spion wrote: post #21
gargarplex wrote: post #18

Earlier quoted context omitted.

Excellent source; thanks! It’s probably worth clarifying that Node is ⅓ the speed of Java in some of these cases and that the Node implementations use both fixed size typed arrays as well as worker threads, features that aren’t common practice in most Node programs.

I wanted to illustrate the fairly "wide dynamic range" available. A lot of typed, GCed languages require significant effort to write highly optimized code anyway, and the optimized code rarely looks like the idiomatic one. But even with idiomatic code the performance is quite good - the JITs are very high quality.

I didn't downvote you – in fact, I upvoted you. But I should also make the point that worker threads do not support importing native Node modules that were built directly on the V8 API. For example, most popular sqlite libraries (better-sqlite3, sqlite3) are not usable with worker threads.

I'm mulling contributing N-API support to the libraries... but I haven't even done any research or planning work yet.

Re: A 7KB AWS lambda Node.js library with zero runtime dependencies

#33

Post by fahrradflucht »

golergka wrote: post #24
spion wrote: post #12

Earlier quoted context omitted.

For those situations where the GC becomes a performance (or more likely memory usage) problem, it seems reasonable that the built-in WASM support of most engines will be able to provide an adequate performance (its already getting quite close): https://www.usenix.org/conference/atc19/presentation/jangda

Anything CPU-bound is a very bad fit for node. But most web services are IO-bound, and Node is excellent for them.

I agree, although for server side rendering of web frontends, it is still the best choice even though producing vdom and rendering it to string is usually cpu bound.

Re: A 7KB AWS lambda Node.js library with zero runtime dependencies

#34

Post by fahrradflucht »

ZitchDog wrote: post #29
tnolet wrote: post #20

Earlier quoted context omitted.

Node is especially good at handling async stuff. It’s in the JavaScript DNA. Whether through callbacks, Promises or async/await. As many backend apps are basically tying together 3rd party and 1st APIs it’s actually a very logical choice.

Kind of silly in a lambda though, as lambdas do not run concurrently. A bash script would suffice.

But you can still have concurrency while handling a single invocation.

Re: A 7KB AWS lambda Node.js library with zero runtime dependencies

#35

Post by ignoramous »

ZitchDog wrote: post #29
tnolet wrote: post #20

Earlier quoted context omitted.

Node is especially good at handling async stuff. It’s in the JavaScript DNA. Whether through callbacks, Promises or async/await. As many backend apps are basically tying together 3rd party and 1st APIs it’s actually a very logical choice.

Kind of silly in a lambda though, as lambdas do not run concurrently. A bash script would suffice.

Lambda for NodeJs doesn't / won't run multiple requests in the same process but different V8 contexts at the same time?

That sounds wasteful, and imo makes Cloudflare's Serverless tech superior for strictly network-io bound workloads. Lambda, to be fair, supports way many event triggers and all sorts of runtime and user-space constructs, but still manages warm start times <10ms which is really impressive.

Re: A 7KB AWS lambda Node.js library with zero runtime dependencies

#36

Post by virmundi »

ZitchDog wrote: post #29
tnolet wrote: post #20

Earlier quoted context omitted.

Node is especially good at handling async stuff. It’s in the JavaScript DNA. Whether through callbacks, Promises or async/await. As many backend apps are basically tying together 3rd party and 1st APIs it’s actually a very logical choice.

Kind of silly in a lambda though, as lambdas do not run concurrently. A bash script would suffice.

I’m new at this, and would love feedback if I’m wrong, but I think that a lambda instance could be reused if the system had need. As a result the best practice is to closure global-like data in the handler function itself. This would then get passed down through the layers much like Golang’s context.

Re: A 7KB AWS lambda Node.js library with zero runtime dependencies

#37

Post by virmundi »

geewee wrote: post #3
s_Hogg wrote: post #2

Not knowing this myself, could someone explain the attraction in using a web scripting framework for stuff like this? I get that this particular example makes the whole thing seem fairly straightforward, but have never really heard why people like adapting Node.js and similar to non-web environments beyond "you can". Is there anything more to it than that?

I think it's partly "you can", but surprisingly enough I also feel that node's single-threaded architecture makes code surprisingly easy to reason about.

I’ve seen people think they’re reasoning about it when I fact they are not. I was on a project where the developers we Node pros for years. They were flummoxed when they couldn’t introduce transactions because they didn’t close over the database connection. When I said they had to hold the same connection through all the method calls, I was told I was wrong and that a global pool would be able to handle that without some external tracking mechanism.

Re: A 7KB AWS lambda Node.js library with zero runtime dependencies

#38

Post by makstaks »

s_Hogg wrote: post #2

Not knowing this myself, could someone explain the attraction in using a web scripting framework for stuff like this? I get that this particular example makes the whole thing seem fairly straightforward, but have never really heard why people like adapting Node.js and similar to non-web environments beyond "you can". Is there anything more to it than that?

I'm not sure if I understand your question. What do you mean by "web scripting framework?". NodeJS is a server-side runtime. It just so happens to use Javascript as the programming language. Its strength is handling async event-driven requests, so given that AWS Lambda's strength is existing within an event-driven architecture, it's a natural pairing.

Re: A 7KB AWS lambda Node.js library with zero runtime dependencies

#40

Post by staticassertion »

golergka wrote: post #24
spion wrote: post #12

Earlier quoted context omitted.

For those situations where the GC becomes a performance (or more likely memory usage) problem, it seems reasonable that the built-in WASM support of most engines will be able to provide an adequate performance (its already getting quite close): https://www.usenix.org/conference/atc19/presentation/jangda

Anything CPU-bound is a very bad fit for node. But most web services are IO-bound, and Node is excellent for them.

> But most web services are IO-bound

Node's still relatively slow for those workloads.

https://www.techempower.com/benchmarks/#section=data-r18&hw=...

See how far down in each section you have to scroll to find node, even for workloads that are purely "accept a request and respond with a static string". You'll see lots of Java and Go on your way down.

And most services will have far more compute than just shoving bytes in between services. There's request parsing, response encoding, usually at least a tiny bit of data manipulation.

Post reply on HN