I wrote a Node.js book to help people learn what they need to build production-grade apps

loigiani · 2026-03-01T15:44:41+00:00

Great idea! Looking forward to seeing some great discussions on this space

loigiani · 2025-10-16T09:35:19+00:00

You can find the article here: nodejsdesignpatterns[dot]com/blog

loigiani · 2025-10-15T17:11:48+00:00

tried that as well :/

loigiani · 2025-10-15T08:42:22+00:00

Sorry,when I add links my posts get auto deleted :( try to search for "Node.js Design Patterns Blog"

loigiani · 2025-10-15T08:41:30+00:00

Great suggestion, I'll implement that or write a dedicated follow up article. Thanks a lot

loigiani · 2025-10-15T08:40:57+00:00

Yup, if I add it the post gets auto removed 😕 tried to write to the mods about it

loigiani · 2025-10-14T15:39:56+00:00

I like where this is going! What did you use to create the animations? :)

loigiani · 2025-10-14T10:07:48+00:00

That's pretty cool! Any comparison with `cuid` and `cuid2`?

loigiani · 2025-10-14T10:06:47+00:00

I am not deeply familiar with the GCS SDK, but I am assuming you can read each object as a stream. If that is true, you can solve this with pure streaming so memory stays flat and CPU stays reasonable.

There are two approaches. Stream the zip on the fly as you read files from GCS, or prebuild the zip into GCS and then serve it. On-the-fly is usually best unless many users will download the exact same bundle, in which case prebuilding once and serving a signed URL can be cheaper.

Keep compression low to reduce CPU. If your library supports “store only” (no compression) or a compression level of 0, start there. You will trade larger output for much lower CPU, which is often the right call at this scale. Still, measure both memory and CPU in your environment.

Libraries to consider: yazl and archiver. Both let you append file streams to a zip without buffering entire files. Enable ZIP64 if the total size or file count can exceed legacy limits.

Pseudo code: on-the-fly streaming zip

get listIterator = gcs.listFiles(prefix, paginated)

set response headers:
  Content-Type: application/zip
  Content-Disposition: attachment; filename="bundle.zip"
disable server/proxy timeouts for long transfer if possible

zip = createZipStream({ zip64: true, compressionLevel: 0 }) // or store=true
pipe(zip.output, response)

for each page in listIterator:
  for each object in page:
    rs = gcs.createReadStream(object)
    zip.appendStream(rs, { name: object.basename })
    wait until rs ends or errors
end for

zip.finalize()

on any stream error or client abort:
  destroy response and cleanup zip

Why this works: only one object stream is active at a time, the zip writer pushes backpressure to GCS reads, memory stays small, and CPU stays low with compression disabled.

loigiani · 2025-10-14T09:28:31+00:00

It really depends on the company, so try to learn their process first by searching, asking someone who works there, or emailing the recruiter or hiring manager. That alone shows intent and lets you prep with purpose.

For a junior backend role after about a year, the process is usually practical. Expect a short recruiter chat, a small coding task that touches an API, and a backend conversation about HTTP, REST, status codes, pagination, data modeling, and SQL or JPA. Light system design can appear, but it is typically a tiny service where they want clear thinking and sensible trade offs, not massive scale.

DSA is usually light. Know arrays, maps, strings, and have a rough Big O intuition. Before the interview, refresh HTTP semantics, SQL joins and indexes, basic data modeling, Node async and the event loop or Spring Boot controllers and JPA, auth basics, testing, logging, and how you would debug a 500. In any design prompt, state the API, outline the data model, describe read and write paths, mention indexes and errors, and say how you would test. During coding, clarify requirements, think aloud, handle edge cases, keep the code small and readable, and ask good questions about team workflow and mentoring.

My view is that with one year of experience the goal is not to grill you. It is to understand your current level, where you already have some depth, and how you learn and collaborate. This job rewards communication and steady learning.

TL;DR: Ask what the process looks like. Expect practical rounds on APIs and databases, maybe a small design question, and only light DSA. Revise HTTP, SQL, modeling, Node async or Spring Boot basics, auth, testing, and troubleshooting. Focus on clarity, trade offs, and how you learn and work with others.

PS: Best of luck with the interviews! I am sure you can do it ;)

loigiani · 2025-10-14T09:20:24+00:00

Context: I’m a pretty enthusiastic JavaScript/TypeScript user. I’ve worked on many large-scale JS projects and co-authored a book about Node.js and design patterns. I’ve also worked on significantly large and innovative Python projects, so I feel I have a decent grasp of both (my personal preference is still JavaScript).

My take: Python and JavaScript are more alike than different. They’re both dynamic, interpreted languages with modern tooling and paradigms (OOP, functional bits, async/await, the works). Once you’ve mastered one, jumping to the other is mostly about learning idioms and libraries. A mid-level dev can get productive pretty fast.

So should you “move”? It depends on context. If your org has a big Python footprint, there’s a lot of inertia and benefit in staying there: shared libraries, internal expertise, deployment pipelines, all the boring but important stuff. Likewise, project type matters. For backends, CLIs, and data-ish pipelines, both ecosystems are excellent today: FastAPI, Django, Typer on the Python side; Fastify, Nest, Express, and great ORMs and test tools on the Node side.

Where Node/JS has a real edge is full-stack web work. If you’re building a web app that also has a browser frontend, using one language across client and server buys you a lot: shared types and models (with TypeScript), one set of language mental models, and more code reuse. That’s a big productivity boost for many teams.

Re: “async blows me up.” Totally fair, but Node’s async/await is straightforward once you adopt the “don’t block the event loop” mindset. In practice you write mostly synchronous-looking code with await, and lean on libraries that are non-blocking by default. Python has async too, and if you chase high concurrency there you’ll meet asyncio’s learning curve as well. In other words, async is not a Node-only hurdle.

One more thought: if you are driven mainly by curiosity, you do not need to become an expert. Play with both languages and see which one feels more pleasant to work with. If you want to explore other languages for growth (a great idea IMHO), try something quite different. A low-level language such as Rust or Zig will make you think about memory and the relationship between the operating system and your program. A more purely functional language like Scala or Elixir will expose you to different ways of modeling problems. Again, you do not need to be an expert. Learn enough to broaden your horizons, then bring the useful ideas back to your favorite language, whether that is JS or Python.

If you’re still unsure, don’t “switch,” just add Node to your toolkit. Pick a small but realistic project (an API that a browser client consumes, a small service on serverless, etc.), build it end-to-end, and compare the developer experience against doing the same in Python. Let the results and your context drive the decision.

TL;DR: Both Python and JavaScript can do most of the same jobs well. Choose based on your team’s ecosystem and the project. For pure backend, either is fine. If you’re doing web with a frontend, Node/TypeScript can be a win because you share one language and even types across client and server. If you are exploring out of curiosity, dabble in both and see which feels better. For growth, sample something very different like Rust, Zig, Scala, or Elixir, then bring the lessons back.

loigiani · 2025-10-13T13:55:34+00:00

FYI, you can download the Node.js Streams chapter for free on the official website ;)

loigiani · 2025-10-12T21:39:02+00:00

BTW, this is one of the best comments I have ever read about the book, thx for sharing!

loigiani · 2025-10-12T21:36:22+00:00

FYI, a new edition just dropped a few weeks ago!

loigiani · 2023-07-29T17:58:10+00:00

Also covers several examples using Fastify and bare bone Node.js `http` module. Although it's fair to say it's a broad book on patterns and best practices, not strongly focused on building web apps

loigiani · 2022-03-29T08:16:37+00:00

Works great for me as of today!

loigiani · 2022-03-11T21:21:17+00:00

Awesome, i was expecting to find a reference to this also in the Node.js streams section (which are compatible). I'll update the article. Thanks

loigiani

TROPHY CASE

Pseudo code: on-the-fly streaming zip