r/node

I developed an LSP, VS-Code extension and NPM package, please try it out and give me your thoughts!

I wanted a library like vis.js but needed it canvas-based for server-side rendering without a headless browser in node, so I built one. I'd love to get some feedback.

hey everyone, i’ve been wondering where people draw the line in Node/Express apps.

at what point do you stop doing background work after response and move everything into a proper job queue?

is a small delay (1–2s async work) still fine in production, or do you avoid it completely from the start?

curious how others handle this in real apps

If there was a magic wand that can take us all back to pre AI era

>which means software development jobs were still considered high skilled needing time/skills/seniority and companies used to hire x devs instead of much lower devs now (because 1 dev + AI = more productive so less need to hire more)

Would you take it? or you would prefer to still have LLMs taking over the way they have already to a point that companies are hiring less, junior roles are evaporating at a rapid rates and seniors (these roles have also reducing in head count) are addicted to AI tools to a point that without them many are struggling to work and who know how the tech scene would look like in next 2 years let alone 5 years.

Why or why not?

Hi, really more of an API design question than an azure-specific one.

I'm building a mixed B2B/B2C file API. Customers/partners upload/download up to 500MB files. Storage account is locked down (currently) with no public access (publicNetworkAccess: Disabled) but I'm considering changing this.

Downloads: Two options:

1. GET /files/:id/content streams bytes through the API (App Service, private endpoint to blob).

2. MS Graph style: 302 w/ presigned URL, client downloads straight from blob. No streaming through app but storage needs public access.

Uploads:

Currently doing chunked upload sessions modeled on MS Graph createUploadSession. Client POSTs to create a session, gets back an upload URL with a 24h HMAC token, PUTs chunks. Server calls stageBlock. Token is the only auth on the PUT.

Chose this because:

• 230s App Service request cap rules out single PUT
• Chunked PUT direct to blob w/ SAS (like downloads option 2) means public storage
  • I'm still wondering if straight-to-SAS-URL is the right move instead of my chunked sessions
  • It makes it a little weird to use because you also have to tell the client what headers they need to include
  • User can upload ANY size to that endpoint (and we can only check when they commit)
  • User can their own storage tier etc. with the headers it seems?

Has anyone done this tradeoff? I see a lot of "just hand out the blob storage SAS URLs" for both but there seems to be some significant downsides for using them for either download or upload. Just looking for advice or examples.

edit: Thanks for all the feedback. Since security and control is much more important to me than a bit more load on my server, I think I'm going to settle on this set up:

• publicNetworkAccess: Disabled / vnet-only access to the blob storage
• app-level Bearer/cookie auth on all file endpoints (no presigned urls anywhere)
• upload is ms graph-style with PUT /files/upload-sessions + PUT /files/upload-sessions/:id (loop) with auto-commit on the last byte uploaded
• download is direct from a /files/:id/content with a Range: header supported to allow downloading huge files/resumable downloads despite the 230s request timeout.

Ive been too casual about npm install scripts. `postinstall` runs when im barely watching the job, and if CI already has npm tokens or GitHub creds sitting in env, that code gets a shot before the app even starts

Mini Shai-Hulud and the GitHub Actions cache poisoning threads finally got me to set `ignore-scripts` by default, then allow scripts only when I can name the package and why it needs one. Annoying. Less annoying than learning the install step read a token at 2am, tho

Hello everyone,

I downloaded 'FNM' on my window pc to allow Node version control. I followed the guide to installed the FNM, set up the $PROFILE file, and successfully installed a Node version.

Now, when i check for node version using Powershell, it shows the correct version. However, when I do it in a VScode, it says 'Node' doesn't exist.

Will i have to create a separate $PROFILE from within the VScode? Not sure if this is the standard approach or i would need to find a way to use the same $PROFILE i use. I did already check using this 'where.exe fnm' command from both (plain Powershell vs Powershell in VScode) but they pointed the same location.

How strictly should I avoid a Node/Express handler returning a value to the client, but have some process continue in the background to finish processing it?

If the background is expected to take another 1~2 seconds is it acceptable?

Or should I avoid them and relegate all background tasks, big or small, to a dedicated job queue at the cost of complexity.

Hello! you guys were very helpful in the getting me up to speeed with Express/node post, thank you so much! Another portion of this is now coding review.

I learned alot about architecture, naming endpoints, error statuses, global error handling, chaining middleware, validation of inputs (using zod, etc), user session validation, proper REST patterns, standard http headers and response codes, unit vs integration testing and when to use what, monitoring in production, scaling the service (ie add cache on GET requests, or run multiple behind a load balancer), different ways to server HTML

My other followup is!! are there any other 'gotchas'/concepts I need to prep for a coding review? such as I think they can pull of a SQL query that is prone to injection and not use paramterized queries:

app.get('/user', (req, res) => {
  const username = req.query.username;

  // 🚨 DANGEROUS: User input is directly interpolated into the SQL string
  const query = `SELECT * FROM users WHERE username = '${username}'`;

  db.query(query, (err, results) => {
    res.json(results);
  });
});

A week ago I posted about ArchUnitTS, my library for enforcing architecture rules in TypeScript projects as unit tests.

A few of you specifically asked whether this could be used to enforce clean Angular feature/module boundaries in real projects: making sure feature modules don’t import directly from each other’s internal files, and instead communicate through public API barrel files like index.ts or public-api.ts.

So to that request I’ve added exactly that.

---

First a mini recap of what ArchUnitTS does:

• Most tools catch style issues, formatting issues, or generic smells.
• ArchUnitTS focuses on structural rules: wrong dependency directions, circular dependencies, naming convention drift, architecture/diagram mismatch, code metrics, and so on.
• You define those rules as tests, run them in Jest/Vitest/Jasmine/Mocha/etc., and they automatically become part of CI/CD.

In other words: ArchUnitTS allows you to enforce your architectural decisions by writing them as simple unit tests.

That matters more than ever in Claude Code / Codex times, because LLMs are great at generating code but they love to violate architectural boundaries, especially when they get stuck.

Repo: https://github.com/LukasNiessen/ArchUnitTS

---

Now what’s new

Exclusion-aware dependency rules for Angular public API boundaries

Before, ArchUnitTS could already enforce internal dependency rules like:

• “components must not depend on infrastructure”
• “core must not depend on shared”
• “feature A must not depend on feature B”
• “folders must be cycle-free”

But one common Angular case was still a bit annoying to express cleanly:

A component in one feature should not import directly from another feature’s internal files.

For example, this should usually be forbidden:

import { OrderService } from '../orders/internal/order.service';
import { OrderCardComponent } from '../orders/components/order-card.component';

But this should be allowed:

import { OrderSummary } from '../orders';
import { PUBLIC_ORDERS_TOKEN } from '../orders/public-api';

This is not technically always a circular dependency.
But it is still architectural coupling.

It means another feature now knows the internal folder structure of orders. If the orders feature reorganizes its components, services, hooks, facades, or models, unrelated features can suddenly break.

So ArchUnitTS now supports except in pattern matchers.

Example:

import { projectFiles } from 'archunit';

it('should consume orders only through its public API', async () => {
  const rule = projectFiles()
    .inPath('src/app/**/*.ts', {
      except: { inPath: 'src/app/orders/**' },
    })
    .shouldNot()
    .dependOnFiles()
    .inFolder('src/app/orders/**', {
      except: ['index.ts', 'public-api.ts'],
    });

  await expect(rule).toPassAsync();
});

This says:

• check all Angular app files
• exclude files inside orders itself, because a module may use its own internals
• forbid other features from depending on files inside orders
• but allow imports through orders/index.ts and orders/public-api.ts

So this fails:

import { OrderService } from '../orders/internal/order.service';

But this passes:

import { OrderSummary } from '../orders';

You can also make the exceptions explicit by target:

.inFolder('src/app/orders/**', {
  except: {
    withName: ['index.ts', 'public-api.ts'],
  },
});

This is especially useful in Angular projects because Angular feature modules often create natural architectural boundaries, but violations tend to accumulate silently over time.

And these imports are very hard to catch in code review because they look like normal TypeScript imports.

Now the boundary can be tested directly.

---

Very curious for any type of feedback! PRs are also highly welcome.

Need to build an express.jss API for an interview, havent touched express.js in a while 😄. Im a frontend leaning dev as well so something that spoon feeds me information are appericiated. Hoping it covers stuff like middleware, etc