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

181–190 of 448 posts

Re: Modern Node.js Patterns

#181

Post by austin-cheney »

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 can call that directly like:

    `${vars.text.green}whatever${vars.text.none}`;

Re: Modern Node.js Patterns

#182

Post by ninetyninenine »

jiggawatts wrote: post #128
MuffinFlavored wrote: post #88

Is current node.js a better language than .NET 6/7/8/9, why or why not?

In my experience, no. It's still single-threaded, it still uses millions of tiny files (making startup very slow), it still has wildly inconsistent basic management because it doesn't have "batteries included", etc...

You can bundle it all into one file and it's not single threaded anymore. There's this thing called worker_threads.

But yes there are downsides. But the biggest ones you brought up are not true.

Re: Modern Node.js Patterns

#183

Post by exhaze »

pnappa wrote: post #139
_heimdall wrote: post #137

Earlier quoted context omitted.

I always try to throw schema validation of some kind in API calls for any codebase I really need to be reliable. For prototypes I'll sometimes reach for tRPC. I don't like the level of magic it adds for a production app, but it is really quick to prototype with and we all just use RPC calls anyway. For procudtion I'm most comfortable with zod, but there are quite a few good options. I'll have a fetchApi or similar wr…

How do you supply the schema on the other side? I found that keeping the frontend & backend in sync was a challenge so I wrote a script that reads the schemas from the backend and generated an API file in the frontend.

There are a few ways, but I believe SSOT (single source of truth) is key, as others basically said. Some ways:

1. Shared TypeScript types

2. tRPC/ts-rest style: Automagic client w/ compile+runtime type safety

3. RTK (redux toolkit) query style: codegen'd frontend client

I personally I prefer #3 for its explicitness - you can actually review the code it generates for a new/changed endpoint. It does come w/ downside of more code + as codebase gets larger you start to need a cache to not regenerate the entire API every little change.

Overall, I find the explicit approach to be worth it, because, in my experience, it saves days/weeks of eng hours later on in large production codebases in terms of not chasing down server/client validation quirks.

Re: Modern Node.js Patterns

#185

Post by turadg »

gear54rus wrote: post #49
prmph wrote: post #38

I think slowly Node is shaping up to offer strong competition to Bun.js, Deno, etc. such that there is little reason to switch. The mutual competition is good for the continued development of JS runtimes

Slowly, yes, definitely welcome changes. I'm still missing Bun's `$` shell functions though. It's very convenient to use JS as a scripting language and don't really want to run 2 runtimes on my server.

Execa package works nicely for that. Zx has a good DX but is YA runtime.

https://github.com/sindresorhus/execa/blob/main/docs/bash.md

Re: Modern Node.js Patterns

#186

Post by jvuygbbkuurx »

koolba wrote: post #177
pnappa wrote: post #139

Earlier quoted context omitted.

How do you supply the schema on the other side? I found that keeping the frontend & backend in sync was a challenge so I wrote a script that reads the schemas from the backend and generated an API file in the frontend.

Write them both in TypeScript and have both the request and response shapes defined as schemas for each API endpoint. The server validates request bodies and produces responses that match the type signature of the response schema. The client code has an API where it takes the request body as its input shape. And the client can even validate the server responses to ensure they match the contract. It’s pretty beautiful…

This will break old clients. Having a deployment stategy taking that into account is important.

Re: Modern Node.js Patterns

#187

Post by yesbabyyes »

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.

It's definitely ai slop. See also the nonsensical attempt to conditionally load SQLite twice, in the dynamic imports example.

The list of features is nice, I suppose, for those who aren't keeping up with new releases, but IMO, if you're working with node and js professionally, you should know about most, if not all of these features.

Re: Modern Node.js Patterns

#188

Post by hnroo99 »

hnroo99 wrote: post #117
exhaze wrote: post #76

Earlier quoted context omitted.

Tangential, but thought I'd share since validation and API calls go hand-in-hand: I'm personally a fan of using `ts-rest` for the entire stack since it's the leanest of all the compile + runtime zod/json schema-based validation sets of libraries out there. It lets you plug in whatever HTTP client you want (personally, I use bun, or fastify in a node env). The added overhead is totally worth it (for me, anyway) for sh…

Just last week I was about to integrate `ts-rest` into a project for the same reasons you mentioned above... before I realized they don't have express v5 support yet: https://github.com/ts-rest/ts-rest/issues/715 I think `ts-rest` is a great library, but the lack of maintenance didn't make me feel confident to invest, even if I wasn't using express. Have you ever considered building your own in-house solution? I woul…

nvm I'm dumb lol, `ts-rest` does support express v5: https://github.com/ts-rest/ts-rest/pull/786. Don't listen to my misinformation above!!

I would say this oversight was a blessing in disguise though, I really do appreciate minimizing dependencies. If I could go back in time knowing what I know now, I still would've gone down the same path.

Re: Modern Node.js Patterns

#189

Post by jedwards1211 »

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.

This has been the case for quite awhile, most of the things in this article aren’t brand new

Re: Modern Node.js Patterns

#190

Post by johnny22 »

upcoming-sesame wrote: post #124
hungryhobbit wrote: post #80

Earlier quoted context omitted.

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).

still I would rather use that than import mocha, chai, Sinon, istanbul. At the end it's just tests, the syntax might be more verbose but Llms write it anyway ;-)

> but Llms write it anyway

The problem isn't in the writing, but the reading!

Post reply on HN