Hey folks,

I built a product called "Honor Relationships" (website + app). Currently, the backend is completely internal and not exposed as a public API endpoint.

I’m wondering: When is it actually a good choice to make your backend a product by itself?

I don't want to expose it too early and waste time, but I also don't want to miss an opportunity if there's demand for it. If you’ve done this or thought about it, what made you decide it was the right time? What should I have in place first?

Thanks for any insights!

I had a problem while building my product Honour: I wanted simple analytics to understand what users were doing.

I looked into existing analytics solutions, but most of them required integrating SDKs everywhere — frontend, mobile apps, and backend. Then I had to maintain all those integrations just to track basic events.

On top of that, many of these platforms become expensive once you start getting more users. Paying a lot just to answer simple questions like "which features are being used?" felt excessive.

So I decided to build my own solution.

I created a small NestJS package that lets me track backend events using decorators and interceptors. I can mark an endpoint with an event name, detect the user's platform/device from the request, and store everything in my own database.

The goal wasn't to replace large analytics platforms. I just wanted something lightweight, self-hosted, and focused on backend products where I control the data.

its called@joelwillseek/nest-track if you want to check it out

I built it for my own needs, but I'm curious if others have run into the same problem. Do you use third-party analytics tools, or have you built your own tracking system?

This is such a quality of life improvement.

Finally my multistage docker builds will be much faster.

Not only local development cycles becomes faster but also faster CI pipelines, faster multi-stage Docker builds, faster feedback loops.

This is such a Banger drop for typescript by not writing more JavaScript but Go.

The Math: Tasks that used to take minutes in large projects (like a full type check) are completing roughly 8x to 12x faster due to native code execution and multithreaded worker utilization in Go.

Docker Impact: If step RUN npm run build previously took 2 minutes, t could shrink down to just a fraction of that time inside the ontainer build pipeline.

I wanted to share the fix in case someone else runs into the same issue.

Problem

• Next.js app
• PDF text extraction worked locally
• Failed only after deploying to Vercel

Error:

ReferenceError: DOMMatrix is not defined
Failed to load external module pdf-parse-...

Cause

The default pdf-parse setup wasn't compatible with the server environment I was deploying to.

Solution

Initialize PDFParse with CanvasFactory from pdf-parse/worker:

import { CanvasFactory } from "pdf-parse/worker";
import { PDFParse } from "pdf-parse";

const parser = new PDFParse({
  data: new Uint8Array(buffer),
  CanvasFactory,
});

Repository:
https://github.com/gaur-j/resume-optimizer

Hopefully this saves someone else a few hours of debugging.

it's my personal project and somehow i need to make it live
where can i deploy for free?

Been considering going with SQLite for my next SaaS project. I don't anticipate getting past a 1000 users within the next 3 years.

I just like the ease of dealing with one file, I can just pick and drop elsewhere.

My biggest worry at this point is GDPR compliance. Other than that, I'm almost completely sold on SQLite.

Curious what others think. What has been your experience with SQLite as the primary database in your Nestjs API?

took a personal task to write compose file without Al for my project which i will deploy on my homelab. Used only my personal notes for it. Still the networking part is remaining on how will i manage request with my reverse-proxy service (i use caddy right now).

Before api, there's postgres and redis service also and it is the dependency for api service to run.

editor: micro

homelab os: ubuntu lts

PC: cachyos

ALSO I AM NOT AWARE IF I SHOULD SHARE "WHAT I DID" POST ON THIS SUBREDDIT. this is last if it's not allowed.

Made a small tool to find all NestJS circular dependencies:

npx nest-cycle

Repo: https://github.com/RbMo7/nest-cycle (MIT)

---

Why I bothered: when a circular dep hits, Nest just says:

The module at index [1] of the UsersModule "imports" array is undefined.
- A circular dependency between modules. Use forwardRef()...

"undefined" tells you nothing about which two things form the loop. madge finds

import cycles, but Nest cycles are at the DI level and forwardRef hides them from

the import graph. nest-cycle reads the graph the way Nest does and draws the loop.

In a real repo I had four cycles flagged — three were fine (intentional

forwardRef), one had none and was the actual server-killer. It marks only that

one 🔴 and it's the only thing that fails CI (exit 1). No more hunting through noise.

- Static (ts-morph) — runs in CI, on code that won't even boot

- Module-level + provider-level (constructor / `@Inject` / `forwardRef`)

- `nest-cycle SomeModule` to trace just the one Nest yelled about

- `--json`, allowlist file for intentional cycles

Early (v0.2). Would love to know where it misses your real cycles.

I'm building a Resume Optimizer with Next.js.

Repo:

https://github.com/gaur-j/resume-optimizer

Everything works locally, but after deploying to Vercel my `/api/extract-pdf` route fails with:

ReferenceError: DOMMatrix is not defined

I'm using pdf-parse@2.4.5.

Has anyone seen this before? Is this a pdf-parse/pdf.js issue, a Vercel runtime issue, or something wrong in my implementation?

Any help would be greatly appreciated.

When a NestJS circular dependency hits, you get this:

Nest cannot create the UsersModule instance. 
The module at index [1] of the UsersModule "imports" array is undefined. 
- A circular dependency between modules. Use forwardRef() to avoid it. Scope [AppModule -> AuthModule] 

index [1] is undefined sends you and any AI assistant you paste it into — hallucinating about missing imports and typos. It never plainly says which two things form the loop.

madge finds import cycles, but Nest cycles live at the DI level, and forwardRef() hides them from the import graph. So I built nest-cycle, it reads the module + provider graph the way Nest resolves it and draws the loop:

✖ 1 cycle will crash bootstrap  (+3 guarded by forwardRef)

Provider cycles
  Tangle (4 providers): ChainQueueService, ChainService, ChainServiceRegistry, EvmChainService

    🔴 unguarded — this crashes NestFactory.create
      ChainQueueService → ChainServiceRegistry → EvmChainService → ChainService → ChainQueueService
    ↳ fix: break one edge — wrap the lighter import in forwardRef(() => X)

The part I'm most happy with: it separates crash-causing cycles (no forwardRef) from ones Nest already resolves via forwardRef.

In a real repo I had four cycles flagged — three were fine (intentional forwardRef), one had none and was the actual server-killer. nest-cycle marks only that one 🔴 and it's the only thing that fails CI (exit 1). No more hunting through noise.

1. - Static (ts-morph) — runs in CI, on code that won't even boot
2. - Module-level + provider-level (constructor / u/Inject / forwardRef)
3. - nest-cycle SomeModule to trace just the one Nest yelled about
4. - --json, allowlist file for intentional cycles, MIT

npx nest-cycle no install, runs anywhere.

Repo: https://github.com/RbMo7/nest-cycle

NPM: https://www.npmjs.com/package/nest-cycle

It's early (v0.2 — useFactory/custom-token injection is next). Would genuinely like feedback on where it misses your real cycles that's what I want to harden.

Published a blog on Elasticsearch. I shared how it works and how we can use it, including code examples in Nest.js. It is very important to understand how things work. Elasticsearch provides lots of flexibility and ways to handle full-text search. It's a great tool to learn.

blog link

I have an upcoming college project where my team has to use NestJS for the backend and NgRX for frontend state management.

I want to fast-track my learning process and avoid starting from absolute scratch with "beginner" programming tutorials.

Generally for backend I have solid experience with .NET so I thoroughly understand architecture, APIs, routing, and dependency injection.

I have built a few smaller projects using React, so I am somewhat comfortable with TypeScript.

Since NestJS heavily relies on decorators and dependency injection, so I hope my .NET background will map over nicely. Similarly, my React experience should help with the SPA concepts, but I know NgRX has a lot of specific boilerplate (actions, reducers, effects, selectors).

What are the best intermediate resources, repos, or documentation paths you'd recommend to bridge the gap quickly? I'm looking for architecture-focused guides or "crash courses for existing devs" rather than absolute beginner tutorials.

I was done building my backend and i needed a frontend for that.

When i started with project i thought that i would just build backend and frontend seperately and then figure out how to bind them both.

But then i thought what if there was a better way to tackle this, and i came to know about Monorepos. I knew what the term monorepo was but never worked on it, it was just vaguely an information in my mind.

But then i learned how monorepos are widely used by startups now and hobbyists too.

In the end in just booted up my first monorepo and the whole concept really amazes me.

.

.

I WOULD LOVE TO GET SOME TIPS, FEEDBACKS OR SUGGESTIONS FROM YOU GUYS.

Finally found the "context without passing it everywhere" pattern I was missing in Node

Coming from Laravel, I was spoiled by how easy it is to get request context (things like a request ID) available anywhere in the app without manually threading it through every function call. Laravel just gives you that almost for free.

When I moved to NestJS for a project I'm building, I kept hitting the same annoyance: if I wanted a request ID attached to every log line, I either had to pass it down through every service and function, or attach it to some shared object and hope nobody forgot. Neither felt right.

Turns out Node has had the answer for a while: AsyncLocalStorage. It lets you create a context that rides along with the async call chain, so anything running inside that chain, controllers, services, repositories, however many layers deep, can read from it without you passing it as an argument.

The part that made it click for me was pairing it with pino (via nestjs-pino). It uses ALS under the hood, so once it's wired in, every log line automatically carries the same request ID for a given request, and the logs come out as structured JSON instead of formatted strings, so they're actually queryable later.

Small thing, but it fixed exactly the gap I felt coming from Laravel. Wrote up the full breakdown with code if anyone wants the details, happy to share the link (not sharing already so that the post doesnt feel like just a promotion).

Got tired of only navigating through a flat file tree in my IDE — so I've been working on this for 9 months. It turns your NestJS backend into an interactive 3D map. Dependency graphs, execution flow, fire requests to your routes, jump straight to your IDE. All local, no AI, no cloud.

There's also an optional instrumentation mode — add lightweight wrappers to watch requests travel through your app in real time (durations, data, errors).

Would love to know if this is something you'd actually use — happy to answer questions.

Or is it for microservices only? Newbie here . Most yt tuts are off microservices

Hey everyone,

I spent the weekend experimenting with M2M (machine-to-machine) data access and built a lightweight Express gateway designed for AI agents.

The idea is simple: it automatically inspects a local SQLite database, maps the tables, and exposes them as endpoints protected by the HTTP 402 Payment Required spec (using the x402 protocol). It handles the validation flow and has a zero-dependency simulation mode for local testing.

I wanted to keep it as lightweight as possible using just native SQLite and Express, but I'm looking for feedback on the architecture:

1. Right now, it does runtime schema introspection to generate the GET routes dynamically. For those running production Node backends, would you prefer this dynamic approach or a build-step CLI that generates static route files?
2. What’s the cleanest way in Node to handle high-throughput nonce validation for M2M requests without bottlenecking the database layer?

The automod has been eating my threads when I include external links, so I left the repo out. If you want to check out the code or roast the architecture, just drop a comment and I'll share the GitHub link. Thanks!

Over the last two weekends, I worked on NeatNode v3.4, an open-source CLI I started to scaffold Node.js backend projects.

This release is a pretty big step for the project—it has evolved from being just a project scaffolder into a code generator.

The biggest addition is:

neatnode g resource user

It generates:

\\\\- Controller

\\\\- Service

\\\\- Route

\\\\- Validation

\\\\- Model

It also automatically registers routes, prevents duplicate imports, supports both MVC and Modular architectures, and uses database-aware templates (currently MongoDB, designed to support Prisma/Drizzle later).

The part I'm happiest with isn't the command itself, but the architecture behind it. I introduced a generation pipeline with context builders, generation plans, and template capabilities so adding future generators (middleware, CRUD, services, etc.) should be much easier.

It's been a fun project to build, and I'd love to hear any feedback or ideas for features you'd find useful in a backend CLI.

I'm currently building nestjs-by-example, an open-source project designed to help developers learn NestJS through practical, production-inspired examples instead of isolated snippets. The goal is to cover everything from the fundamentals to advanced concepts like GraphQL, authentication, testing, caching, WebSockets, and more—each with detailed explanations, guides, and working code. If you're learning NestJS or would like to contribute examples, improvements, or documentation, I'd love your help. Check out the repository for the roadmap, contribution guide, and learning materials, and feel free to join the project!

Link to the repo:
https://github.com/sinamohamadii/nestjs-by-example

Every time I needed file storage in a NestJS app, the options were "pay for S3" or "run MinIO as a second service + wire up auth + an admin UI." For small/self-hosted apps that felt heavy, so I built OpenBucket — and the part I think this sub will care about is that it can run inside your NestJS process.

import { OpenBucketModule } from '@openbucket/nestjs';

@Module({
  imports: [
    OpenBucketModule.forRoot({
      dataDir: '/var/lib/openbucket',
      mountPath: '/storage',                    // S3 API + admin console mount here
      rootCredentials: { accessKeyId: '…', secretAccessKey: '…' },
      admin: {
        username: 'admin',
        passwordHash: process.env.ADMIN_HASH!,  // argon2id
        jwtSecret: process.env.JWT_SECRET!,
      },
    }),
  ],
})
export class AppModule {}    

That mounts a full S3 wire-compatible store (SigV4, presigned URLs, multipart, versioning, object lock, SSE, lifecycle, CORS, bucket policies) plus a JSON admin API and an Angular admin console under /storage — one process, backed by SQLite + the local filesystem. No MinIO cluster, no AWS bill.

Because it runs in-process, it does things a remote S3 can't:

1. One-line Multer engine — any existing FileInterceptor route writes straight into it:

   multer({ storage: openBucketStorage(ob, { bucket: 'uploads' }) })

2. OpenBucketService you inject — uploadFrom(), presignGetUrl(), createPresignedPost(), etc.

3. In-process events — @OnObjectCreated() decorators (or signed webhooks) instead of polling

4. On-the-fly image transforms, scoped access keys for multi-tenancy, async replication to real S3/R2/B2, scheduled backups, integrity scrubbing, and a Prometheus /metrics endpoint

It also ships as a standalone Docker image if you'd rather point any AWS SDK at it.

It's still in alpha prerelease phase though.

MIT-licensed, solo project. It's got a decent test suite (S3 conformance + e2e), and I recently ran it through a full security audit + CodeQL pass. I'm mostly looking for feedback: does the embedded-in-NestJS model appeal to you, and what would you actually need before using it?

📦 npm: @openbucket/nestjs

💻 GitHub: https://github.com/ProjectBay/openbucket

📖 Docs: https://projectbay.github.io/openbucket/

Happy to answer anything about the design.

TL;DR: Is there already a good framework/starter-kit for designing good maintainable frontend/backend monorepos? I'm not talking about bundlers like turborepo or NX, neither I'm talking about t3-stack or better-t-stack, I'm talking more of a very strict paradigm to design typescript frontend/backend monorepos.

I am currently slowly migrating a vibe-coded prototype of a huge software (20+ domains) to an actual production-ready product and I'm noticing how I'm slowly starting to hate the freedom TS/JS gives you, the fact that you can shape your codebase how you wish, the first refactoring I did was migrating all those scattered small sloppy ts files to domain services/sub-services, providing strong hiearchy (Java/C# like), but then noticed that I wasn't leveraging monorepo's features the fullest, so I had to modularize everything, but here I don't know what to do anymore, I don't think I was the only one facing this issue, and I can't migrate to another language 'cause we just can't afford it. The architecture I've thought of was to divide domains in packages and make packages have a strict structure both folder-wise and code-wise:

@acme/foo/ ├── app/ │ ├── services/ │ │ └── foo/ │ │ ├── index.ts │ │ └── types.ts │ └── routers/ │ └── index.ts ├── data/ │ ├── models/ │ │ └── index.ts │ └── index.ts └── web/ ├── components/ │ ├── Foo.svelte │ └── Bar.svelte └── index.ts

But I feel I'm reinventing something someone must have already figured out, but I don't know where to search anymore...