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

331–340 of 448 posts

Re: Modern Node.js Patterns

#331

Post by berkes »

batmansmk wrote: post #311
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?

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 d…

If cron is broken for you, than the logic solution would be to replace it with something that does work for you. But do so at the right place and abstraction. That's hardly ever the runtime or in the app.

Do One Thing (and do it well).

A special domain specific scheduler microservice? One of the many Cron replacements? One of the many "SaaS cron"? Systemd?

This problem has been solved. Corner cases ironed out. Free to use.

Same for ENV var as configurations (as opposed to inventing yet another config solution), file permissions, monitoring, networking, sandboxing, chrooting etc. the amount of broken, insecure or just inefficient DIY versions of stuff handled in an OS I've had to work around is mind boggling. Causing a trice a loss: the time taken to build it. That time not spent on the business domain, and the time to them maintain and debug it for the next fifteen years.

Re: Modern Node.js Patterns

#332

Post by berkes »

hk1337 wrote: post #304
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?

> The "proper" place to solve this, is in the OS. This is my thought on using dotenv libraries. The app shouldn’t have to load environment variables, only read them. Using a dotenv function/plugin like in omz is far more preferable.

Entirely.

The argument often heard though is 'but windows'. Though if windows lacks env (or Cron, or chroot, etc) the solution would be to either move to an env that does support it, or introduce some tooling only for the windows users.

Not build a complex, hierarchical directory scanner that finds and merges all sorts of .env .env.local and whatnots.

On dev I often do use .ENV files, but use zenv or a loadenv tool or script outside of the projects codebase to then load these files into the env.

Re: Modern Node.js Patterns

#333

Post by berkes »

brulard wrote: post #285
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 many apps do you think has properly set user and access rights only to what they need? In production? If even that percentage was high, how about developers machines, people that run some node scripts which might import whoever knows what? It is possible to have it running safely, but I doubt it's a high percentage of people. Feature like this can increase that percentage

Wouldn't "simplifying" or even awareness of the existence of such OS features be a much better solution than re-building it in a runtime?

If an existing feature is used too little, then I'm not sure if rebuilding it elsewhere is the proper solution. Unless the existing feature is in a fundamentally wrong place. Which this isn't: the OS is probably the only right place for access permissions.

An obvious solution would be education. Teach people how to use docker mounts right. How to use chroot. How Linux' chmod and chown work. Or provide modern and usable alternatives to those.

Re: Modern Node.js Patterns

#334

Post by Chyzwar »

bakkoting wrote: post #204
bikeshaving wrote: post #133

Earlier quoted context omitted.

The fact that CJS/ESM compatibility issues are going away indicates it was always a design choice and never a technical limitation (most CJS format code can consume ESM and vice versa). So much lost time to this problem.

It was neither a design choice nor a technical limitation. It was a big complicated thing which necessarily involved fiddly internal work and coordination between relatively isolated groups. It got done when someone (Joyee Cheung) actually made the fairly heroic effort to push through all of that. Joyee has a nice post going into details. Reading this gives a much more accurate picture of why things do and don't happ…

Node.js made many decisions that have massive impact on ESM adoption. From forcing extensions and dropping index.js to loaders and complicated package.json "exports". In addition to node.js steamrolling everyone, tc39 keep making are idiotic changes to spec like `deffered import` and `with` syntax changes.

Re: Modern Node.js Patterns

#336

Post by nedt »

palmfacehn wrote: post #230
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…

> JS on the backend was arguably an even bigger mistake when the JS ecosystem was less sophisticated.

I see it being used since over 25 years for the Austrian national broadcaster. Based at least originally on rhino, so it's also mixed with the Java you love. Fail to see the big issue as it's working just fine for such a long time.

Re: Modern Node.js Patterns

#337

Post by jappgar »

jmull wrote: post #153

Something's missing in the "Modern Event Handling with AsyncIterators" section. The demonstration code emits events, but nothing receives them. Hopefully some copy-paste error, and not more AI generated crap filling up the internet.

(Async) Iterators are definitionally pull-based and not suitable for event (push) handling.

They've also been around for years as another poster mentioned.

Re: Modern Node.js Patterns

#338

Post by _heimdall »

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?

OS level checks will inevitably work differently on different OSes and different versions. Having a check like this in the app binary itself means you can have a standard implementation regardless of the OS running the app.

I often hear similar arguments for or against database level security rules. Row level security, for example, is a really powerful feature and in my opinion is worth using when you can. Using RLS doesn't mean you skip checking authorization rules at the API level though, you check on author in your business logic _and_ in the database.

Re: Modern Node.js Patterns

#339

Post by brulard »

berkes wrote: post #333
brulard wrote: post #285

Earlier quoted context omitted.

How many apps do you think has properly set user and access rights only to what they need? In production? If even that percentage was high, how about developers machines, people that run some node scripts which might import whoever knows what? It is possible to have it running safely, but I doubt it's a high percentage of people. Feature like this can increase that percentage

Wouldn't "simplifying" or even awareness of the existence of such OS features be a much better solution than re-building it in a runtime? If an existing feature is used too little, then I'm not sure if rebuilding it elsewhere is the proper solution. Unless the existing feature is in a fundamentally wrong place. Which this isn't: the OS is probably the only right place for access permissions. An obvious solution would…

Your point about OS caring about this stuff is solid, but saying a solution is education seems a little bit naive. How are you going to teach people? Or who is going to do that? If node runtime makes its use safer by implementing this, that helps a lot of people. To say people need to learn themselves helps noone.

Re: Modern Node.js Patterns

#340

Post by evanjrowley »

Cthulhu_ wrote: post #269
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 do this in a native fashion? I mean I believe you (chroot jail I think it was?), but not everyone runs on *nix systems, and perhaps more importantly, not all Node developers know or want to know much about the underlying operating system. Which is to their detriment, of course, but a lot of people are "stuck" in their ecosystem. This is arguably even worse in the Java ecosystem, but it's considered a se…

OpenBSD pledge

https://man.openbsd.org/pledge.2

Post reply on HN