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

221–230 of 448 posts

Re: Modern Node.js Patterns

#221

Post by tankenmate »

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 wouldn't trust it to be done right. It's like a bank trusting that all their customers will do the right thing. If you want MAC (as opposed to DAC), do it in the kernel like it's supposed to be; use apparmor or selinux. And both of those methods will allow you to control way more than just which files you can read / write.

Re: Modern Node.js Patterns

#222

Post by kookamamie »

pests wrote: post #216
CSSer wrote: post #210

Earlier quoted context omitted.

You can get download progress with fetch. You can't get upload progress. Edit: Actually, you can even get upload progress, but the implementation seems fraught due to scant documentation. You may be better off using XMLHttpRequest for that. I'm going to try a simple implementation now. This has piqued my curiosity.

Sniped

Nerd

Re: Modern Node.js Patterns

#223

Post by int_19h »

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…

Last time a major runtime tried implementing such restrictions on VM level, it was .NET - and it took that idea from Java, which did it only 5 years earlier.

In both Java and .NET VMs today, this entire facility is deprecated because they couldn't make it secure enough.

Re: Modern Node.js Patterns

#224

Post by xbbdbd »

austin-cheney wrote: post #181
vinnymac wrote: post #81

You no longer need to install chalk or picocolors either, you can now style text yourself: `const { styleText } = require('node:util');` Docs: https://nodejs.org/api/util.html#utilstyletextformat-text-op...

I never needed those. I would just have an application wide object property like: text: { angry : "\u001b[1m\u001b[31m", blue : "\u001b[34m", bold : "\u001b[1m", boldLine : "\u001b[1m\u001b[4m", clear : "\u001b[24m\u001b[22m", cyan : "\u001b[36m", green : "\u001b[32m", noColor : "\u001b[39m", none : "\u001b[0m", purple : "\u001b[35m", red : "\u001b[31m", underline: "\u001b[4m", yellow : "\u001b[33m" } And then you ca…

This is the problem with people trying to be clever. Now you output escape sequences regardless of terminal setting.

Using a library which handles that (an a thousand other quirks) makes much more sense

Re: Modern Node.js Patterns

#225

Post by porridgeraisin »

stevage wrote: post #162
tanduv wrote: post #78

Earlier quoted context omitted.

I never really liked the syntax of fetch and the need to await for the response.json, implementing additional error handling - async function fetchDataWithAxios() { try { const response = await axios.get('https://jsonplaceholder.typicode.com/posts/1'); console.log('Axios Data:', response.data); } catch (error) { console.error('Axios Error:', error); } } async function fetchDataWithFetch() { try { const response = awa…

I usually write it like: const data = (await fetch(url)).then(r => r.json()) But it's very easy obviously to wrap the syntax into whatever ergonomics you like.

You don't need all those parens:

  await fetch(url).then(r => r.json())

Re: Modern Node.js Patterns

#226

Post by xbbdbd »

bravesoul2 wrote: post #83

Anyone else find they discover these sorts of things by accident. I never know when a feature was added but vague ideas of "thats modern". Feels different to when I only did C# and you'd read the new language features and get all excited. In a polyglot world and just the rate even individual languages evolve its hard to keep up! I usually learn through osmosis or a blog post like this (but that is random learning).

Reading release notes would have solved that issue ;)

Re: Modern Node.js Patterns

#227

Post by int_19h »

macNchz wrote: post #106
bravesoul2 wrote: post #85

Earlier quoted context omitted.

AI is going to bring that back like an 80s disco playing Wham. If you gonna do it do it wrong...

I've had Claude decide to replace my existing fetch-based API calls with Axios (not installed or present at all in the project), apropos of nothing during an unrelated change.

I had Gemini correct my code using Google's new LLM API to use the old one.

Re: Modern Node.js Patterns

#228

Post by bombela »

tankenmate wrote: post #221
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 wouldn't trust it to be done right. It's like a bank trusting that all their customers will do the right thing. If you want MAC (as opposed to DAC), do it in the kernel like it's supposed to be; use apparmor or selinux. And both of those methods will allow you to control way more than just which files you can read / write.

Yeah but you see, this requires to be deployed along side the application somehow with the help of the ops team. While changing the command line is under control of the application developer.

Re: Modern Node.js Patterns

#229

Post by bravesoul2 »

xbbdbd wrote: post #226
bravesoul2 wrote: post #83

Anyone else find they discover these sorts of things by accident. I never know when a feature was added but vague ideas of "thats modern". Feels different to when I only did C# and you'd read the new language features and get all excited. In a polyglot world and just the rate even individual languages evolve its hard to keep up! I usually learn through osmosis or a blog post like this (but that is random learning).

Reading release notes would have solved that issue ;)

Which release notes. Id need to read hundreds!

Re: Modern Node.js Patterns

#230

Post by palmfacehn »

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.

JS on the backend was arguably an even bigger mistake when the JS ecosystem was less sophisticated. The levels of duct tape are dizzying. Although we might go back even further and ask if JS was also a mistake when it was added to the browser.

I often wonder about a what-if, alternate history scenario where Java had been rolled out to the browser in a more thoughtful way. Poor sandboxing, the Netscape plugin paradigm and perhaps Sun's licensing needs vs. Microsoft's practices ruined it.

Post reply on HN