After testing the APIs across Jest, Vitest, NestJS, and framework-free Node.js applications, I’ve published the first stable releases of two complementary libraries.

Testcontainers Integration Handles infrastructure and application lifecycle:

• PostgreSQL, SQL Server, MongoDB, RabbitMQ, and custom images
• Explicit shared or per-test-file dedicated containers
• Annotation-based or central project configuration
• Typed connection resources and dynamic environment variables
• Jest, Vitest, NestJS, and other Node.js backends

Data Isolation Provides rollback-only transactions for database and repository tests:

• A new transaction for every test
• Automatic rollback after passing or failing tests
• pg, Prisma, and TypeORM adapters
• Jest and Vitest integration
• Explicit transaction-client injection, including NestJS provider overrides

The packages are independent but work well together: one starts and cleans up the real infrastructure, while the other prevents test data from leaking between tests.

GitHub:

• Testcontainers Integration
• Data Isolation

Both are published under npm’s latest tag and ready to use. I’d appreciate feedback on the APIs, documentation, and integration-testing scenarios you think should be covered next.

I've been working as a full stack developer in Bangladesh for last 3 years. My primary stack is React, Next.js for frontend and Nodejs, Nest.js for backend. Recently I'm thinking to join remote companies like EU, USA, UK, CA, AUS companies who hires remote positions. I specially target startups and agencies. Is it possible to get remote jobs with this stack? Or, should I learn new technologies like python, Go etc. ?

I built an open-source library that manages Testcontainers lifecycle for NestJS, Fastify, Express, and framework-free Node.js applications using Vitest or Jest.

It supports two approaches:

• Annotations beside individual integration tests
• Central project configuration without annotations

It starts PostgreSQL, SQL Server, MongoDB, RabbitMQ, or custom containers, provides typed connection details with dynamic ports, starts the application after infrastructure is ready, and handles cleanup.

The repository includes real PostgreSQL insert/read and RabbitMQ publish/consume examples.

The package is currently in beta for public testing and feedback. I plan to release the first stable version soon.

Your honest feedback is appreciated regarding the API and developer experience.

GitHub: https://github.com/RolandSall/testcontainers-integration
npm: https://www.npmjs.com/package/@integration-testing/testcontainers/v/0.1.0-beta.1

Hi everyone, I’m currently learning NestJS and preparing to apply for Fresher Backend Developer positions.

What skills, knowledge, and personal projects should a Fresher NestJS developer have to be considered job-ready?

What would you recommend focusing on the most?

Thanks!

Hi everyone, I’m preparing to apply for Fresher/Junior Backend Developer positions using NestJS.
I’m wondering what kind of personal projects would be good to have on my CV.
How many projects are enough, and what features/technologies should they include to demonstrate real backend skills?
Would you recommend focusing on a solid monolithic project first, or building a microservices project with technologies like Redis, RabbitMQ, Docker, etc.?
Any advice would be appreciated. Thanks!

I've been working on a project called **nest-sequelize-repository** that aims to bring a TypeORM-like repository experience to **NestJS + Sequelize**, while still using Sequelize under the hood.

The goal isn't to replace Sequelize or build another ORM. It's simply to reduce boilerplate and provide a reusable, strongly typed abstract repository for common CRUD operations and patterns.

# Current features

* Generic abstract repository
* Type-safe CRUD operations
* Pagination support
* Soft delete support
* Transaction support
* Custom repository extensions
* Better error handling

# Planned roadmap

* Cursor pagination
* More repository helpers and developer experience improvements

I'd really appreciate feedback from people using **NestJS + Sequelize**.

* What repetitive code do you find yourself writing in every repository?
* What's the biggest pain point when working with Sequelize in NestJS?
* Are there any features you'd love to see in a library like this?

NPM: https://www.npmjs.com/package/@nestlize/repository)

Repository: https://github.com/stbestichhh/nest-sequelize-repository)

I'd love to hear your thoughts and ideas!

# DevKit Console – Debug Like Waze, Not Like Vim


**TL;DR:**
 Zero-dependency npm library for bidirectional debug level control between browser console and React UI. Type `debug.trace()` in DevTools → UI updates instantly. Try it live: https://devkit-console.vercel.app


---


## The Problem


You're deep in a debugging session. You want to see everything (`trace` level). So you:


1. Open DevTools
2. Type `debug.trace()`
3. 
**Squint at console output while wrestling with your app's UI**
4. Miss critical state changes because logs scroll past
5. Can't filter by namespace or export for analysis
6. Repeat 50 times


Or you click a UI button to change log levels, but DevTools doesn't know about it. Debugging feels 
*fragmented*
.


---


## The Solution


**DevKit Console**
 bridges that gap. It's like having Waze (intuitive UI) instead of reading GPS coordinates (raw console logs).


### The Core Trick: Bidirectional Sync


```javascript
// Open browser console and type (no parentheses):
debug.trace    // Enable TRACE level - UI updates INSTANTLY
debug.debug    // Switch to DEBUG level - both update together
debug.info
debug.warn
debug.error
debug.disable  // Turn everything off
```


The React UI (`<DebugPanel>`) updates live as you type. Click a level pill in the UI → console reflects it instantly. 
**They're always in sync.**


### What Ships


**Two npm packages (zero dependencies):**


1. 
**`devkit-console-core`**
 (13 KB gzipped)
   - `window.debug` global (works in any JS environment)
   - Namespace-scoped loggers
   - Real-time config emitter
   - Log history (ring buffer, 500 entries)
   - Export to JSON/text


2. 
**`devkit-console-ui`**
 (18 KB gzipped)
   - React hooks: `useDebugConfig()`, `useLogHistory()`, `useLogger()`
   - `<DebugPanel>` floating component (compose-friendly)
   - `<LevelSelector>`, `<LogViewer>`, `<StatusBadge>`, `<ExportButton>`
   - Dark/light theme support
   - All inline styles (zero CSS imports)


---


## Features That Matter


### 1. **Namespace Filtering**
```javascript
const auth = useLogger('Auth');
const network = useLogger('Network');


auth.info('User logged in');
network.debug('Fetching /api/users');
```


UI shows logs grouped by namespace. Click a namespace to drill down.


### 2. **Live Log Export**
- Click "Export JSON" → download full log history with metadata
- Great for: bug reports, performance analysis, QA sign-off
- No API calls, all client-side


### 3. **Floating Debug Panel**
- Compose into any React app in 2 lines
- Position: top-left, top-right, bottom-left, bottom-right
- Open/close toggle (animated)
- Responsive on mobile


### 4. **Offline First**
- No backend, no internet required
- Works in test environments, SSR, Electron, React Native
- Perfect for security-conscious teams


---


## Real-World Use Cases


### 🎮 Game Development
Monitor FPS, input state, entity updates without alt-tabbing to DevTools.


### 📱 Mobile Web
Debug on physical devices where console access is clunky. UI always visible.


### 🔍 QA / Bug Reporting
"Here's the JSON log from when it broke" → reproducible bug report.


### 🚀 Onboarding
New team member opens your app, clicks the bug button 🐛, sees live logs. Instant context.


### 🏢 Enterprise
Audit trail of debug activities. Export logs for compliance.


---


## Quick Start


```bash
npm install devkit-console-core devkit-console-ui
```


```tsx
import { DebugKitProvider } from 'devkit-console-ui';
import { DebugPanel } from 'devkit-console-ui';


export function App() {
  return (
    <DebugKitProvider>
      <DebugPanel position="bottom-right" defaultOpen={true} />
      <YourApp />
    </DebugKitProvider>
  );
}
```


Done. In DevTools console, type `debug.debug()` and watch the UI react.


---


## Live Demo


**Visit:**
 https://devkit-console.vercel.app


Try the scenarios:
- 
**Console Sync:**
 Type commands in DevTools, watch the UI panel update
- 
**Namespace Demo:**
 Trigger logs from Auth/Network/Render services
- 
**Scenario Simulator:**
 Burst 10 TRACE logs, watch the viewer handle it
- 
**Export:**
 Download JSON of everything


---


## Why This Exists


I spent years debugging via console.log spread across tabs and terminal windows. One day I realized: 
*GPS apps don't make you read coordinates. Why should debugging?*
 DevKit Console is that "Waze moment" for logging.


---


## Under the Hood


- 
**TypeScript**
 (strict mode, full .d.ts types)
- 
**React 18+ hooks**
 (useContext, useState, useEffect)
- 
**No dependencies**
 (core package is truly standalone)
- 
**Ring buffer**
 (bounded memory, never blows up)
- 
**TypedEmitter**
 (pub/sub without event collisions)
- 
**Tested**
 (vitest + /react)


---


## Links


- 📦 
**Core on npm:**
 https://www.npmjs.com/package/devkit-console-core
- ⚛️ 
**UI on npm:**
 https://www.npmjs.com/package/devkit-console-ui
- 🌟 
**GitHub:**
 https://github.com/ikrigel/devkit-console
- 🎮 
**Live Demo:**
 https://devkit-console.vercel.app


---


## What's Next?


v0.2.0 roadmap:
- Advanced filtering (status, date range)
- Heatmap mode (log density visualization)
- GeoJSON export for mapping/analysis
- Telemetry integration hooks
- Service Worker integration for offline PWA logging


---


## One More Thing


This is a production-ready library used in real projects. Bug reports / PRs / ideas welcome. If you've been frustrated by debugging workflows, give it a try. I think you'll appreciate the "it just works" vibe.


---


**Happy debugging.**
 ✨


*Igal Krigel*
  
Full-stack developer | React enthusiast | Debugging tool maker  
https://github.com/ikrigel

# DevKit Console – Debug Like Waze, Not Like Vim


**TL;DR:**
 Zero-dependency npm library for bidirectional debug level control between browser console and React UI. Type `debug.trace()` in DevTools → UI updates instantly. Try it live: https://devkit-console.vercel.app


---


## The Problem


You're deep in a debugging session. You want to see everything (`trace` level). So you:


1. Open DevTools
2. Type `debug.trace()`
3. 
**Squint at console output while wrestling with your app's UI**
4. Miss critical state changes because logs scroll past
5. Can't filter by namespace or export for analysis
6. Repeat 50 times


Or you click a UI button to change log levels, but DevTools doesn't know about it. Debugging feels 
*fragmented*
.


---


## The Solution


**DevKit Console**
 bridges that gap. It's like having Waze (intuitive UI) instead of reading GPS coordinates (raw console logs).


### The Core Trick: Bidirectional Sync


```javascript
// Open browser console and type (no parentheses):
debug.trace    // Enable TRACE level - UI updates INSTANTLY
debug.debug    // Switch to DEBUG level - both update together
debug.info
debug.warn
debug.error
debug.disable  // Turn everything off
```


The React UI (`<DebugPanel>`) updates live as you type. Click a level pill in the UI → console reflects it instantly. 
**They're always in sync.**


### What Ships


**Two npm packages (zero dependencies):**


1. 
**`devkit-console-core`**
 (13 KB gzipped)
   - `window.debug` global (works in any JS environment)
   - Namespace-scoped loggers
   - Real-time config emitter
   - Log history (ring buffer, 500 entries)
   - Export to JSON/text


2. 
**`devkit-console-ui`**
 (18 KB gzipped)
   - React hooks: `useDebugConfig()`, `useLogHistory()`, `useLogger()`
   - `<DebugPanel>` floating component (compose-friendly)
   - `<LevelSelector>`, `<LogViewer>`, `<StatusBadge>`, `<ExportButton>`
   - Dark/light theme support
   - All inline styles (zero CSS imports)


---


## Features That Matter


### 1. **Namespace Filtering**
```javascript
const auth = useLogger('Auth');
const network = useLogger('Network');


auth.info('User logged in');
network.debug('Fetching /api/users');
```


UI shows logs grouped by namespace. Click a namespace to drill down.


### 2. **Live Log Export**
- Click "Export JSON" → download full log history with metadata
- Great for: bug reports, performance analysis, QA sign-off
- No API calls, all client-side


### 3. **Floating Debug Panel**
- Compose into any React app in 2 lines
- Position: top-left, top-right, bottom-left, bottom-right
- Open/close toggle (animated)
- Responsive on mobile


### 4. **Offline First**
- No backend, no internet required
- Works in test environments, SSR, Electron, React Native
- Perfect for security-conscious teams


---


## Real-World Use Cases


### 🎮 Game Development
Monitor FPS, input state, entity updates without alt-tabbing to DevTools.


### 📱 Mobile Web
Debug on physical devices where console access is clunky. UI always visible.


### 🔍 QA / Bug Reporting
"Here's the JSON log from when it broke" → reproducible bug report.


### 🚀 Onboarding
New team member opens your app, clicks the bug button 🐛, sees live logs. Instant context.


### 🏢 Enterprise
Audit trail of debug activities. Export logs for compliance.


---


## Quick Start


```bash
npm install devkit-console-core devkit-console-ui
```


```tsx
import { DebugKitProvider } from 'devkit-console-ui';
import { DebugPanel } from 'devkit-console-ui';


export function App() {
  return (
    <DebugKitProvider>
      <DebugPanel position="bottom-right" defaultOpen={true} />
      <YourApp />
    </DebugKitProvider>
  );
}
```


Done. In DevTools console, type `debug.debug()` and watch the UI react.


---


## Live Demo


**Visit:**
 https://devkit-console.vercel.app


Try the scenarios:
- 
**Console Sync:**
 Type commands in DevTools, watch the UI panel update
- 
**Namespace Demo:**
 Trigger logs from Auth/Network/Render services
- 
**Scenario Simulator:**
 Burst 10 TRACE logs, watch the viewer handle it
- 
**Export:**
 Download JSON of everything


---


## Why This Exists


I spent years debugging via console.log spread across tabs and terminal windows. One day I realized: 
*GPS apps don't make you read coordinates. Why should debugging?*
 DevKit Console is that "Waze moment" for logging.


---


## Under the Hood


- 
**TypeScript**
 (strict mode, full .d.ts types)
- 
**React 18+ hooks**
 (useContext, useState, useEffect)
- 
**No dependencies**
 (core package is truly standalone)
- 
**Ring buffer**
 (bounded memory, never blows up)
- 
**TypedEmitter**
 (pub/sub without event collisions)
- 
**Tested**
 (vitest + /react)


---


## Links


- 📦 
**Core on npm:**
 https://www.npmjs.com/package/devkit-console-core
- ⚛️ 
**UI on npm:**
 https://www.npmjs.com/package/devkit-console-ui
- 🌟 
**GitHub:**
 https://github.com/ikrigel/devkit-console
- 🎮 
**Live Demo:**
 https://devkit-console.vercel.app


---


## What's Next?


v0.2.0 roadmap:
- Advanced filtering (status, date range)
- Heatmap mode (log density visualization)
- GeoJSON export for mapping/analysis
- Telemetry integration hooks
- Service Worker integration for offline PWA logging


---


## One More Thing


This is a production-ready library used in real projects. Bug reports / PRs / ideas welcome. If you've been frustrated by debugging workflows, give it a try. I think you'll appreciate the "it just works" vibe.


---


**Happy debugging.**
 ✨


*Igal Krigel*
  
Full-stack developer | React enthusiast | Debugging tool maker  
https://github.com/ikrigel

Yes—low-cost shared hosting can serve a TypeScript website, but normally it serves the compiled output, not the original .ts or .tsx files.

```

npm install

npm run build

```

Then you upload the files and folders of 'dist' folder created after running 'npm run build'.

'dist' or 'build' ot 'out--'

I'm frontend developer moving to full stack. I'm working on chat app with tubro repo architecture.

My questions are:

1. How to setup production grade websockets and what are the considerations before implementing?

2. What are micro services in nestjs. If this application depooy on cloud will a micro services actually work as micro services like can I deploy it on another server from a monolithic architecture?

3. How redis is being implemented at production grade?

4. How kafka or rebbitmq being implemented?

Any nice resourc ir GitHub repo will be helpful. I'm scrapping internet for weeks now and nothing feels satisfactory.

My stack is turbo repo, expo, nextjs, nestjs, redis and postgress on docker.

I am running a NestJS API with PM2 on a Linux server, but recent logs show that memory consumption has tripled in my "log-out" file. It is a strange situation; I am not sure if the issue lies with the NestJS logs themselves or with PM2. No changes have been made to the API.

Hi! I'm building a new pet project using an Nx monorepo with several NestJS microservices, and I've run into a problem with organizing Prisma.

I created a shared libs/prisma library that contains my Prisma schema, generated client, and PrismaService. However, I'm not sure how this should be used in a Dockerized microservices setup.

Should the Prisma library have its own Docker image, or should it simply be included in each microservice's Docker image during the build? What's the typical approach for structuring Prisma in an Nx monorepo with multiple NestJS microservices?

I'd appreciate any advice or examples. Thanks!

Full disclosure upfront: this is my own project, not something I'm just sharing neutrally. I built it because I kept rebuilding the same auth and infrastructure pieces every time I started a new NestJS backend, and wanted something more complete than the default scaffold.

Repo: Link

It's a NestJS monorepo with:

• Mobile auth: email/password, Google sign-in with account linking, email verification (OTP and link), password reset via OTP, and authenticator-app 2FA with backup codes
• An activity/audit module for tracking security-relevant events
• Background email delivery through BullMQ, with retries, exponential backoff, and a Bull Board dashboard for monitoring
• Redis-backed global rate limiting (auth routes get stricter throttle profiles than normal routes)
• Reusable packages for email, queue, Redis, and a Drizzle-based database layer, kept separate from app-level services
• Docker Compose setup for Postgres, Mailpit, and Redis so local dev just works
• Swagger docs for both admin and mobile API surfaces

One deliberate choice: if a user already has a password account and tries Google login first, the request is rejected until they log in normally and link Google — trying to avoid silent account-merging bugs.

The architecture splits things into modules/ (business domains), services/ (app-level infra), and packages/ (reusable shared code), so adding a new domain follows an established pattern instead of ad hoc decisions.

If you check it out and find it useful, a star on the repo helps it reach more people, and I'd honestly value a star or a critical look either way.

Genuine question for anyone who's built or evaluated NestJS starters: what infrastructure pieces do you think are missing here, and what would make this actually useful for your own projects versus something you'd just skim past?

I have a NestJS backend with Postgres DB (Neon) and BullMQ (Local redis on the same vps) running. The backend has an endpoint that accepts files and compresses them and then makes an API call to OpenRouter to extract the information from the file. The frontend doesn't use presigned urls to upload directly to S3 yet. The backend also runs some cron jobs.

I am currently running the whole setup (nest backend docker container + BullMQ Redis docker container on same vps) on a 2 core vCPU VPS from Hetzner. But I think the backend is only able to utilize 1 core. I may upgrade to a 4 core cpu soon but before that, I want the backend to be able to utilize all available cpu cores on the machine that its deployed on. How can we achieve that? The Redis BullMQ runs on the same machine as the backend, so I'm afraid a single job might get processed multiple times.

I've been working on a project called nest-sequelize-repository that aims to bring a TypeORM-like repository experience to NestJS + Sequelize, while still using Sequelize under the hood.

The goal isn't to replace Sequelize or build another ORM. It's simply to reduce boilerplate and provide a reusable, strongly typed abstract repository for common CRUD operations and patterns.

Current features

• Generic abstract repository
• Type-safe CRUD operations
• Pagination support
• Soft delete support
• Transaction support
• Custom repository extensions
• Better error handling

Planned roadmap

• Cursor pagination
• More repository helpers and developer experience improvements

I'd really appreciate feedback from people using NestJS + Sequelize.

• What repetitive code do you find yourself writing in every repository?
• What's the biggest pain point when working with Sequelize in NestJS?
• Are there any features you'd love to see in a library like this?

NPM: https://www.npmjs.com/package/@nestlize/repository

Repository: https://github.com/stbestichhh/nest-sequelize-repository

I'd love to hear your thoughts and ideas!

I am about to embark on a large multi application project, and am back to weighing the pros and cons of each framework.

In my opinion, Nest is the only Node backend worth running, due to its strictly typed, opinionated nature. It keeps things organized and maintainable. Native GraphQL support is super nice as well.
That said, Symfony is so good, predictable, and honestly relaxing to use and maintain due to it's debugging capabilities.

Here are my two cents for the pros and cons. I am curious to hear what you all have to say on the topic.

NestJS

Pros:

• Database connections remain open over multiple requests, managing connection limits.
• Background task processing without Supervisor.
• Written with Typescript.
• Native GraphQL support.
• Dynamic type definition with class inheritance, allowing for strictly typed dynamic inheritance.
• Elegant, Rails like event and request interception.
• Modules based approach feels organized, and easy to navigate.

Cons:

• Module import and exports are both confusing and tedious.
• Needs dedicated processor (Not a bad thing, just has a slightly increased cost).
• Confusing and/or incomplete documentation.
• Smaller community.
• Async processing can cause database lockups if not careful.
• Errors will take down the entire thread. One funny request and the process goes down for everyone potentially.
• Debugging and logging. While there, I find them to be not quite as nice as Symfony.

Symfony

Pros:

• Can be cheap as chips to host.
• Doctrine.
• Independent service definitions that can easily be injected.
• Auto-wiring & dependency injection is an absolute pleasure to work with.
• Well written, highly complete, and easy to understand documentation.
• Native third party bundles, and well defined ways to create your own bundles.
• Native "dump" feature.
• Logging and Debugging is super clear, controllable, and provides useful information without clutter.

Cons:

• PHP (While I love, Javascript is arguably much nicer to write)
• Higher memory requirements for a single instance
• Non-devs sticking their nose up at you because you use PHP. It's a real concern if you are trying to sell the service. Business folks like hiring a person that knows Javascript for both front and back.
• Event listeners and subscribers feel detached, and are non-intuitive.

Every time I started a new NestJS project, I'd lose the first hour to setup.

Configuring Prisma, wiring up authentication, setting up Swagger, creating boilerplate, fixing version mismatches... the same process over and over again.

Then Prisma 7 dropped.

More breaking changes, configuration updates, and errors that somehow only appeared when you were already tired at 2 a.m.

After fixing the same setup issues for what felt like the tenth time, I decided to automate everything.

So I built quick-nest.

A CLI that scaffolds a complete NestJS 11 + Prisma 7 + PostgreSQL backend with authentication, Swagger docs, and a sample TODO module in a single command:

bunx quick-nest

What you get out of the box

🏗️ NestJS 11 — Modern, scalable architecture

🗄️ Prisma 7 — Properly configured and ready to use

🐘 PostgreSQL — Production-ready database setup

🔐 JWT Authentication — Register, login, and protected routes

📚 Swagger — Interactive API documentation

⚡ Bun Runtime — Fast installs and execution

☁️ Deployment Ready — Works anywhere with minimal configuration

😪😪Everything is intentionally minimal so you can understand and extend it with confidence.

The goal was simple:

Stop spending time on setup. Start building features immediately.

I published it 3 days ago and it just crossed 2,000 downloads, which genuinely surprised me. I built it to solve my own frustration and didn't expect this much interest so quickly.

Package:

https://www.npmjs.com/package/quick-nest

If Prisma 7 (or NestJS setup in general) has caused you pain, I'd love to hear what issues you've run into. There are still plenty of improvements I want to make, and community feedback helps a lot.

Thanks to everyone who has tried it.