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

351–360 of 448 posts

Re: Modern Node.js Patterns

#351

Post by chamomeal »

pavel_lishin wrote: post #87
vinnymac wrote: post #70

Earlier quoted context omitted.

If you haven't tried vitest I highly recommend giving it a go. It is compatible with `jest-extended` and most of the jest matcher libraries out there.

I've heard it recommended; other than speed, what does it have to offer? I'm not too worried about shaving off half-a-second off of my personal projects' 5-second test run :P

Also it’s got a really nice browser UI. Colocates logs by specific test run. Super nice.

I’m sure there’s a package for jest to do that (idk maybe that’s what jest extended is?) but the vitest experience is really nice and complete

Re: Modern Node.js Patterns

#352

Post by vincnetas »

vlovich123 wrote: post #345
berkes wrote: post #242

Earlier quoted context omitted.

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?

Except, the OS hasn’t actually solved it. Any program you can run can access arbitrary files of yours and it’s quite difficult to actually control that access even if you want to limit the blast radius of your own software. Seriously - what software works you use? Go write eBPF to act as a mini adhoc hypervisor to enforce difficult to write policies via seLinux? That only even works if you’re the admin of the machine…

"Any program you can run". But you should not run any program as YOU. Programs can run as separate limited user.

Re: Modern Node.js Patterns

#353

Post by simonw »

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?

How would you solve this at the OS level across Linux, macOS and Windows?

I've been trying to figure out a good way to do this for my Python projects for a couple of years now. I don't yet trust any of the solutions I've come up with - they are inconsistent with each other and feel very ironed to me making mistakes due to their inherent complexity and lack of documentation that I trust.

Re: Modern Node.js Patterns

#354

Post by spacebanana7 »

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?

Putting network restrictions in the application layer also causes awkward issues for the org structures of many enterprises.

For example, the problem of "one micro service won't connect to another" was traditionally an ops / environments / SRE problem. But now the app development team has to get involved, just in case someone's used one of these new restrictions. Or those other teams need to learn about node.

This is non consensual devops being forced upon us, where everyone has to learn everything.

Re: Modern Node.js Patterns

#355

Post by spacebanana7 »

simonw wrote: post #353
berkes wrote: post #242

Earlier quoted context omitted.

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?

How would you solve this at the OS level across Linux, macOS and Windows? I've been trying to figure out a good way to do this for my Python projects for a couple of years now. I don't yet trust any of the solutions I've come up with - they are inconsistent with each other and feel very ironed to me making mistakes due to their inherent complexity and lack of documentation that I trust.

If something is solved at the OS level it probably needs to vary by OS. Just like how an application layer solution to parsing data must vary slightly between nodeJS and java.

For a solution to be truly generic to OS, it's likely better done at the network level. Like by putting your traffic through a proxy that only allows traffic to certain whitelisted / blacklisted destinations.

Re: Modern Node.js Patterns

#356

Post by pmbanugo »

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.

tell me you're not a Node.js developer :)

Re: Modern Node.js Patterns

#357

Post by rvz »

wiseowise wrote: post #282
rvz wrote: post #130

Perhaps the technology that you are using is loaded with hundreds of foot-guns if you have to spend time on enforcing these patterns. Rather than taking the logical focus on making money, it is wasting time on shuffling around code and being an architecture astronaut with the main focus on details rather than shipping. One of the biggest errors one can make is still using Node.js and Javascript on the server in 2025.

What the f are you even talking about. It literally lists features modern Node.js has, there’s nothing to enforce.

Read the comment again:

> Perhaps the technology that you are using is loaded with hundreds of foot-guns

"Modern features" in Node.js means nothing given the entire ecosystem and its language is extremely easy to shoot yourself in the foot.

Re: Modern Node.js Patterns

#358

Post by simonw »

spacebanana7 wrote: post #355
simonw wrote: post #353

Earlier quoted context omitted.

How would you solve this at the OS level across Linux, macOS and Windows? I've been trying to figure out a good way to do this for my Python projects for a couple of years now. I don't yet trust any of the solutions I've come up with - they are inconsistent with each other and feel very ironed to me making mistakes due to their inherent complexity and lack of documentation that I trust.

If something is solved at the OS level it probably needs to vary by OS. Just like how an application layer solution to parsing data must vary slightly between nodeJS and java. For a solution to be truly generic to OS, it's likely better done at the network level. Like by putting your traffic through a proxy that only allows traffic to certain whitelisted / blacklisted destinations.

The proxy thing solved for betroth access but not for filesystem access.

With proxies the challenge becomes how to ensure the untrusted code in the programming language only accesses the network via the proxy. Outside of containers and iptables I haven't seen a way to do that.

Re: Modern Node.js Patterns

#359

Post by CSSer »

rikafurude21 wrote: post #328
CSSer wrote: post #268

Earlier quoted context omitted.

It took me a couple hours, but I got it working for both uploads and downloads with a nice progress bar. My uploadFile method is about 40 lines of formatted code, and my downloadFile method is about 28 lines. It's pretty simple once you figure it out! Note that a key detail is that your server (and any intermediate servers, such as a reverse-proxy) must support HTTP/2 or QUIC. I spent much more time on that than the…

can we see a gist?

https://github.com/hu0p/fetch-transfer-progress-demo/

Re: Modern Node.js Patterns

#360

Post by spacebanana7 »

simonw wrote: post #358
spacebanana7 wrote: post #355

Earlier quoted context omitted.

If something is solved at the OS level it probably needs to vary by OS. Just like how an application layer solution to parsing data must vary slightly between nodeJS and java. For a solution to be truly generic to OS, it's likely better done at the network level. Like by putting your traffic through a proxy that only allows traffic to certain whitelisted / blacklisted destinations.

The proxy thing solved for betroth access but not for filesystem access. With proxies the challenge becomes how to ensure the untrusted code in the programming language only accesses the network via the proxy. Outside of containers and iptables I haven't seen a way to do that.

I guess my point was that we have different OS's precisely because people want to do things in different ways. So we can't have generic ways to do them.

OS generic filesystem permissions would be like a OS generic UI framework, it's inherently very difficult and ultimately limited.

Separately, I totally sympathise with you that the OS solutions to networking and filesystem permissions are painful to work with. Even though I'm reasonably comfortable with rwx permissions, I'd never allow untrusted code on a machine which also had sensitive files on it. But I think we should fix this by coming up with better OS tooling, not by moving the problem to the app layer.

Post reply on HN