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

Modern Node.js Patterns

kashw1n.com

Post reply on HN
Print view View original

291–300 of 448 posts

Re: Modern Node.js Patterns

#291

Post by tchetwin »

captn3m0 wrote: post #274
simonw wrote: post #113

Whoa, I didn't know about this: # Run with restricted file system access node --experimental-permission \ --allow-fs-read=./data --allow-fs-write=./logs app.js # Network restrictions node --experimental-permission \ --allow-net=api.example.com app.js Looks like they were inspired by Deno. That's an excellent feature. https://docs.deno.com/runtime/fundamentals/security/#permiss...

Can't seem to find an official docs link for allow-net, only blog posts.

https://github.com/nodejs/node/pull/58517 - I think the `semver-major` and the timing mean that it might not be available until v25, around October

Re: Modern Node.js Patterns

#292

Post by zero_shift »

berkes wrote: post #242
simonw wrote: post #113

Whoa, I didn't know about this: # Run with restricted file system access node --experimental-permission \ --allow-fs-read=./data --allow-fs-write=./logs app.js # Network restrictions node --experimental-permission \ --allow-net=api.example.com app.js Looks like they were inspired by Deno. That's an excellent feature. https://docs.deno.com/runtime/fundamentals/security/#permiss...

I very much dislike such features in a runtime or app. The "proper" place to solve this, is in the OS. Where it has been solved, including all the inevitable corner cases, already. Why reinvent this wheel, adding complexity, bug-surface, maintenance burden and whatnot to your project? What problem dies it solve that hasn't been solved by other people?

> Why reinvent this wheel, adding complexity, bug-surface, maintenance burden and whatnot to your project? What problem dies it solve that hasn't been solved by other people?

Whilst this is (effectively) an Argument From Authority, what makes you assume the Node team haven't considered this? They're famously conservative about implementing anything that adds indirection or layers. And they're very *nix focused.

I am pretty sure they've considered "I could just run this script under a different user"

(I would assume it's there because the Permissions API covers many resources and side effects, some of which would be difficult to reproduce across OSes, but I don't have the original proposal to look at and verify)

Re: Modern Node.js Patterns

#293

Post by arccy »

kijin wrote: post #215
simonw wrote: post #113

Whoa, I didn't know about this: # Run with restricted file system access node --experimental-permission \ --allow-fs-read=./data --allow-fs-write=./logs app.js # Network restrictions node --experimental-permission \ --allow-net=api.example.com app.js Looks like they were inspired by Deno. That's an excellent feature. https://docs.deno.com/runtime/fundamentals/security/#permiss...

Path restrictions look simple, but they're very difficult to implement correctly. PHP used to have (actually, still has) an "open_basedir" setting to restrict where a script could read or write, but people found out a number of ways to bypass that using symlinks and other shenanigans. It took a while for the devs to fix the known loopholes. Looks like node has been going through a similar process in the last couple o…

I believe that the various OSes have implemented appropriate syscalls such as openat to support it

e.x. https://go.dev/blog/osroot

Re: Modern Node.js Patterns

#294

Post by sethaurus »

mcv wrote: post #249
mythz wrote: post #196

Earlier quoted context omitted.

why not? const data = await (await fetch(url)).json()

That's very concise. Still, the double await remains weird. Why is that necessary?

The first `await` is waiting for the response-headers to arrive, so you know the status code and can decide what to do next. The second `await` is waiting for the full body to arrive (and get parsed as JSON).

It's designed that way to support doing things other than buffering the whole body; you might choose to stream it, close the connection early etc. But it comes at the cost of awkward double-awaiting for the common case (always load the whole body and then decide what happens next).

Re: Modern Node.js Patterns

#295

Post by moritzruth »

mcv wrote: post #249
mythz wrote: post #196

Earlier quoted context omitted.

why not? const data = await (await fetch(url)).json()

That's very concise. Still, the double await remains weird. Why is that necessary?

IMU because you don't necessarily want the response body. The first promise resolves after the headers are received, the .json() promise resolves only after the full body is received (and JSON.parse'd, but that's sync anyway).

Re: Modern Node.js Patterns

#296

Post by PartiallyTyped »

bilalq wrote: post #217
hliyan wrote: post #179

Earlier quoted context omitted.

There has to be something wrong with a tech stack (Node + Lambda) that adds 100ms latency for some requests, just to gain the capability [1] to send out HTTP requests within an environment that almost entirely communicates via HTTP requests. [1] convenient capability - otherwise you'd use XMLHttpRequest

1. This is not 100ms latency for requests. It's 100ms latency for the init of a process that loads this code. And this was specifically in the context of a Lambda function that may only have 128MB RAM and like 0.25vCPU. A hello world app written in Java that has zero imports and just prints to stdout would have higher init latency than this. 2. You don't need to use axios. The main value was that it provides a unifie…

On init lambda funcs run a full core, but on invoke the 128MB run at 1/20 core.

Re: Modern Node.js Patterns

#297

Post by zero_shift »

andai wrote: post #151
farkin88 wrote: post #16

The killer upgrade here isn’t ESM. It’s Node baking fetch + AbortController into core. Dropping axios/node-fetch trimmed my Lambda bundle and shaved about 100 ms off cold-start latency. If you’re still npm i axios out of habit, 2025 Node is your cue to drop the training wheels.

16 years after launch, the JS runtime centered around network requests now supports network requests out of the box.

What a strange comment. You could always do network calls. Fetch is an API that has similar semantics across browser and server, using Promises.

Re: Modern Node.js Patterns

#298

Post by epolanski »

berkes wrote: post #242
simonw wrote: post #113

Whoa, I didn't know about this: # Run with restricted file system access node --experimental-permission \ --allow-fs-read=./data --allow-fs-write=./logs app.js # Network restrictions node --experimental-permission \ --allow-net=api.example.com app.js Looks like they were inspired by Deno. That's an excellent feature. https://docs.deno.com/runtime/fundamentals/security/#permiss...

I very much dislike such features in a runtime or app. The "proper" place to solve this, is in the OS. Where it has been solved, including all the inevitable corner cases, already. Why reinvent this wheel, adding complexity, bug-surface, maintenance burden and whatnot to your project? What problem dies it solve that hasn't been solved by other people?

What's there to dislike? They don't replace the restrictions at OS level, they add to it.

Re: Modern Node.js Patterns

#299

Post by valenterry »

As a primary backend developer, I want to add my two cents:

> Top-Level Await: Simplifying Initialization

This feels absolutely horrible to me. There is no excuse for not having a proper entry-point function that gives full control to the developer to execute everything that is needed before anything else happens. Such as creating database connections, starting services and connecting to APIs, warming up caches and so on. All those things should be run (potentially concurrent).

Until this is possible, even with top-level await, I personally have to consider node.js to be broken.

> Modern Testing with Node.js Built-in Test Runner

Sorry, but please do one thing and do it well.

> Async/Await with Enhanced Error Handling

I wish had JVM-like logging and stack traces (including cause-nesting) in node.js...

> 6. Worker Threads: True Parallelism for CPU-Intensive Tasks

This is the biggest issue. There should be really an alternative that has builtin support for parallelism that doesn't force me to de/serialize things by hand.

---

Otherwise a lot of nice progress. But the above ones are bummers.

Re: Modern Node.js Patterns

#300

Post by epolanski »

andai wrote: post #151
farkin88 wrote: post #16

The killer upgrade here isn’t ESM. It’s Node baking fetch + AbortController into core. Dropping axios/node-fetch trimmed my Lambda bundle and shaved about 100 ms off cold-start latency. If you’re still npm i axios out of habit, 2025 Node is your cue to drop the training wheels.

16 years after launch, the JS runtime centered around network requests now supports network requests out of the box.

Node always had a lower level http module.
Post reply on HN