
A 7KB AWS lambda Node.js library with zero runtime dependencies - albertgao
https://www.npmjs.com/package/micro-aws-lambda
======
s_Hogg
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?

~~~
spion
Main strengths:

* The ecosystem is pretty strong and constantly evolving. Lots of companies and individuals are putting a serious amount of work into making high-quality tooling and libraries. (Although with that also comes a lot of lower quality stuff and its sometimes hard to tell)

* The language isn't owned by any single company and is well specified

* TypeScript provides a powerful and flexible type system with advanced dependant-types like features. Lets you gradually evolve from a messy JS prototype to well-organized code with fairly strict type checking

* Fastest dynamic language. 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)

* wasm support in the runtime a promising escape hatch to the integration with other languages should that become needed. (Similarly not owned by a single company and well-specified)

* sharing code and types between client and server, including interfaces, validation and data models.

* particularly well suited to handling heterogeneous structured data due to how cheap it is to define new object types (even in typescript)

* Async-IO-first (in fact, async-only IO for the most part)

Main weaknesses:

* Poor standard library with an anemic set of classes, anemic set of implementable protocols/interfaces (more stuff like Symbol.asyncIterable needed) and lacking convenience functions. E.g. see [https://api.dart.dev/stable/2.7.1/dart-async/Stream-class.ht...](https://api.dart.dev/stable/2.7.1/dart-async/Stream-class.html) and compare with... well nothing in the language! The official node streams have a terrible API.

* Combining lack of both protocols and standard library leads to pretty bad userspace library fragmentation. (What is the go-to stream library?)

* Restricted data sharing between threads (only SharedArrayBuffer) makes it quite limited for multi-threaded problems.

* (mainly TypeScript) - Insufficient reflection capabilities

* Rigid (non-configurable) node_modules resolution algorithm accepted as standard limits flexibility when organizing projects

Mythical weaknesses that don't matter that much:

* Implicit conversions - largely irrelevant since TypeScript

* DOM/Browser related weirdness - often attributed to the language but actually problems with browser APIs

~~~
gargarplex
> 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.

~~~
spion
[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html)

[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/fastest/javascript.html)

~~~
gargarplex
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.

~~~
spion
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.

~~~
gargarplex
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.

------
rebolyte
If you’re looking for more full-featured middleware functionality targeted at
Lambda, also check out Middy:

[https://github.com/middyjs/middy](https://github.com/middyjs/middy)

~~~
armatav
Someone HAS to start flagging these sorts of posts.

~~~
makstaks
@armatav why should this post be flagged? The recommendation was very helpful
to me and lets me compare two solutions.

------
ilaksh
I'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.

~~~
makstaks
@ilaksh the middleware pattern is a common pattern for many large frameworks
like ExpressJS and Ruby on Rails. It allows you to cleanly handle the request
and response cycle. From a code maintenance perspective, using a well-
established pattern that keeps your codebase module and extensible is desired.

If you have one or two lambda functions, then definitely this may be overkill,
like you said just call a few functions. But as your system matures and grows,
these few functions become a few modules, then your few modules become
libraries, so on and so forth. You might want to consider this pattern before
it's unclear what exactly is interacting with your requests and responses and
in what order.

------
616c
It wasn't obvious so I checked: zero runtime since it typescript and the
@types/aws-lambda stuff is not needed in resulting compiled JS. Still I'm not
sure what this does beyond until functions for events you receive in Lambda
and have to parse raw yourself?

~~~
616c
I meant util functions. Silly mobile HN clients, bah!

------
fibo
I created and use this tiny helper: [http://g14n.info/aws-lambda-
res/](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.

------
makstaks
Thank you for this library, I am looking forward to reviewing your work. I
didn't want to use a framework (like hapi or express) to achieve something
similar.

