A middleware needs an app setting. It imports your exported app, and now the source dependencies look like this:

app.ts -> routes/orders.ts
  -> middleware/tenant-context.ts -> app.ts

All the files in middleware/ can look fine when checked in isolation. The cycle leaves that folder and comes back through the router.

This is a useful detail when writing a cycle test with my library, ArchUnitTS:

import { projectFiles } from 'archunit';

const violations = await projectFiles('tsconfig.json')
  .inFolder('src/**')
  .should()
  .haveNoCycles()
  .check();

expect(violations).toEqual([]);

Use a scope that contains the whole chain. With that example, src/middleware/** alone passes because this check looks for cycles within the selected files. src/** reports the three-file cycle.

For middleware that needs the current Express app, req.app is already available. Using req.app.get('tenantConfig') inside the middleware lets you remove the singleton import. Passing the particular dependency into a middleware factory is another option. The app can still import the router and register the middleware; that forward wiring is fine.

One fewer reason for middleware to know about bootstrap code

The check follows static imports, not the order Express runs middleware. This API is available in archunit 2.5.5 on npm, free and open source.

Hey everyone!

I'd like to share an open-source project I've been working on: express-mongo-honeypot.

It's a TypeScript middleware for Express that uses honeypot traps to detect suspicious requests, automatically identify scanners and bots, and block their IP addresses using MongoDB.

What does it do?

• Honeypot traps: Configurable endpoints that legitimate users should never access.

• Automatic IP blocking: IPs that trigger a trap are automatically added to a MongoDB blocklist.

• Persistent blocklist: Blocked IPs remain stored in MongoDB.

• Predefined trap collections: Ready-to-use configurations for WordPress, PHP, Node.js, and more.

• Customizable: Bring your own logger, IP detection logic, and blocklist storage.

• TypeScript support: Fully typed API.

• Express 4 and 5 support.

Installation:

npm install express-mongo-honeypot mongodb

Quick example:

import express from "express";
import {
  createHoneypot,
  createMongoBlocklist
} from "express-mongo-honeypot";

const app = express();

const blocklist = createMongoBlocklist({
  url: "mongodb://localhost:27017",
  database: "myapp"
});

const honeypot = createHoneypot({
  blocklist
});

app.use(honeypot);

app.listen(3000);

The idea behind this project is to provide an additional security layer for Express applications without requiring a complicated setup.

I'd appreciate feedback, suggestions, and contributions

Thanks for checking it out!

When an Express route starts doing too much, looking at the route file only gets you so far. Some of the interesting coupling is another import or two away, inside the service it calls.

I maintain ArchUnitTS, and its dependency reports can start from one route module and follow the imports the analysis resolves.

import { projectGraph } from 'archunit';

const report = projectGraph()
  .reachableFrom('src/routes/checkout.ts');
await report.exportAsHTML('reports/checkout-dependencies.html');

Run this in an async function from the project root. In a route → service → store fixture, the report included the store even though the route did not import it directly. An unrelated module stayed out.

That gives you a smaller starting point for splitting a route handler or moving persistence behind an interface. You can inspect that dependency view before deciding which architecture rule to enforce.

It's a static import graph. It won't tell you which middleware ran for a particular request or reconstruct dependencies the extraction cannot resolve.

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

Hey everyone,

I’m planning to build a multi-platform gaming project that includes:

1. E-commerce store for gaming products, accessories, and merchandise

2. Real-time community with posts, likes, comments, shares, images and videos

3. Dedicated video section with playlists, individual video pages, and a main video feed

4. Multi-language, multi-currency, and multi-payment support

5. Everything working in real-time

My current preferred stack:

- Frontend: Next.js 15 + React + TypeScript + Tailwind + GSAP + Three.js

- Backend: Node.js + Express + Socket.io

- Database: MongoDB Atlas

- Cache / Real-time: Redis

- Media storage: Cloudflare R2 + CDN

Questions:

1. Which database is better for a multi-platform gaming project like this — MongoDB, PostgreSQL, Cassandra, or something else?

2. Is MongoDB a good primary choice for this mix of e-commerce + community + video features?

3. Would you recommend adding PostgreSQL for orders and payments?

4. Any better alternatives for real-time features or video handling?

5. Overall architecture suggestions?

Would love honest feedback from people who have built similar multi-platform projects. Thanks!

Hey r/npm! I just published v9.0.1 of LimitForge (npm), a zero-runtime-dependency rate limiting and resilience middleware for Express (Node >= 18, ESM + TypeScript definitions).

I wanted a single middleware that handles distributed Redis enforcement cleanly without bringing down the Express app if Redis slows down or drops, and without pulling heavy external dependencies like prom-client.

Key Engineering Choices

• 3 Algorithms with Memory & Redis Parity: Fixed Window, Rolling Sliding Window (Redis ZSET), and continuous-refill Token Bucket (supporting dynamic tier policies and weighted request cost).

• Clock-Drift Protection in Redis Lua: Sliding-window and token-bucket Lua scripts use Redis server TIME by default instead of Node client timestamps, and fixed-window uses a versioned SET ... PX state marker (lf1|count|start|legacyUntil) rather than separate INCR + EXPIRE calls.

• Resilience & Failover (ResilientStore): Wraps RedisStore with a timeoutMs guard and a CircuitBreaker (CLOSED -> OPEN -> single-flight HALF_OPEN canary probe) that fails over to an in-memory fallback (RateLimit-Degraded: true), or lets you set onStoreError: 'fail-closed' where strict global quotas are required.

• Bounded-Cardinality Observability: Native /metrics Prometheus text exporter (v0.0.4) that normalizes dynamic route IDs (/users/42 -> /users/:id) and caps series (maxSeries -> _overflow) to protect Prometheus TSDB, plus duck-typed OpenTelemetryBridge span enrichment (ratelimit.* + limitforge.*).

• Key Collision & Privacy Hardening: Escapes delimiter characters across key segments and supports optional SHA-256 hashing (hashClientIdentifier: true) for API keys/tokens.

Quick Example

import express from 'express';
import { createClient } from 'redis';
import { rateLimiter, RedisStore, MemoryStore, ResilientStore, createPrometheusExporter } from 'limitforge';

const app = express();
const redisClient = createClient({ url: process.env.REDIS_URL, disableOfflineQueue: true });
redisClient.connect().catch(() => {});

const store = new ResilientStore({
  primaryStore: new RedisStore({ client: redisClient }),
  fallbackStore: new MemoryStore(),
  timeoutMs: 150
});

app.use('/api', rateLimiter({
  store,
  algorithm: 'sliding-window',
  limit: 100,
  windowMs: 60_000,
  metrics: true
}));

app.get('/metrics', createPrometheusExporter());

Benchmarks & Testing

• Measured with process.hrtime.bigint() (10k iterations after 1k warmup on Node 24): in-memory evaluation adds +2.4 µs to +2.5 µs p50 overhead over a no-op middleware (~222k–262k ops/sec across algorithms; +6.3 µs with metrics enabled).

• 341 unit/integration tests (node --test) + GitHub Actions CI across Node 18, 20, and 22 against redis:7-alpine.

Looking for Feedback

1. For people running distributed rate limiters in production: how do you prefer handling Redis timeouts/outages — local per-instance fallback (AP) or 503 fail-closed (CP)?

2. Any edge cases in Express 4/5 route scoping or TypeScript declarations I should tighten next?

• GitHub: https://github.com/Anivesh91/LimitForge

• npm: npm install limitforge express (optional redis peer dep)

Arkos.js v1.7.5-rc is out

Another release candidate focused on fixes, this time for the WebSocket Gateway and for how config errors are reported.Highlights:

• Gateway connection middleware fix: gateway.use() callbacks are now registered on the namespace with ns.use() and run before authentication. Before, a (socket, next) middleware received the event payload instead of next and never ran on connection.

• Middlewares now drill down into nested gateways, in ancestor-to-descendant order (parent → child → auth).

• Fatal config errors: the process now exits with the error message instead of dumping a stack trace. This covers route config validation, input validators, OpenAPI, the auth and file-upload routers, and the generate command.• New ArkosGatewayMiddleware type, exported from arkos/websockets.

• Docs now explain how connection middleware differs from event-level .pipe() middleware.

No breaking changes are expected, but this is a release candidate, so please test it before taking it to production.

npm install [email protected]

Full release: https://github.com/Uanela/arkos/releases/tag/v1.7.5-rc

#OpenSource #NodeJS #TypeScript #Express #Prisma #WebSockets

Dunno if I'm breaking any rules or not, but I wanted to ask about how the session knows what data belongs to the user.

Would you assign to the session the data id reference from the database in the session?

Would you assign the session id to the data storage?

I wanted to get some extra input, because I've been going in circles for a couple of days thinking about it already.

Hey everyone,

When a client drops a connection (or a frontend Promise.race aborts), your server usually keeps running expensive DB queries and fetch requests for nothing.

I built flex-fetch-express to fix this. It uses Node's AsyncLocalStorage to catch client disconnects and automatically aborts any ongoing network requests deep in your stack. No need to manually pass { signal } down through 10 layers of functions.

• GitHub: https://github.com/yarin-mag/flex-fetch-express

• npm: npm i flex-fetch-express

Let me know what you think!

Arkos.js v1.7.4-rc is out (a framework for building REST APIs with Express and Prisma)

If you haven't heard of it: Arkos.js is a RESTful framework built on top of Express and Prisma. It comes with a CLI that generates routers for you, authentication routes, and OpenAPI docs served through Scalar, so you can get a Node.js API running without wiring everything by hand.

This release candidate is mostly small fixes:

1. Auth routers generated by the CLI now use the "Authentication" tag instead of the old pluralized "Auths" name.

2. Because of that, auth routes no longer appear under a separate heading in the generated OpenAPI/Scalar docs.

3. The default Scalar config now targets Scalar's current root class, .scalar-app-client.

4. With that fix, the fullscreen CSS overrides in the API reference work again.

5. The router template no longer adds a stray trailing newline after the generated hook config object.

6. Test mocks were updated for the lazy env-loading path.

7. To try it, run: npm install [email protected]

8. No breaking API changes are expected.

9. It's a release candidate, so if you run into any issues, please report them before it's promoted to stable.

10. Full release notes: https://github.com/Uanela/arkos/releases/tag/v1.7.4-rc

If you build APIs with Express and Prisma, give it a try and let me know what you think. Feedback is very welcome!

For a small Express app on a single VPS, I wanted answers to a few basic questions: is traffic changing, are 4xx/5xx responses rising, is latency creeping up, and how much CPU and heap is the process using?

Prometheus + Grafana can obviously handle this, but for this app I wanted something much smaller.

So I wrote a small helper that counts things where Express already sees every response and exposes them as JSON. It uses only Express and Node built-ins, with no SDK and no prom-client.

The core of it:

const { performance } = require("node:perf_hooks");

const METRICS_PATH = "/statlite/metrics";

const counters = {
  requestsTotal: 0,
  responses4xxTotal: 0,
  responses5xxTotal: 0,
  requestDurationSecondsTotal: 0,
};

function statliteMetricsMiddleware(req, res, next) {
  if (req.path === METRICS_PATH) return next(); // don't count the polls themselves

  const start = performance.now();

  res.once("finish", () => {
    counters.requestsTotal += 1;
    counters.requestDurationSecondsTotal +=
      (performance.now() - start) / 1000;

    if (res.statusCode >= 400 && res.statusCode < 500) {
      counters.responses4xxTotal += 1;
    }

    if (res.statusCode >= 500) {
      counters.responses5xxTotal += 1;
    }
  });

  next();
}

Register it before your routes, then add a GET /statlite/metrics route that returns the counters plus process.cpuUsage(), process.memoryUsage().heapUsed, and process.uptime().

Because the finish listener fires after later middleware runs, it sees the final status, including a 500 set by an error handler.

A few design notes:

• Counters are cumulative, so the poller derives rates and average latency from deltas. The app keeps only running totals.

• Heap is V8 heap used, not RSS or container memory.

• CPU is CPU-seconds divided by wall-seconds since the previous snapshot, so it is expressed in cores.

• Snapshot collection does no I/O.

Limitations:

• It's single-process, with counters in memory. Cluster mode, PM2 clusters, and replicas each need their own target or aggregation.

• It reports mean latency only, with no percentiles.

• The endpoint is unauthenticated and meant to sit on a private network.

• Connections aborted before a response finishes aren't counted.

For charting and history, I point a small tool I built, StatLite, a single binary with SQLite storage, at the endpoint. Disclosure: I'm the author of StatLite.

Full writeup with the complete helper, config, and a runnable demo:

https://pvrlabs.xyz/articles/lightweight-express-monitoring.html

Curious what people here use for small Express deployments. Do you still reach for prom-client + Prometheus/Grafana, use a hosted service, or keep something simpler?

Hello everyone,

I wanted to share a full-stack open-source project I built entirely in TypeScript using NestJS on the backend and Next.js on the frontend, which integrates Vector Databases for automated customer interactions.

The project is fully open-source and available on GitHub:

GitHub: https://github.com/mostafa18181/roboinsta

🛠️ Tech Stack & Architecture:

\- Backend: NestJS (TypeScript) with a modular architecture, designed for high-concurrency event handling and webhooks.

\- Frontend: Next.js (TypeScript) for the dashboard and account management.

\- Data & AI Layer: Vector Database integration for semantic search, context retrieval, and dynamic product Q&A scenarios.

⚙️ What the System Does:

1. Multi-Tenant Instagram Integration: Allows multiple users to connect their Instagram accounts.

2. AI-Powered Product Promotion:Context-aware responses to user queries and posts based on custom vector embeddings.

3. Automated Inventory Management:Tracks real-time product stock and automatically decrements inventory upon completed sales triggers.

4. Custom Q&A Scenarios: Configurable decision trees and vector-based knowledge retrieval for domain-specific automation.

💡 Why I'm Open-Sourcing It:

This was initially developed as an MVP for a startup initiative. Due to team/partner changes, the commercial launch was halted and the live deployment was taken offline. However, the underlying TypeScript codebase and architectural patterns are solid, so I decided to open-source it for the community.

Feel free to check out the repo, explore the NestJS/Next.js implementation, fork it, or use the architecture for your own projects. Feedback on the code structure, typing patterns, and backend design is highly appreciated!

Built this a few years ago to spin up new express projects. Due to compatibility issues with some libraries (i.e. KnexJS), I was setting the type to commonJS for the longest time. Finally the new express template project that's spin up is now type: "module"

https://github.com/seanpmaxwell/express-generator-typescript

I’m learning Node.js and Express.js, and I understand the basic idea of middleware, especially using it for authentication.

For example:

app.use(authMiddleware);

But I’m still struggling to understand when and why middleware is actually useful in real-world applications beyond authentication.

I know middleware can access req, res, and next(), but I’d like to understand how experienced developers use it in production projects.

What are some practical use cases for middleware besides:

• Authentication

• Authorization

For example, do you commonly use middleware for:

• Logging requests?

• Error handling?

• Request validation?

• Rate limiting?

• Adding data to req?

• Processing files?

• Checking permissions?

• Something else?

If possible, could someone explain with a real-world example rather than just the basic definition?

I think seeing how middleware fits into an actual application architecture would help me understand it much better.

When SIGTERM arrives, should an Express service stop accepting requests, finish current requests, drain a small outbound queue, and then exit? How do you decide what gets a timeout or gets dropped? I’m interested in small services rather than Kubernetes-specific solutions.

If one failing dependency causes the same error on many requests, sending every stack trace to Telegram or a webhook becomes noise.

Would you put fingerprinting and cooldown logic inside Express error middleware, in a separate notifier service, or behind a queue?

Which request context is essential in the alert: route, status, request ID, deployment version, or something else?

I’m building an open-source package with an Express adapter and would appreciate feedback from people running real Express APIs.

How do you keep your Express API docs in sync with your code?

I've been working on something for the last 6 months because I kept running into an annoying problem:

Your Express backend is constantly changing, but your API documentation doesn't always change with it.

A route gets added, a parameter changes, validation gets updated, a controller gets refactored... and eventually the Swagger/OpenAPI docs don't completely represent what the backend actually does.

So I built RouteLens.

The idea is pretty simple:

Instead of manually describing your API, RouteLens analyzes your existing Node/Express codebase and tries to discover the API that's actually implemented.

It looks at things like:

• routes and HTTP methods

• route parameters

• controllers

• request/response information

• validation schemas (Zod/Joi/etc.)

• how those pieces are connected

I'm now trying to answer a very simple question:

Does this actually work on Express projects I didn't write?

I'm looking for a few developers who have a real Node/Express project and are willing to run RouteLens against it for ~10–15 minutes.

I'm especially interested in projects with multiple routers/controllers and some kind of request validation.

I don't need compliments or “looks cool” feedback.

If it completely misses your routes, misunderstands your architecture, or gives you something useless, that's exactly what I want to find out.

If you're interested in trying it, comment "Interested" or DM me and I'll send you access.

I'd genuinely love to see what it gets right — and where it falls apart.

Quick one following up on the 1.7.0 WebSocket Gateway release. This RC cleans up a few rough edges:

- Prisma client now generates into .arkos/ at the project root (was u/arkosjs/generated) — also works if you point it at a custom directory. Auto-added to .gitignore and tsconfig.json for you.

- Gateway: namespace-level broadcast — gateway.nsp is now exposed directly.

- Gateway: user() targeting on the namespace — reach a user across the whole namespace, not just inside a room.

- Fix: file upload router wasn't respecting the global prefix — fixed.

- Fix: email service was passing the wrong from address (auth.user) when calling send().

- Fix: bogus warning about dtos/schemas not being attached to route hooks.

- Arkos now throws right away if it can't find arkos.config.ts, instead of silently misbehaving later.

Full changelog and diffs on the GitHub release page: https://github.com/uanela/arkos/releases/tag/v1.7.1-rc

Upgrade with pnpm install arkos@latest. Feedback and issues welcome as always.

Hey everyone,

I just shipped v1.7.0-rc of Arkos.js, my open-source Node.js/TypeScript framework built on Express and Prisma that auto-generates CRUD, auth, RBAC, docs, and more. This is the biggest release yet - the headline feature is a full WebSocket layer.

WebSocket Gateways (ArkosGateway)

Built on Socket.IO, but following the same conventions as the rest of Arkos:

- Reuses whatever auth you've already configured (static/dynamic) - no separate WebSocket auth setup

- Plugs into ArkosPolicy for per-event authorization

- Reuses your existing Zod/class-validator setup for payload validation

- Shares the global error handler

Example:

import ArkosGateway from arkos/websockets

const gateway = ArkosGateway({ name: "/", authentication: true })

gateway.on({ event: "send_message" }, (socket, data) => {

socket.to(data.room).emit("receive_message", data)

})

Other things baked into the event pipeline:

- Deduplication on by default, keyed on a mid in the message metadata, with a pluggable store - in-memory out of the box, bring your own for Redis or multi-instance setups

- maxAge option to reject stale messages, plus a built-in future-timestamp guard

- Enhanced broadcast targeting - excluding specific users, listing unique users in a room, targeting all active connections of one user

- Built-in retry with exponential backoff for acknowledged emits

Client packages: arkosjs websockets-client (framework-agnostic) and arkosjs react-websockets (hooks + provider). Vue, Svelte, Solid, and Angular bindings are in progress and open for community contribution.

Also in this release:

- Dynamic-mode permission overrides - grant or deny individual permissions to a specific user on top of their role, via a new UserPermission model

- Built-in static file serving and upload pipeline improvements

- Query orderBy now forwards straight to Prisma

- Scalar added as an alternative to Swagger for the API docs page

Upgrade with: pnpm install arkos@latest

Docs: arkosjs.com/docs

Repo: github.com/Uanela/arkos

Release notes: github.com/Uanela/arkos/releases/tag/v1.7.0-rc

Would love feedback - especially from anyone doing real-time features on top of Express and Prisma right now. Curious what pain points you're hitting.

​I wanted a single, production-grade, middleware suite to handle all of this ​so I built and just published keyguard-express—a TypeScript fork of the Python keyguard package. It handles machine-to-machine auth so you can leave your user auth (sessions, JWTs) to do its own thing.

With just 5 Loc, you get: API Key Auth: Fully secure via X-API-KEY headers, stored using PBKDF2-SHA512 with 100k iterations and timing-safe comparisons.
​Zero-Downtime Key Rotation: Link old keys directly to new keys on the fly; the old key acts as a deprecated fallback during the transition.
​HMAC Webhook Verification: Verifies X-Signature, X-Timestamp, and X-Nonce with strict replay and timing-safe guards.
​Abuse Protection: Tracks invalid requests and automatically blocks malicious IPs at a configurable threshold.
​Hybrid Storage: Auto-detects and swaps backends between SQLite/in-memory and PostgreSQL/Redis. And more🙂

Check the source on github {https://github.com/tyrmoga/keyguard_express }. Your contributions are welcome Try it out on your project (npm install keyguard-express)

What do you think? Would you use this on your project?

Express 5, Node 22.

Document upload route uses multer.single("file"), then immediately starts SSE on the same response:

  app.post("/s/:token/upload", requireSession, upload.single("file"), async (req, res) => {
    const file = req.file;
    ...
    await streamPipeline(res, documentId, file.path, filename);
  });

streamPipeline does writeHead (text/event-stream), flushHeaders, writes ":ok\n\n", then for-await loops pipeline events with res.write until res.end().

Session middleware runs first: looks up token in Postgres, attaches req.session, redirects to / if expired.

Questions:

1. Starting SSE inside a multer route handler: anything wrong with that? Multer has already parsed the body by then. Worried I'm mixing "file upload POST" and "long-lived stream" on one endpoint when I should split them.

2. Client closes tab mid-pipeline: upstream workflow tasks keep running. I write to res until something throws. What's the usual way to detect disconnect and stop writing without noisy errors? req.on("close")? res.on("close")?

3. Typing req.session via declare global on Express.Request: still the normal approach or is there something cleaner in Express 5?

Here is the github repo, main server is in main.ts and pipeline-stream.ts.

Shipped a new beta of Arkos (Express + Prisma framework) today, mostly cleanup and correctness fixes rather than big new features.

Highlights:

Email service config got more forgiving. Previously it threw if you didn't set both a user and password, even if your SMTP relay doesn't require auth. Now it only requires a host, and only sets up auth credentials if both are actually provided.

Error handler no longer trusts arbitrary statusCode/status fields on thrown errors unless the error is explicitly marked isOperational. This closes a small footgun where an unexpected error could accidentally leak an unintended status code or message to the client.

File upload static serving now returns a proper 404 (via AppError) when a file doesn't exist, instead of just falling through silently.

OpenAPI generation for file uploads is smarter now: better field descriptions distinguishing single vs array uploads, fixed array-binary-field schema flattening, and it conditionally includes a JSON content type alongside multipart/form-data depending on whether the upload is required.

Generated validators (both Zod schemas and class-validator DTOs from the CLI) now coerce types automatically, handling the classic "everything is a string when it comes from multipart or query params" problem for numbers, booleans, dates and bigints.

Also removed the old AuthPermissionAction enum from the create-arkos scaffold, in favor of a plain string, so custom actions don't require a schema migration anymore.

Nothing groundbreaking, but if you're running Arkos in production these are worth picking up.

Repo: github.com/uanela/arkos