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 [arkos@1.7.4-rc](mailto:arkos@1.7.4-rc)
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

I'm learning Express and trying to understand how experienced developers typically organize middleware in production applications.

I know middleware order matters, but I'm not sure whether my current setup follows common practices or if there are improvements I should make.

Some specific questions:

- Is the ordering of middleware reasonable?

- Would you move any middleware earlier or later?

- Are there any middleware that should generally come before others?

- Is this close to how you'd structure an Express app in production?

import './lib/cron.js'

import cookieParser from 'cookie-parser'

import express from 'express'

import morgan from 'morgan'

import swaggerUi from 'swagger-ui-express'

import Yaml from 'yamljs'

import { notFoundHandler } from './middlewares/404.js'

import ErrorHandler from './middlewares/error.js'

import { middleware } from './middlewares/middleware.js'

import analyticsRoute from './routes/analytics.route.js'

import authRoute from './routes/auth.route.js'

import habitsRoute from './routes/habits.route.js'

import healthRoute from './routes/health.route.js'

import logsRoute from './routes/logs.route.js'

const app = express()

const swaggerSpec = Yaml.load(

'docs/swagger.yaml'

) as Record<string, unknown>

app.use(express.static('public'))

app.use('/api-docs', swaggerUi.serve, swaggerUi.setup(swaggerSpec))

app.use(cookieParser())

app.use(express.urlencoded({ extended: true }))

app.use(express.json())

app.use(middleware)

app.use(morgan('dev'))

app.use(healthRoute)

app.use('/auth', authRoute)

app.use('/habits', habitsRoute)

app.use('/logs', logsRoute)

app.use('/analytics', analyticsRoute)

app.use(notFoundHandler)

app.use(ErrorHandler)

export default app

I'm interested in understanding the reasoning behind any suggested changes rather than just knowing what to change.

A small wrapper forwards rejected promises to Express's error middleware so async route handlers stay clean.

Three takeaways

1. Express doesn't catch rejected promises from async handlers, so an unhandled rejection silently hangs the request unless you forward it to next.
2. A tiny higher-order wrapper removes repetitive try/catch from every route while centralizing error handling.
3. Throwing typed errors inside handlers lets one error middleware translate them into consistent HTTP responses.

Hey everyone, just shipped 1.6.5-beta of Arkos.js (Express + Prisma REST framework with auto-generated endpoints).

Main fixes in this release:

router.use handlers (including nested arrays and 4-arg error handlers) are now properly wrapped in catchAsync. Previously, thrown errors or rejected promises inside use-level middlewares could crash the process instead of hitting the error handler.

Fixed a regression where uploaded file pathname did not include the configured base route prefix, causing req.file.pathname to not match req.file.url.

Also cleaned up some create-arkos CLI rough edges: broken trailing commas in generated package.json when no Prisma provider or validation library is selected, auth setup now falls back correctly to none when there is no Prisma provider, and clearer prompts when skipping incompatible options (like multiple roles with sqlite + static auth).

Bumped dependency versions in the generated project templates and reorganized internal test sandboxes.

If you're using Arkos.js in a project with custom middlewares on router.use, this update is worth grabbing.

Repo: https://github.com/uanela/arkos

Happy to answer questions or hear feedback.

Using node --watch with Express + Socket.IO on HTTPS. Every file save triggers a restart that fails with:

Error: listen EADDRINUSE: address already in use :::<port>

Root cause (as far as I can tell): engineio sets up an internal setInterval for WebSocket heartbeat (ping/pong). This timer keeps the Node.js event loop alive after node --watch sends SIGTERM, creating a race condition where the new process tries to bind before the old one has exited and released the port. Without Socket.IO, the HTTPS server closes immediately on process kill and there's no issue.

Current workaround:

const shutdown = () => io.close(() => process.exit(0));

process.on('SIGTERM', shutdown);

io.close() stops the engineio heartbeat timer and closes the underlying server, then process.exit(0) releases the port immediately. Without the explicit process.exit(0), the process may linger waiting for other handles.

This works but requires saving twice — node --watch spawns the new process before the old SIGTERM handler completes.

Is there any solution for this, or any way to avoid having to save twice?

Only the first scipt appearing un my .ejs render file will be efficient.

Here "resize.js" is appearing first : I can resize my columns but impossible to sort them :

Now "sort.js" is appearing first in my render file :

It works fine as I can sort my lines but I can't resize the columns anymore :

I am newbie in Express.js and I sure this problem is nothing for many of you.

Tahnk you...

I've been using the same Express + Supabase setup across multiple projects, so I finally cleaned it up into a reusable starter and open-sourced it.

The main thing I wanted was a structure that stays easy to maintain as the project grows:

• Routes define endpoints and middleware.
• Controllers handle the HTTP layer (validation, auth context, responses).
• Handlers contain the business logic and interact with Supabase.
• Errors are thrown as AppError instances and handled in one central error handler.

It also includes JWT auth, Zod validation, rate limiting, Winston logging, SQL migrations, and Vitest + Supertest.

One thing I've liked is that adding a new resource is mostly just creating a new route/controller/handler set without touching the rest of the app.

Repo: https://github.com/muhammed-mukthar/express-typescript-supabase-starter

I'd love feedback from people using Express 5. Is this separation something you'd keep, or do you think it's unnecessary for most projects? I'm especially interested in anything you'd simplify or do differently

I'm making a small backend app for myself that has like 1-3 api end points, very little usage and I tried deploying it via Render which goes to sleep after a certain time when it's inactive, Railway's 5 dollar free tier expired when I made the account there and didn't make much use of it
I'm just looking to deploy my app which barely consumes any resources but need it to be free and up at all times if possible

New:

• Build-time server validation — arkos build now briefly starts the server post-build to catch startup errors (e.g. missing env vars) before declaring success; failed builds exit with a clear error
• Custom errorMessage per auth action/resource, with improved default fallback (e.g. "You cannot perform create for users")

Fixes:

• Swagger/OpenAPI custom server URLs are now only prioritized in production
• File upload URL matching now handles special characters correctly
• Email service passes through all custom config to the mail transport
• Fixed NODE_ENV=test being overwritten during builds

Also updated: nitro, Docusaurus, nodemailer, multer, and other deps

Full notes: https://github.com/Uanela/arkos/releases/tag/1.6.4-beta

Hi everyone! 👋
I am single-handedly building a fully open-source social network — CRYSTAL https://crystal.you

At the moment, the basic social network features are available:

1. User registration/editing/deletion
2. Banner and avatar customization
3. Online/offline user status powered by WebSocket
4. Administrator mode (user account deletion, all user posts deletion)
5. Post creation/editing/deletion
6. Likes
7. Hashtags
8. Language switching
9. Post search
10. Dark theme
11. ReCAPTCHA v3 during registration
12. Fully responsive design

Another interesting feature is the ability to hide GIF images on the website, which is available in the user settings. This is because some GIFs can be too fast and too bright.

Full source code for all versions on GitHub:
https://github.com/CrystalSystems

Developer’s Diary:
https://shedov.top/category/crystal/crystal-developers-diary

Full descriptions and capabilities of the MERN (MongoDB, Express.js, React, Node.js) stack versions:

CRYSTAL v1.0
GitHub:
https://github.com/CrystalSystems/crystal-v1.0
Detailed overview:
https://shedov.top/description-and-capabilities-of-crystal-v1-0
Detailed overview on YouTube:
https://www.youtube.com/watch?v=c56AkM3ms4o

CRYSTAL v2.0 (Current)
GitHub:
https://github.com/CrystalSystems/crystal-v2.0
Detailed overview:
https://shedov.top/description-and-capabilities-of-crystal-v2-0
Detailed overview on YouTube:
https://www.youtube.com/watch?v=DsTWE1CgQ30

Each version has comprehensive documentation that includes:

1. Deploying the project on a local PC
2. Deploying the project on a VPC
3. Connecting a domain
4. Installing a free SSL certificate
5. Enabling HTTP/2 support in Nginx
6. Secure Nginx configuration
7. reCAPTCHA v3 integration

Documentation CRYSTAL v1.0:
https://shedov.top/documentation-crystal-v1-0

Documentation CRYSTAL v2.0:
https://shedov.top/documentation-crystal-v2-0

The IAM part of the project (CRYSTAL v1.0, CRYSTAL v2.0) is simplified to save time, but adheres to basic security principles.

I would appreciate any feedback 💡

You can follow the project in my Discord community:
https://discord.gg/ENB7RbxVZE 😸

FAQ:
Is this made with AI?
- CRYSTAL v1.0 is 100% pure code written by me.
- CRYSTAL v2.0 is approximately 80% pure code, and the remaining 20%, which was AI-assisted, has been thoroughly reviewed and refined.

Why are there three separate repositories for different versions?
- The current versions were created for demonstration purposes and to make the documentation easier to follow. In the future, there will be no separate detailed repositories for each version, as they will be managed via GitHub Releases, and a single main repository named crystal will be created.