I created and use this tiny helper: http://g14n.info/aws-lambda-res/
I think it is far enough for my needs, it is nice to use no framework other than the one provided by AWS.
A 7KB AWS lambda Node.js library with zero runtime dependencies
41–50 of 63 posts
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#42Earlier quoted context omitted.
> The performance is also quite comparable to statically typed GCed languages. (For example, you can probably get to 50%-90% of Java performance on most single-threaded workloads) Citation needed, please. I disagree with this. I recently was able to achieve a massive speedup in a Node application through writing a native C++ module... and implementing Garbage Collection is required for N-API.
An interesting blog post on how that might be done: https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...
That was amazing to re-read, thanks for sharing. news.yc discussion back on tfa back in the day is a pretty good read, too: https://news.ycombinator.com/item?id=16413917
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#43Earlier quoted context omitted.
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 byt…
This benchmark mainly measures the performance of the HTTP parsing and database libraries, often in a suboptimal default configuration. In node land, they're admittedly not amazing, but nothing about the language prevents them from being better.
For example, for a long time, the only reason that node was slow on these benchmarks was the built-in URL parser. Replacing it with this carefully written module https://www.npmjs.com/package/fast-url-parser resulted in 2x improvements on the benchmark. I haven't looked closely at the situation nowadays but I imagine its still quite similar with lots of low hanging fruit lying around and stalled due to backward-compatibility concerns.
For proof find "es4x" in the benchmark list, which basically replaces the entire stack of HTTP parsing and database libraries with the ones from vert.x and runs JS on Graal, even though Graal is currently at least 2.5x slower than V8 in terms of JS performance: https://github.com/graalvm/graaljs/issues/74
Node core (and the libraries around it) has unfortunately stalled in the "good enough" zone for quite a while. The good bit is that they stay in the good-enough zone after adding your own code.
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#44Earlier quoted context omitted.
IMO, Node's superpower is not really in the language but in the NPM ecosystem. If that is not attractive to you (maybe you develop the whole system by yourself, or need fine-tuned performance), Node only has to offer an ubiquous language, and that's about it.
People overlook the fact that JS is a pretty nice modern language in its own right. "Because you can" is pointlessly dismissive and indicates to me that one still thinks JS is nothing more than a language to toggle a CSS class on because they haven't used it since people used the word DHTML. - async-everything, not a blocking language where anything async relegates you to a subecosystem like you have it in basically…
> “ JS is a pretty nice modern language“
Are we talking about the same JS here? Because the JS I know is a dumpster fire of a language.
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#45Earlier quoted context omitted.
> 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 byt…
This benchmark mainly measures the performance of the HTTP parsing and database libraries, often in a suboptimal default configuration. In node land, they're admittedly not amazing, but nothing about the language prevents them from being better. For example, for a long time, the only reason that node was slow on these benchmarks was the built-in URL parser. Replacing it with this carefully written module https://www.…
I think your point is actually just proving something important that I ended my initial post with - that there is almost never a "pure IO" workload, but that compute is actually an extremely important part of any service. Given node's concurrency model it's even more important, as compute can block other operations.
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#46Earlier quoted context omitted.
This benchmark mainly measures the performance of the HTTP parsing and database libraries, often in a suboptimal default configuration. In node land, they're admittedly not amazing, but nothing about the language prevents them from being better. For example, for a long time, the only reason that node was slow on these benchmarks was the built-in URL parser. Replacing it with this carefully written module https://www.…
I think your point is actually just proving something important that I ended my initial post with - that there is almost never a "pure IO" workload, but that compute is actually an extremely important part of any service. Given node's concurrency model it's even more important, as compute can block other operations.
I had another glance at the framework benchmark, and the quality is absolutely dreadful
I removed the unnecessary middleware bloat (pug html renderer middleware for an API server, really? body-parser and form parser even for endpoints where it's not being used?) and switched to standard pg instead of pg-promise (standard pg also supports promises, pg-promise hasn't been needed for quite a while now)
The performance went from 600req/s to 5500 req/s on the db benchmark, 9x improvement with 10 minutes of work. I think thats a pretty damning result for the tech-empower framework benchmarks quality, at least when it comes to node. This is just standard libraries and practices, not even hacks like replacing the built in url parser with fast-url-parser.
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#47Earlier quoted context omitted.
I think your point is actually just proving something important that I ended my initial post with - that there is almost never a "pure IO" workload, but that compute is actually an extremely important part of any service. Given node's concurrency model it's even more important, as compute can block other operations.
I had another glance at the framework benchmark, and the quality is absolutely dreadful I removed the unnecessary middleware bloat (pug html renderer middleware for an API server, really? body-parser and form parser even for endpoints where it's not being used?) and switched to standard pg instead of pg-promise (standard pg also supports promises, pg-promise hasn't been needed for quite a while now) The performance w…
Submit that to them then?
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#48Earlier quoted context omitted.
I had another glance at the framework benchmark, and the quality is absolutely dreadful I removed the unnecessary middleware bloat (pug html renderer middleware for an API server, really? body-parser and form parser even for endpoints where it's not being used?) and switched to standard pg instead of pg-promise (standard pg also supports promises, pg-promise hasn't been needed for quite a while now) The performance w…
Submit that to them then?
It might be a good idea, although I fear that if I only fix one node framework and keep the rest intact it will create a false impression that that framework is somehow amazing.
Still better than a false impression that nodejs is somehow slow.
They really need some QC though.
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#49I'm sorry but why can't you just call a few functions in your normal handler and then just return the normal type of object that Lambda wants?
This all seems to be pretty useless indirection to me.
Re: A 7KB AWS lambda Node.js library with zero runtime dependencies
#50Not 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?
It's a Turing-complete, general-purpose programming language. What should stop you using it for anything?
LOL. so is brainfuck, but why don't people use it for everything and anything? Just because something is turing complete doesn't mean its well designed.