Node.js at Scale Today: Runtime Power, Production Discipline, and the New Backend Playbook

[0:00]Kyle: Welcome back to the Node.js stack podcast. This is episode two, and today we are staying with Node.js, but we are changing the angle. In the first episode, we talked about where Node.js is going today. Today, we are going deeper into what it means to actually run Node.js at scale.

[0:35]Kyle: Because Node.js has grown up. That part is not really controversial anymore. It powers APIs, dashboards, SaaS platforms, real-time products, developer tools, automation systems, serverless functions, payment workflows, queues, and internal business platforms. But here is the uncomfortable part: Node.js has matured faster than many Node.js teams have.

[1:20]Kyle: A mature runtime does not automatically create a mature backend. You can use the latest LTS version, modern TypeScript, native fetch, the built-in test runner, structured logging, tracing, and still build a messy system if your engineering habits are weak.

[2:00]Kyle: So today we are asking a practical question: what does a serious Node.js backend team look like today? Not the hype version. Not the conference slide version. The real version. The version that has incidents, deadlines, migrations, dependency updates, production traffic, security reviews, and developers joining the team who need to understand the codebase quickly.

[3:00]Kyle: To walk through that, I am joined by Priya Nandakumar, a staff backend engineer and Node.js platform lead at Cloudlane Systems. Priya has worked on Node.js services that handle real-time data, public APIs, background jobs, and internal platform tooling. Priya, welcome.

[3:28]Priya Nandakumar: Thanks for having me. And I like this framing because Node.js does not need another shallow discussion about whether JavaScript belongs on the server. That debate is tired. The useful conversation now is about operating discipline. How do you build Node systems that survive growth?

[4:05]Kyle: Exactly. And I think many people still underestimate how serious Node.js has become.

[4:15]Priya Nandakumar: They do. But there is also the opposite mistake. Some teams overestimate what Node.js gives them for free. Node gives you a strong runtime, a huge ecosystem, great developer speed, and a lot of modern APIs. But it does not give you architecture for free. It does not give you observability for free. It does not give you security for free. It does not give you clean boundaries for free.

[5:00]Kyle: So the message is not Node.js is weak. The message is Node.js is powerful enough that bad decisions scale quickly.

[5:12]Priya Nandakumar: That is the cleanest way to say it. Node helps teams move fast. But moving fast without standards means you also create technical debt fast. Today, good Node teams are not the ones installing the most packages or chasing every new feature. They are the ones building boring, reliable, observable systems.

[6:00]Kyle: Let us start with releases. It sounds boring, but it affects everything. Node has Current, LTS, and Maintenance. How should teams think about that?

[6:18]Priya Nandakumar: Think of it like this. Current is where new features arrive and where library authors start testing support. LTS is where most production teams should live. Maintenance is where you should still receive important fixes, but you should also be planning your move forward. The mistake is treating Node upgrades as optional housekeeping. Runtime upgrades are part of product reliability.

[7:05]Kyle: That is interesting because many companies upgrade frontend dependencies constantly but keep backend runtimes frozen for years.

[7:16]Priya Nandakumar: Yes, and they usually call that stability. But sometimes it is not stability. Sometimes it is fear. If your service is too fragile to upgrade the runtime, that is not proof that the old runtime is safe. It is proof that your tests, deployment process, dependency management, or architecture are not giving you confidence.

[8:00]Kyle: So what should a healthy Node upgrade process look like?

[8:08]Priya Nandakumar: Start early. Do not wait until end-of-life pressure. Read the release notes. Upgrade locally. Run the full test suite. Build the Docker image. Run integration tests. Check native dependencies. Check serverless runtime support if you use serverless. Compare memory usage, startup time, p95 latency, error rate, and logs in staging. Then roll out gradually.

[9:05]Kyle: That sounds obvious, but many teams do not actually have those measurements.

[9:12]Priya Nandakumar: Exactly. And that is the hidden problem. A runtime upgrade exposes whether your engineering system is healthy. If you cannot answer whether latency changed after an upgrade, your observability is weak. If you cannot run a reliable test suite, your quality process is weak. If one dependency blocks the whole upgrade, your dependency discipline is weak.

[10:30]Kyle: Let us talk about Node.js 24 LTS. For a production team today, what should they actually notice?

[10:45]Priya Nandakumar: Node.js 24 is important because it continues the shift toward a more capable native runtime. You get newer V8, newer npm, global URLPattern, stronger web API alignment, improvements around AsyncLocalStorage behavior, and better support for modern development patterns. But the real story is not one feature. The real story is that Node is becoming less dependent on external tools for everyday backend work.

[11:35]Kyle: Less dependent on external tools sounds like a big cultural change for Node.

[11:45]Priya Nandakumar: It is. Historically, Node culture was very package-first. Need HTTP requests? Install something. Need tests? Install something. Need environment handling? Install something. Need argument parsing? Install something. Need URL matching? Install something. That gave the ecosystem energy, but it also created huge dependency trees. Modern Node gives you more reasons to pause before installing.

[12:40]Kyle: But we should not turn that into package shaming, right?

[12:47]Priya Nandakumar: Correct. Packages are not bad. Good packages are one of Node's strengths. The problem is thoughtless installation. A well-maintained framework or library can save months. But a tiny utility package that brings a chain of dependencies for something Node already does may not be worth it.

[13:45]Kyle: So the question becomes: is this dependency creating leverage, or is it creating future work?

[13:54]Priya Nandakumar: Exactly. That should be part of code review. Not in an annoying bureaucratic way, but as a normal engineering question.

[15:00]Kyle: Now TypeScript. This topic gets people excited quickly. Node can now run TypeScript files with type stripping in certain cases. What does that mean in practical terms?

[15:18]Priya Nandakumar: It means Node can remove erasable TypeScript syntax and execute the remaining JavaScript. For many files, especially scripts and simple service code, that is very convenient. You can write TypeScript and run it with less ceremony. That reduces the need for some custom loaders or extra runtime tools.

[16:05]Kyle: That sounds like a huge win.

[16:10]Priya Nandakumar: It is a win, but it is not magic. Type stripping does not mean full TypeScript compilation. It does not mean type checking. It does not mean every TypeScript feature works the same way as a full build pipeline. If your code uses syntax that needs JavaScript generation, or if your project depends on path aliases, decorators, framework transforms, or bundler behavior, you still need to be careful.

[17:00]Kyle: So teams should not delete their build process on day one.

[17:07]Priya Nandakumar: No. The responsible move is to separate use cases. For scripts, small tools, migrations, test helpers, and clean modern modules, native TypeScript execution can be great. For large services, still run type checking in CI. Still understand your module system. Still know what your deployment artifact looks like.

[18:00]Kyle: I like that distinction: running TypeScript is not the same as proving TypeScript is correct.

[18:10]Priya Nandakumar: Exactly. TypeScript gives value through type checking, editor feedback, API contracts, refactoring confidence, and documentation through types. If you skip type checking, you are using TypeScript mostly as syntax. That is not enough for a serious backend.

[19:00]Kyle: What would you recommend for a new Node service today?

[19:07]Priya Nandakumar: Use TypeScript, but keep it simple. Prefer standard module behavior. Avoid unnecessary build tricks. Run type checking in CI. Decide whether you need a bundler or not. Many backend services do not need complex bundling. The simpler your TypeScript setup is, the easier runtime upgrades become.

[20:00]Kyle: Let us move to testing. Node's built-in test runner has become more serious. Why should teams care?

[20:15]Priya Nandakumar: Because it gives you a native testing option without immediately adding a large framework. For backend services, that is often enough. You can write unit tests, integration tests, service tests, CLI tests, and even use mocking support. The biggest benefit is not that it is trendy. The benefit is simplicity.

[21:00]Kyle: Developers sometimes say, why care about test framework weight? It is only dev dependencies.

[21:10]Priya Nandakumar: Dev dependencies still matter. They affect install time, lockfile size, CI reliability, security scans, onboarding, and maintenance. A test framework is part of your engineering platform. If the built-in runner covers your needs, that is fewer moving parts.

[22:00]Kyle: Would you migrate an existing Jest or Vitest suite just because Node has a test runner?

[22:08]Priya Nandakumar: No. Rewrites need a reason. If the current suite is stable, fast, understood, and gives good feedback, keep it. But for new backend services, I would start with node:test unless there is a clear reason not to. Start simple, then add complexity only when the project earns it.

[23:00]Kyle: What should good backend tests cover?

[23:08]Priya Nandakumar: Business rules, API contracts, validation, error behavior, database interactions, authentication boundaries, authorization rules, queue handlers, retries, timeouts, and failure paths. Many teams test the happy path and then wonder why production breaks on edge cases. Backend tests should prove how the system behaves when things go wrong.

[24:00]Kyle: So not just, does this return 200?

[24:05]Priya Nandakumar: Exactly. A serious API test asks: what happens when the user is missing permissions, the database is slow, the upstream service fails, the payload is too large, the token is expired, the retry succeeds, the retry fails, or the same request is sent twice?

[24:30]Kyle: Security. Node's Permission Model is stable now. How should teams think about it?

[24:45]Priya Nandakumar: They should think of it as part of least privilege. A Node process should not automatically have access to everything just because it is running. If a script only needs to read one folder, limit it to that. If a job does not need child processes, do not allow child processes. If a tool does not need environment access, restrict it.

[25:35]Kyle: Is this mainly for production servers?

[25:40]Priya Nandakumar: Not only. In fact, some of the best early use cases are scripts, internal tools, plugin systems, build tools, automation jobs, and CLIs. These are often overpowered. They run on developer machines or CI with access to files, tokens, and environment variables. That is a serious risk.

[26:35]Kyle: That is a good point. People usually think of security as public API endpoints.

[26:42]Priya Nandakumar: Right, but supply-chain attacks often care about developer machines and CI systems. If a malicious dependency or compromised script runs during install, build, or deployment, the damage can happen before production even sees the code.

[27:40]Kyle: So permissions are not a silver bullet, but they reduce blast radius.

[27:48]Priya Nandakumar: Exactly. They do not replace containers, cloud IAM, secrets management, dependency review, or code review. But they add another boundary. Mature systems use layers.

[29:00]Kyle: Let us talk about web-standard APIs. Node now feels more aligned with the browser than it used to. Why does that matter?

[29:15]Priya Nandakumar: It matters because full-stack JavaScript teams benefit from shared concepts. fetch, web streams, URL, URLPattern, WebSocket, AbortController, and other standards reduce the number of custom abstractions developers need to learn. That does not make server code the same as browser code, but it gives both sides more shared vocabulary.

[30:05]Kyle: Give me a simple example.

[30:10]Priya Nandakumar: HTTP requests. Years ago, many projects used different libraries for every environment. Now native fetch handles many everyday server-side HTTP calls. That does not mean fetch gives you everything. You may still need retries, circuit breakers, tracing, auth helpers, generated clients, or custom timeouts. But you can build those deliberately instead of installing a full client by reflex.

[31:05]Kyle: What about URLPattern?

[31:10]Priya Nandakumar: URLPattern is useful because matching URLs is a common problem. Routing, middleware, proxies, edge logic, API gateways, and internal tools all need URL matching. Having a standard primitive available globally helps teams write clearer code and avoid fragile regular expressions in places where URL patterns are the real intent.

[32:05]Kyle: So again, the theme is native primitives reduce unnecessary dependencies.

[32:12]Priya Nandakumar: Yes. But primitives are not full architecture. A primitive gives you a building block. A good system still needs boundaries, conventions, error handling, observability, tests, and product thinking.

[33:30]Kyle: Performance. This is where Node has both strong fans and strong critics. What is the realistic view today?

[33:45]Priya Nandakumar: The realistic view is that Node is excellent for I/O-heavy backend work. APIs, real-time events, service orchestration, serverless handlers, queues, and developer tools are natural fits. But Node is not a magic answer for CPU-heavy workloads. You need to understand the event loop.

[34:30]Kyle: People hear event loop all the time. What does it mean practically?

[34:38]Priya Nandakumar: It means one slow CPU-heavy task can hurt other work in the same process. If you parse a huge JSON payload, generate a PDF, compress a large file, resize images, run expensive encryption, or do heavy data transformation on the main thread, other requests can wait. That is how Node apps suddenly feel slow even when the server is not obviously overloaded.

[35:35]Kyle: So what should teams measure?

[35:40]Priya Nandakumar: Measure p95 and p99 latency, event loop delay, memory usage, garbage collection pressure, database query time, queue depth, external API latency, error rate, and cold starts if serverless is involved. Average latency is not enough. Users feel the tail.

[36:40]Kyle: That line matters: users feel the tail.

[36:45]Priya Nandakumar: Yes. Averages hide pain. A service can look fine on average while a meaningful number of users are having a terrible experience. Serious backend teams look at distributions.

[37:30]Kyle: How do you fix CPU-heavy work in Node?

[37:38]Priya Nandakumar: You have options. Worker threads, job queues, separate services, native modules, streaming instead of buffering, better database-side processing, batching, caching, and sometimes choosing another runtime for that workload. The mature answer is not always make Node do everything. The mature answer is put the work where it belongs.

[38:35]Kyle: That is probably hard for teams that want one stack everywhere.

[38:42]Priya Nandakumar: It can be. But one stack should not become one hammer. Node can be your main backend platform while still delegating specialized jobs to better tools.

[39:00]Kyle: Observability. You mentioned earlier that runtime upgrades expose whether teams can measure things. What should observability look like for Node?

[39:15]Priya Nandakumar: At minimum, structured logs, metrics, traces, health checks, and useful alerts. Not just logs that say something failed. Logs that include request ID, route, operation name, user or tenant context where safe, latency, status, and error type. Metrics that show rate, errors, duration, saturation, queue depth, memory, and event loop delay. Traces that show where time went across services.

[40:10]Kyle: Where does AsyncLocalStorage fit into that?

[40:18]Priya Nandakumar: AsyncLocalStorage helps carry context through asynchronous code. In a Node service, one request may call authentication, validation, business logic, database queries, cache operations, external APIs, and logging. You want the same correlation ID or trace context to follow that flow. Otherwise your logs become disconnected fragments.

[41:10]Kyle: And disconnected fragments are painful during incidents.

[41:15]Priya Nandakumar: They are brutal. During an incident, you do not want to guess. You want to ask: which requests failed, which tenants were affected, what changed, which dependency slowed down, did retries help, did the queue grow, did memory spike, did the event loop stall? Observability should answer those questions quickly.

[42:15]Kyle: What is a common logging mistake?

[42:20]Priya Nandakumar: Logging too much unsafe data. Developers often add logs during debugging and accidentally log tokens, secrets, full request bodies, passwords, personal information, or payment data. Good logging is intentional. It is structured, limited, searchable, and safe.

[43:15]Kyle: So observability is not just more data.

[43:20]Priya Nandakumar: Exactly. More data can make things worse. Good observability is about useful signals. It should reduce confusion, not create a bigger haystack.

[44:00]Kyle: Let us talk about npm and dependency risk. Node's ecosystem is huge. That is an advantage and a risk.

[44:15]Priya Nandakumar: Yes. npm is one of the reasons Node became so successful. But a huge ecosystem means you need discipline. Every dependency is a trust decision. Every transitive dependency is also a trust decision, even if your team did not consciously make it.

[45:00]Kyle: What should a dependency review include?

[45:08]Priya Nandakumar: Ask whether Node already provides the capability. Check whether the package is maintained. Look at install scripts. Look at transitive dependency count. Look at license. Look at security history. Look at how central it will be to your architecture. A small helper used in one file is different from a framework that defines the whole app.

[46:00]Kyle: Should teams try to have zero dependencies?

[46:05]Priya Nandakumar: No. That is unrealistic and usually counterproductive. The goal is not zero dependencies. The goal is justified dependencies. Use high-quality libraries where they provide real leverage. Avoid casual dependencies where the platform or a small local function is enough.

[47:00]Kyle: What about security scanners?

[47:05]Priya Nandakumar: Use them, but do not outsource judgment to them. Scanners are helpful, but teams need to understand exploitability. A vulnerable package buried in a dev-only path may not be the same risk as a vulnerable package handling user input in production. The answer is not panic. The answer is triage.

[48:00]Kyle: AI-assisted development. Every team is dealing with this now. How does it change Node.js work?

[48:15]Priya Nandakumar: AI is useful in Node.js because there is a lot of repetitive work: route handlers, schema validation, tests, migrations, documentation, client examples, refactors, CommonJS to ESM conversion, and debugging unfamiliar errors. Used well, AI speeds up work the developer already understands.

[49:00]Kyle: Used badly?

[49:05]Priya Nandakumar: Used badly, it creates confident nonsense. It may invent APIs, add unnecessary packages, ignore security, write blocking code, mishandle async errors, create weak tests, or produce architecture that looks clean in a small example but fails in a real system.

[50:00]Kyle: What should reviewers ask when code is AI-assisted?

[50:08]Priya Nandakumar: Ask whether the developer can explain it. Ask whether it handles errors. Ask whether it leaks data. Ask whether it validates input. Ask whether it blocks the event loop. Ask whether it respects existing patterns. Ask whether the tests are meaningful or just generated theater. AI code should not get a softer review.

[51:00]Kyle: Generated theater is a good phrase.

[51:05]Priya Nandakumar: It happens a lot. Tests that assert the mock returns what the mock was told to return. Documentation that sounds polished but says nothing. Error handling that catches everything and hides the real failure. AI can create volume. Engineers still need to create quality.

[51:30]Kyle: Let us close with a practical playbook. A team is running Node.js in production today. What should they do this quarter?

[51:45]Priya Nandakumar: First, check your runtime versions. If services are on old or unsupported lines, create an upgrade plan. Second, standardize on an active LTS line unless there is a strong reason not to. Third, audit dependencies. Remove packages that Node now covers natively or that no longer justify their risk.

[52:30]Priya Nandakumar: Fourth, improve tests. Make sure critical business rules, auth boundaries, API contracts, and failure paths are covered. Fifth, improve observability. Add request IDs, structured logs, useful metrics, event loop delay tracking, and tracing where it matters.

[53:10]Priya Nandakumar: Sixth, review security boundaries. Look at secrets, permissions, CI scripts, install scripts, cloud roles, public endpoints, and admin routes. Seventh, define AI code review rules. AI can help, but ownership stays with the team.

[53:50]Kyle: And what should teams stop doing?

[53:55]Priya Nandakumar: Stop installing packages without thinking. Stop treating runtime upgrades as emergencies. Stop logging sensitive data. Stop writing tests only for happy paths. Stop assuming TypeScript removes the need for runtime validation. Stop using Node as an excuse to avoid architecture.

[54:30]Kyle: Final sentence: what is Node.js today?

[54:35]Priya Nandakumar: Node.js today is a mature backend platform. It gives teams speed, reach, and strong native capabilities. But the teams that win with Node will be the teams that pair that speed with discipline.

[54:50]Kyle: Priya Nandakumar, thanks for joining us.

[54:53]Priya Nandakumar: Thanks for having me.

[54:56]Kyle: For listeners, the takeaway is simple: Node.js can help you move fast, but production rewards teams that move carefully. Use the modern runtime, but build the habits that make it safe.

[55:00]Kyle: End.