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

311–320 of 448 posts

Re: Modern Node.js Patterns

#311

Post by batmansmk »

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?

For years, I heard it's better to use cron, because the problem was already solved the right way(tm). My experience with cron has been about a dozen difficult fixes in production of cron not running / not with the right permission / errors lost without being logged / ... Changing / upgrading OSes became a problem. I since switched to a small node script with a basic scheduler in it, I had ZERO issues in 7 years. My devs happily add entries in the scheduler without bothering me. We even added consistency checks, asserts, scheduled one time execution tasks, ... and now multi server scheduling.

Deployments that need to configure OSes in a particular way are difficult (the existence of docker, kubernetes, snap are symptoms of this difficulty). It requires a high level of privilege to do so. Upgrades and rollbacks are challenging, if ever done. OSes sometimes don't provide solution when we go beyond one hardware.

If "npm start" can restrain the permissions to what it should be for the given version of the code, I will use it and I'll be happy.

Re: Modern Node.js Patterns

#312

Post by mcv »

int_19h wrote: post #234
theThree wrote: post #120

Earlier quoted context omitted.

It's still not ready for use. I don't care Enum. But you can not import local files without extensions. You can not define class properties in constructor.

Why not import files with extensions? That's the way JS (and TS) import is actually supposed to work.

I have to admit I was a bit surprised when I was suddenly expected to get rid of all extensions in import. Sure, looks clean, but is it right?

Re: Modern Node.js Patterns

#313

Post by mcv »

hungryhobbit wrote: post #80
tyleo wrote: post #10

This is great. I learned several things reading this that I can immediately apply to my small personal projects. 1. Node has built in test support now: looks like I can drop jest! 2. Node has built in watch support now: looks like I can drop nodemon!

Eh, the Node test stuff is pretty crappy, and the Node people aren't interested in improving it. Try it for a few weeks before diving headfirst into it, and you'll see what I mean (and then if you go to file about those issues, you'll see the Node team not care).

Could you expand on the shortcomings of Node test compared to jest?

Re: Modern Node.js Patterns

#314

Post by moogly »

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.

With node:fetch you're going to have to write a wrapper for error handling/logging/retries etc. in any app/service of size. After a while, we ended up with something axios/got-like anyway that we had to fix a bunch of bugs in.

Re: Modern Node.js Patterns

#315

Post by larsnystrom »

moogly wrote: post #314
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.

With node:fetch you're going to have to write a wrapper for error handling/logging/retries etc. in any app/service of size. After a while, we ended up with something axios/got-like anyway that we had to fix a bunch of bugs in.

And AFAIK there is still no upload progress with fetch.

Re: Modern Node.js Patterns

#316

Post by [deleted] »

pbreit wrote: post #74
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.

It has always astonished me that platforms did not have first class, native "http client" support. Pretty much every project in the past 20 years has needed such a thing. Also, "fetch" is lousy naming considering most API calls are POST.

[deleted]

Re: Modern Node.js Patterns

#317

Post by spixy »

hollowturtle wrote: post #289

Am I the only one believing common js was super ok and don't like esm? Or put differently I didn't see the necessity of having esm at all in Node. Let alone the browser, imagine loading tons of modules over the wire instead of bundle them

Yes.

Also CommonJS does not support tree shaking.

Re: Modern Node.js Patterns

#318

Post by moogly »

tyleo wrote: post #10

This is great. I learned several things reading this that I can immediately apply to my small personal projects. 1. Node has built in test support now: looks like I can drop jest! 2. Node has built in watch support now: looks like I can drop nodemon!

I tried node:test and I feel this is very useful for tiny projects and library authors who need to cut down on 3rd party dependencies, but it's just too barebones for larger apps and node:assert is a bit of a toy, so at a minimum you want to pull in a more full-fledged assertion library. vitest "just works", however, and paves over a lot of TypeScript config malarkey. Jest collapsed under its own weight.

Re: Modern Node.js Patterns

#319

Post by looshch »

yawnxyz wrote: post #27
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.

node fetch is WAY better than axios (easier to use/understand, simpler); didn't really know people were still using axios

what about interceptors?

Re: Modern Node.js Patterns

#320

Post by austin-cheney »

xbbdbd wrote: post #224
austin-cheney wrote: post #181

Earlier quoted context omitted.

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

There is no cleverness involved. The escape sequences are decades old and universally supported as a de facto standard. In this case the escape sequences are assigned to variables that are attached to other strings. This is as clever as using an operator. These escape sequences are even supported by Chromes dev tools console directly in the browser.

The real issue is invented here syndrome. People irrationally defer to libraries to cure their emotional fear of uncertainty. For really large problems, like complete terminal emulation, I understand that. However, when taken to an extreme, like the left pad debacle, it’s clear people are loading up on dependencies for irrational reasons.

Post reply on HN