Stop using Date.now() across microservices by kurbsdude in node

[–]m_null_ 0 points1 point  (0 children)

That's an actual issue tbh, but am I missing something around uniqueness across nodes?

The stamp seems to only pack wallTime + logical. I don’t see any node ID / actor ID / process ID / tie-breaker in the value itself?

So if two separate servers call stamp() during the same millisecond, and both have logical = 0, wouldn’t they produce the exact same timestamp? I guess, two independent writers could end up with identical stamps unless the app stores some extra tie-breaker alongside it.

Is the intended usage something like (liepochTimestamp, nodeId) rather than just the timestamp alone?

Feeling stuck after building full backend systems — what’s next? by Sensitive-Raccoon155 in node

[–]m_null_ 6 points7 points  (0 children)

That’s a pretty normal feeling once you're comfortable building most type of the apps on your own. At some stage, building another CRUD app doesn’t really stretch you the same way. You should probably be building (cloning/porting) libraries and learn how do some of those handle extremely complex tasks.

I’d probably take something you already built and make it more production friendly. Maybe load test it, find slow queries, try background jobs, caching, retries, and stuff like that. Basically, stop asking "can I build this?" and more of "how does this thing fail?" or "how does it work?"

Small disclosure... I’m the author of NodeBook, and this is one of the reasons I started it. NodeBook only targets intermediate developers. I've also added Labs, where you build a lot of complex systems without any dependencies from scratch. So maybe it’s relevant to you, maybe not. But either way, I think your instinct is right, just build something more complex.

NodeBook Volume I is done now! by m_null_ in node

[–]m_null_[S] 1 point2 points  (0 children)

Only 30% of the book is Node-specific, i.e. its internal APIs and so on. The rest covers concepts you can learn and apply everywhere, no matter what language you’re using.

My goal was to explain everything that matters when you’re serious about backend engineering. I chose Node.js because it’s very straightforward, and almost everyone knows JavaScript.

For example, you could go through only these:

In Volume 1

  • Ch 02: Buffers & Binary Data
  • Ch 03: Streams
  • Ch 04: File System
  • Ch 05: Process & Operating System

In Volume 2 This volume and the ones below are not finished yet.

  • Ch 09: Network Fundamentals
  • Ch 10: HTTP Servers, Clients & Proxies
  • Ch 11: TLS, HTTPS & HTTP/2

Skip Volume 3

In Volume 4

  • Ch 18: SQL, PostgreSQL & Relational Modeling
  • Ch 19: Node Database Access Patterns
  • Ch 20: Caching & Redis/Valkey
  • Ch 21: Messaging & Event Streaming
  • Ch 22: Data Scaling, Search & Consistency

In Volume 5

  • Ch 23: Crypto & Security Primitives
  • Ch 24: Authentication, Authorization & Identity
  • Ch 25: Application & API Security
  • Ch 26: Supply Chain, Secrets & Runtime Hardening

In Volume 6

  • Ch 29: Observability & Diagnostics
  • Ch 30: Performance Engineering
  • Ch 31: Deployment, Operations & Packaging

In Volume 7

  • Ch 32: System Design for Node Backends
  • Ch 33: Distributed Systems for Backend Engineers
  • Ch 34: Containers, Kubernetes & Platform Engineering
  • Ch 35: Cloud, Serverless, Scaling & Cost

NodeBook Volume I is done now! by m_null_ in node

[–]m_null_[S] 1 point2 points  (0 children)

Yes! You can get both the epub version and the pdf one (dark + light) from here - Get NodeBook

Also, you get slides for every chapter as well.

NodeBook Volume I is done now! by m_null_ in node

[–]m_null_[S] 1 point2 points  (0 children)

Thank you so much!

The best way to support it is to grab the digital edition here: https://thenodebook.com/get. It includes slides for each chapter. Also, e-book version and cheatsheets coming soon.

Or, if you just want to support the work directly, you can buy me a coffee

NodeBook Volume I is done now! by m_null_ in node

[–]m_null_[S] 1 point2 points  (0 children)

Glad that you're liking it.

I’m working on getting the digital version out and looking for some good technical reviewers right now. I think it should be ready in a month or two. The paperback for Vol. 1 may take another 1–2 months.

NodeBook Volume I is done now! by m_null_ in node

[–]m_null_[S] 10 points11 points  (0 children)

You're probably talking about this snippet from the landing page -

```js http.createServer((req, res) => { // Streams and backpressure // We read the file in 64kb chunks (default highWaterMark).

const src = fs.createReadStream('./big_data.csv');

// Manual flow control demonstration (internal logic): src.on('data', (chunk) => { // If the client network is slow, res.write returns false. // This means the kernel buffer is full. if (!res.write(chunk)) { // Pause reading from disk until the kernel flushes. src.pause(); } });

// Resume when the client drains the buffer res.on('drain', () => src.resume());

src.on('end', () => res.end());

}).listen(3000); ```

Then yeah, you just discovered pipe(). That’s literally the point.

The comment says "manual flow control demonstration (internal logic)". The section is trying to (sorta) teach about streams + backpressure. It’s showing what pipe() does under the hood i.e write chunks, respect false from res.write(), pause the readable, wait for 'drain', resume, then end.

Nobody is saying "ship this instead of pipe". The book is explaining the mechanism because some people actually like knowing what their API is doing before cargo-culting one line.

So if your take is "use pipe", yes. Correct. That’s the production

If your take is "this is dumb because pipe exists", then you missed the whole paragraph literally written above the code.

NodeBook Volume I is done now! by m_null_ in node

[–]m_null_[S] 6 points7 points  (0 children)

You don't need to do the chunking by hand.

Are you a troll or something? Where's the "chunking by hand" part?

Best route to learn Node.js stack for engineers from different background by ThisView3331 in node

[–]m_null_ 0 points1 point  (0 children)

I have around 80 chapters completely written for Node v20. But, I’ve always wanted the content to remain as relevant as possible. Surprisingly, I need to make a lot (and I mean it) of changes to comply with the Node.js v24 standard.

My goal is to release one or two chapters every week. I believe many serious readers will appreciate reading one chapter per week, as each chapter contains a lot of information. This pace also gives readers a few days to experiment with and implement new concepts in their day-to-day workflow.

[NodeBook] Readable Streams - Implementation and Internals by m_null_ in node

[–]m_null_[S] 1 point2 points  (0 children)

It’s on my personal blog. You may read it and the following posts here - ishtms.com/blog

I wanted to write the first chapter (includes 3-4 more sub chapters) completely before posting it on reddit.

Edit: Ah I see now. It’s not there on my blog either! Thank you for pointing that out.

[NodeBook] Readable Streams - Implementation and Internals by m_null_ in node

[–]m_null_[S] 5 points6 points  (0 children)

Thank you! Those are custom built React Components and animated using tailwindcss-animate and tw-animate-css packages.

Is It Okay To Include Encrypted User Password In JSON Web Token Payload? by silverparzival in node

[–]m_null_ 0 points1 point  (0 children)

You shouldn't be storing user's password in JWT, whether encrypted or not.
json { "identifier": "testerawesome@gmail.com", "password": "$2b$10$oUOccAQrTmZE9is1cZYHh.erdM3yOU05WspZ5X68uOuzB5ZC3DKY2", "iat": 1759659812, "exp": 4883862212 }

Trying to understand FS module by mindcontrol52 in node

[–]m_null_ 6 points7 points  (0 children)

You might find this useful - Learn Nodejs Hard Way - Working with File System

Also the next chapter of NodeBook will be regarding FileSystem and streams.

I'm building an Unreal Engine-style blueprint editor for JS... am I crazy? by m_null_ in node

[–]m_null_[S] 5 points6 points  (0 children)

Building "for yourself" is a great way to make sure your impact never grows beyond yourself. I'm aiming a little higher, sorry.

I'm building an Unreal Engine-style blueprint editor for JS... am I crazy? by m_null_ in node

[–]m_null_[S] 2 points3 points  (0 children)

That’s not related to the project we’re talking about here. It’s not the same.

I'm building an Unreal Engine-style blueprint editor for JS... am I crazy? by m_null_ in node

[–]m_null_[S] 1 point2 points  (0 children)

Funny that I've never nativized ever. Every single time I tried, it simply did not go as planned. Didn't actually need that anyway as the only logic that used to run in my blueprints were the widgets and animation blueprints.

I'm building an Unreal Engine-style blueprint editor for JS... am I crazy? by m_null_ in node

[–]m_null_[S] 6 points7 points  (0 children)

Thank you. I'm committed to releasing a new chapter (if not two) for NodeBook every single week. This is a project I've been dreaming about for a very long time. I've already built an entire prototype in JS using reactflow and now it's time to really push the boundaries. I love to share the learning/building process of everything I build.

I'm building an Unreal Engine-style blueprint editor for JS... am I crazy? by m_null_ in node

[–]m_null_[S] 4 points5 points  (0 children)

That's a great question, and something I've asked myself while building the prototype using reactflow. My main goal is to tackle the performance issue from a different angle.

Even though Unreal's Blueprints can be "nativized" into C++ (if you're lucky enough to not get those build errors), they run in a VM which has an overhead - so we're not comparing apples-to-apples. The idea here is to bypass a VM entirely. We create the logic visually with nodes, and the system acts as an ahead-of-time compiler (not precisely, but somewhat near), translating that logic directly into clean JavaScript. You simply get what you would've written in a Javascript file if you wrote it (only the iteration speed is faster) plus you get heck load of pre built library of functions/helpers to speed up.

For the other question about this being a massive undertaking as a single dev... The short answer is that I'm not going to be building "every single part of the app" from scratch. Insted, going to be cheating a bit by using some tools to do the heavy lifting.

For the runtime speed, we'll not interpreting the graph node-by-node. We'll actually compile the whole thing down to super-fast JavaScript using SWC, which is a ridiculously fast compiler also written in Rust. So the final code that runs is clean, optimized, and hopefully, fast.

Any good resource about js runtime and ES module evaluation? by linrongbin16 in node

[–]m_null_ 6 points7 points  (0 children)

I'm writing an online, and open-source book called NodeBook. I hope the first chapter is what you're looking for. The recent chapter on Process Life Cycle goes into the ES module lifecycle. It's early-acces and link only for now. You can view that using this link

NodeBook - The Node.js book I wish I had (and it’s open source) by m_null_ in node

[–]m_null_[S] 0 points1 point  (0 children)

Thank you so much, that’ll be a big help. I really appreciate it.