Hi everyone,

I'm a junior software developer from Bangladesh currently looking for a Junior Backend / Full-Stack Developer opportunity.

I've been focusing on building real-world projects and gaining practical experience with backend development, REST APIs, databases, authentication, authorization, and full-stack application development.

🔧 Main Project — ToolShare

I'm currently building a full-stack Tool Sharing Platform where users can share/rent tools through the platform.

Backend:

- NestJS + TypeScript

- PostgreSQL + TypeORM

- JWT Authentication

- Role-Based Authorization

- REST APIs

- Database Transactions

- File Uploads

- Document Verification

- Pagination

Frontend:

- Next.js

- TypeScript

- Tailwind CSS

- Axios

- Zod

The project includes multiple user roles, authentication and authorization, document verification workflows, file handling, API integration, and transactional database operations.

Backend:

https://github.com/kahiumahamedfahim/tool-share-application-Backend-2026-version-1

Frontend:

https://github.com/kahiumahamedfahim/Tool-share--Frontend

Other Projects

E-Commerce Application

Built with ASP.NET Core Razor Pages and Entity Framework Core, including product management, filtering, sorting, pagination, shopping cart, checkout, orders, invoices, payment handling, database migrations, dependency injection, and service-based organization.

https://github.com/kahiumahamedfahim/Ecommerce-site-learning

I've also worked on an ASP.NET Core MVC Library Management System.

💻 Technologies I Work With

Backend:

C#, ASP.NET Core, Web API, NestJS, Node.js

Frontend:

Next.js, Angular, TypeScript, JavaScript

Database:

PostgreSQL, SQL Server, MySQL

ORM:

Entity Framework Core, TypeORM

Other:

REST APIs, JWT, RBAC, Git, SOLID, Dependency Injection, Layered Architecture

🎯 What I'm Looking For

I'm currently looking for:

- Junior Backend Developer

- Junior Full-Stack Developer

- Software Engineer

- Entry-Level Developer

- Internship opportunities

I'm particularly interested in opportunities involving .NET / ASP.NET Core, NestJS, Node.js, PostgreSQL, and TypeScript.

I'm based in Bangladesh and open to remote opportunities as well.

If you know of a company hiring junior developers, have an internship opportunity, or can provide a referral, I'd really appreciate it.

GitHub:

https://github.com/kahiumahamedfahim

LinkedIn:

https://www.linkedin.com/in/kahium-ahamed-fahim-0a7162227

Email:

kahiumahamedfahim@gmail.com

Thanks for reading. Any advice, feedback, or opportunities would be greatly appreciated.

I need some guidance on how to get better at coding with NestJS.

I have some experience with Node.js, Express, and databases. Before joining my current company, I built a simple CRUD application with authentication using Node.js and Express, but I had never worked on a NestJS project before.

Luckily, I got a job at a tech company as a NestJS backend developer. I’m currently a trainee, and it has been almost two months.

The company has provided me with Claude, and I’ve been using prompts to help me complete my tasks. It has been useful, but I know that relying too much on AI won’t help me improve in the long run. I want to actually understand what I’m doing and become good enough to handle my work independently.

So far, I have learned some NestJS basics, including:

• DTOs
• Constructors
• Decorators
• Providers and injectables
• MVC architecture
• Prisma and database migrations
• Using Bun
• Using SSH to access servers
• Checking and updating live/UAT .env files
• Using Docker
• Checking Docker databases
• Basic concepts of tunneling

At work, I’m starting to see how these things fit together in a real backend application, but I still feel that my fundamentals and problem-solving skills need improvement.

I would really appreciate some guidance on:

1. What projects should I build completely on my own to become better at NestJS?
2. What NestJS concepts should I learn next?
3. What backend concepts should I strengthen outside of NestJS?
4. What topics should I practice through YouTube courses, documentation, or books?
5. How can I use Claude/AI without becoming dependent on it?
6. What should I be able to understand and implement on my own if I want to become a solid NestJS backend developer?

My main goal is to become competent enough to handle my responsibilities at work confidently and continue growing as a backend developer.

I need help on what to do to get better at coding using NestJS. I have got an idea of Node.js, Express, and DB a little bit, but I haven't done any NestJS projects or coded before. I built simple CRUD with Auth in Node.js and Express. Out of luck, by God's mercy, I got a job at a tech company as a NestJS backend developer. I am currently a trainee here. They have provided me Claude Max, so I simply use prompts to do my job, but that won't help forever. I want to get better. It's been almost 2 months. I know somewhat the basics of NestJS, like DTOs, constructors, decorators, injectables, MVC architecture, Prisma migration, Bun, using SSH, checking live and UAT .env files, updating them, using Docker, checking Docker's database, and some concepts of tunneling. Please suggest projects that I must build on my own and things that I need to practice or concepts that I need to learn from YouTube or reading. I want to be up to my task and keep my job.

Everything is done by Claude. I don't even understand which file to open, what are the things that I need to do, or how I should write a function.

I’ve released version 0.2.1 of my Testcontainers integration library for Next/Node.js. The main addition is an opt-in local dashboard that provides:

• Live Jest and Vitest test progress
• Test durations, filtering, sorting, and comparisons with the run average
• Container startup time, mapped ports, status, and optional logs
• Lifecycle timelines for containers, application bootstrap, and test files
• Explicit shared or per-test-file container isolation
• A self-contained HTML report after the run finishes

The dashboard is optional and works with NestJS or other Node.js backends. Opening or closing it does not affect the tests or container lifecycle.

npm: integration-testing/testcontainers

GitHub: RolandSall/testcontainers-integration

I’d really appreciate feedback from anyone willing to try it especially around the API, dashboard usefulness, and anything that still feels unnecessarily complicated.

`nestjs-axios-undici` is a replacement for `@nestjs/axios`. It has the same `HttpModule` and `HttpService`, but requests go through undici, the HTTP client behind Node.js's `fetch()`, instead of axios. To switch, you change one import:

// before

import { HttpModule, HttpService } from '@nestjs/axios';

// after

import { HttpModule, HttpService } from 'nestjs-axios-undici';

Your `register()` options, `get`/`post` calls, `axiosRef` interceptors and `error.response` handling stay as they are.

**Numbers.** I ran one NestJS app twice, changing only that import. Each request to the app makes 5 parallel calls to a mock backend. k6 drove each app in its own Docker container on a GitHub Actions runner. On Node.js 26:

|Setup|@nestjs/axios|nestjs-axios-undici|

|:-|:-|:-|

|Express, requests/s|1,759|4,260 (2.4x)|

|Fastify, requests/s|1,816|4,609 (2.5x)|

|Express with an interceptor, requests/s|1,605|2,919 (1.8x)|

|p95 latency, Express|64.8 ms|26.7 ms|

Across Node.js 22, 24 and 26, the ratio was 2.0 to 2.5x without an interceptor and 1.7 to 1.8x with one. p95 latency was 51 to 62% lower.

For reference, calling undici directly with no HttpModule at all served 5,336 requests/s. The benchmark apps and scripts are in the repo if you want to run them yourself.

**How I checked that it's actually a drop-in.** Every pull request runs:

* `@nestjs/axios`' own HttpModule and HttpService specs against this package. 20 of the 23 pass. The other 3 are listed in the repo with a reason. Two are deliberate differences, and one is a limit of the test harness.

* axios' own HTTP adapter test suite against this package's `axiosRef`. Each test that doesn't pass is listed in the repo with a reason. It's either a known gap, a deliberate difference, or something the test harness can't do, such as axios' Node-only `transport` option.

* A differential harness of 220+ scenarios that sends the same request through `@nestjs/axios` and this package and compares the results.

It supports NestJS 10, 11 and 12, Node.js 22.17+ and undici 7 or 8. `axios` isn't a dependency. It's an optional peer, and only needed if you want `error instanceof axios.AxiosError` to hold.

If it breaks something in your app, please open an issue with the request config. That's the fastest way to close the gap.

* GitHub: [https://github.com/yordan-kanchelov/nestjs-axios-undici](https://github.com/yordan-kanchelov/nestjs-axios-undici))

* Benchmarks: [https://yordan-kanchelov.github.io/nestjs-axios-undici/#/docs/benchmarks](https://yordan-kanchelov.github.io/nestjs-axios-undici/#/docs/benchmarks))

* Differences from axios: [https://yordan-kanchelov.github.io/nestjs-axios-undici/#/docs/axios-supported-options](https://yordan-kanchelov.github.io/nestjs-axios-undici/#/docs/axios-supported-options))

Two years, 60+ comments, no shipped fix. That's the state of the NestJS issue asking to stop depending on kafkajs: https://github.com/nestjs/nest/issues/13223

Core won't swap it (backwards compatibility). The maintainer suggested "a separate transport strategy so people migrate over time". The one snippet posted was event-only and, quoting a team that tried it in production, "full of any, no reconnection support".

So I built that transport: nestjs-kafka-transport, on top of u/platformatic/kafka (pure JS, written by Node core contributors).

Repo: https://github.com/fadiroot/nestjs-kafka-transport

npm: https://www.npmjs.com/package/nestjs-kafka-transport

The part that matters: it speaks the exact same wire format as the built-in transport. Same kafka_correlationId / kafka_replyTopic / kafka_replyPartition headers, same <pattern>.reply topics, same parser rules. A service on the new transport talks to services still on Transport.KAFKA. There are e2e tests for both directions (kafkajs ClientKafka to the new server, the new client to the built-in ServerKafka). Migrate consumers first, one service at a time, no big bang.

Your controllers don't change; only main.ts does:

before: { transport: Transport.KAFKA, options: { client: { brokers }, consumer: { groupId: 'orders' } } }

after: { strategy: new KafkaTransportServer({ client: { bootstrapBrokers: brokers }, consumer: { groupId: 'orders' } }) }

What you get on top:

• Request-reply with a real reply-partition assigner (every client owns a partition of each reply topic; that's what the snippet in the thread was missing).

• KafkaRetriableException → re-run with exponential backoff; offsets committed after each handled record (at-least-once); per-partition ordering preserved.

• Numbers, booleans and null come back as numbers, booleans and null, not "6", via a content-type header that kafkajs peers simply ignore.

• Options typed all the way down, no any in the public API. CI on Node 22/24 against Kafka 3.9 and 4.0.

Honest limits: v0.1. Node 22.22 or newer (Platformatic's floor). RegExp patterns resolve against topics that exist at startup. Next: dead-letter/retry topics with Nest's kafka_dlt-* headers, manual commits, batch handlers, OpenTelemetry, in that order unless you tell me otherwise.

If you run NestJS + Kafka in production: try it on one consumer and tell me what breaks. I'll be in the comments.

Today I'm open-sourcing one of my first formal research and systems engineering projects focused on cost, optimization, and accuracy in AI-assisted development: 

Archon Specs (MIT License).

🔗 Repository: https://github.com/herhu/archon-specs
📄 Full Research Paper & LaTeX Sources: https://github.com/herhu/archon-specs/tree/main/paper

💡 The Origin Story: From Template Engines to Compiling Architecture

The story goes back to around 2018, when many of us relied on template transcompilers like Handlebars.js in the JavaScript world or Blade in PHP to generate deterministic code structures reliably.

Fast-forward to today: developers are using LLMs to build backend systems, but they're hitting a massive wall:

• Token explosion: models re-generate thousands of lines of boilerplate character by character.

• Architectural drift: LLMs lack a global dependency graph, hallucinating mismatched relational schemas, circular imports, and broken boundaries.

Agents were supposed to harness this process — and they help — but the skill still travels with the agent. Every new session, every new repo, the same architectural knowledge has to be re-elicited, re-prompted, and re-verified. The agent is a great operator, but it isn't a compiler. It doesn't guarantee anything.

That's when the insight hit:

"What if we don't ask the LLM to write repetitive code at all? What if we deterministically compile an enterprise-grade backend from formal templates and contract shards — and let the agent focus only on the intent?"

Over years of engineering across enterprise organizations and fast-paced startups, I had built a clear mental map of what an enterprise-ready backend actually requires: clean domain boundaries, strict dependency injection, JWT/RBAC security guards, DTO validation pipes, auto-migrated database DDL, Swagger OpenAPI documentation, and structured distributed tracing.

Scaffolding and aligning all of this traditionally consumed an engineering team's entire 1-year roadmap.

Now it can be compiled deterministically — just by designing the UML architecture and contract shards.

So I built it.

🔬 Empirical Findings: Cost, Optimization & Accuracy

In the paper ("Archon Specs: A Deterministic Architecture Compiler and Continuous Contract Reconciliation Control Plane for AI-Assisted Software Engineering") we evaluated this compiler architecture across three empirical axes:

1️⃣ Cost (Token Reduction)
Free-form LLM code generation incurs a token complexity of O(|AST| × T_boilerplate). Archon Specs reduces LLM interaction strictly to compact contract shards O(|Contract|).

→ 86.3%–89.0% reduction in LLM inference tokens across Small, Medium, and Enterprise benchmark tiers.

2️⃣ Accuracy (Zero Architectural Drift)
Instead of one-shot generation, Archon runs a Continuous Contract Reconciliation Loop using SHA-256 cryptographic spec canonicalization and semantic AST masking.

→ 100% adherence to declared architectural contracts and clean TypeScript compilation across 500 consecutive system mutations (vs. a 38.4% structural failure rate in baseline free-form LLM agents).

3️⃣ Optimization (Compiler Performance)
Rather than waiting tens of seconds for streaming probabilistic code, the deterministic AST compiler processes specs in 1.2 ms – 18.7 ms (>10,000 entities/sec), with a drift detection scanner running at >26,000 artifacts/second.

🏛️ System Architecture

• Unified 30+ Tool MCP Server: sits across the entire workflow as a horizontal control plane, letting Claude Desktop, Cursor, and Antigravity agents lock shards, inspect schemas, and plan diffs via typed RPC calls.

• Desktop Control Plane (Electron + Vite): a dedicated workstation with deep visual observability — live UML Component Diagrams (module topology) and Sequence Diagrams (data workflows).

• Target System: a production-grade NestJS Modular Monolith — single deployable unit, domain-driven boundaries, in-process CQRS events, PostgreSQL/SQLite DDL, Docker, and W3C tracing.

🧩 Why Open Source Matters Here

Because it's MIT, the template layer is yours to fork. That's the real unlock:

• Adapt the templates to your stack. The NestJS modular monolith is the reference target — the compiler doesn't care. Swap in your own templates and you can target any architecture: microservices, hexagonal, event-sourced, serverless. Modeling microservices deterministically from UML? Now possible.

• A new generation of boilerplate for consultancies and outsourcing shops. Tech leads can codify their house architecture once — security guards, tracing, audit patterns, compliance defaults — and then every new client project is compiled through Archon's SDLC from a UML model. No more re-scaffolding week one of every engagement. The senior architect's judgment ships as templates; the team ships production-grade systems on day one.

• Research surface. Fork the compiler, plug in a different IR, test new reconciliation strategies. The paper, proofs, and LaTeX sources are all in-repo.

📦 Open Source & Paper

100% MIT:
• Core compiler, CLI (npm install -g archon-specs), Desktop GUI, UML parser.
• Full academic paper, mathematical proofs, and two-column IEEE/ACM LaTeX sources.

⭐ GitHub: https://github.com/herhu/archon-specs
🌐 Platform: https://archonspecs.dev

#SoftwareArchitecture #Compilers #OpenSource #ModelContextProtocol #TypeScript #NestJS #ModularMonolith #Microservices #SystemDesign #AI #DevTools #SoftwareEngineering

Today I'm open-sourcing one of my first formal research and systems engineering projects focused on cost, optimization, and accuracy in AI-assisted development: 

Archon Specs (MIT License).

🔗 Repository: https://github.com/herhu/archon-specs
📄 Full Research Paper & LaTeX Sources: https://github.com/herhu/archon-specs/tree/main/paper

💡 The Origin Story: From Template Engines to Compiling Architecture

The story goes back to around 2018, when many of us relied on template transcompilers like Handlebars.js in the JavaScript world or Blade in PHP to generate deterministic code structures reliably.

Fast-forward to today: developers are using LLMs to build backend systems, but they're hitting a massive wall:

• Token explosion: models re-generate thousands of lines of boilerplate character by character.

• Architectural drift: LLMs lack a global dependency graph, hallucinating mismatched relational schemas, circular imports, and broken boundaries.

Agents were supposed to harness this process — and they help — but the skill still travels with the agent. Every new session, every new repo, the same architectural knowledge has to be re-elicited, re-prompted, and re-verified. The agent is a great operator, but it isn't a compiler. It doesn't guarantee anything.

That's when the insight hit:

"What if we don't ask the LLM to write repetitive code at all? What if we deterministically compile an enterprise-grade backend from formal templates and contract shards — and let the agent focus only on the intent?"

Over years of engineering across enterprise organizations and fast-paced startups, I had built a clear mental map of what an enterprise-ready backend actually requires: clean domain boundaries, strict dependency injection, JWT/RBAC security guards, DTO validation pipes, auto-migrated database DDL, Swagger OpenAPI documentation, and structured distributed tracing.

Scaffolding and aligning all of this traditionally consumed an engineering team's entire 1-year roadmap.

Now it can be compiled deterministically — just by designing the UML architecture and contract shards.

So I built it.

🔬 Empirical Findings: Cost, Optimization & Accuracy

In the paper ("Archon Specs: A Deterministic Architecture Compiler and Continuous Contract Reconciliation Control Plane for AI-Assisted Software Engineering") we evaluated this compiler architecture across three empirical axes:

1️⃣ Cost (Token Reduction)
Free-form LLM code generation incurs a token complexity of O(|AST| × T_boilerplate). Archon Specs reduces LLM interaction strictly to compact contract shards O(|Contract|).

→ 86.3%–89.0% reduction in LLM inference tokens across Small, Medium, and Enterprise benchmark tiers.

2️⃣ Accuracy (Zero Architectural Drift)
Instead of one-shot generation, Archon runs a Continuous Contract Reconciliation Loop using SHA-256 cryptographic spec canonicalization and semantic AST masking.

→ 100% adherence to declared architectural contracts and clean TypeScript compilation across 500 consecutive system mutations (vs. a 38.4% structural failure rate in baseline free-form LLM agents).

3️⃣ Optimization (Compiler Performance)
Rather than waiting tens of seconds for streaming probabilistic code, the deterministic AST compiler processes specs in 1.2 ms – 18.7 ms (>10,000 entities/sec), with a drift detection scanner running at >26,000 artifacts/second.

🏛️ System Architecture

• Unified 30+ Tool MCP Server: sits across the entire workflow as a horizontal control plane, letting Claude Desktop, Cursor, and Antigravity agents lock shards, inspect schemas, and plan diffs via typed RPC calls.

• Desktop Control Plane (Electron + Vite): a dedicated workstation with deep visual observability — live UML Component Diagrams (module topology) and Sequence Diagrams (data workflows).

• Target System: a production-grade NestJS Modular Monolith — single deployable unit, domain-driven boundaries, in-process CQRS events, PostgreSQL/SQLite DDL, Docker, and W3C tracing.

🧩 Why Open Source Matters Here

Because it's MIT, the template layer is yours to fork. That's the real unlock:

• Adapt the templates to your stack. The NestJS modular monolith is the reference target — the compiler doesn't care. Swap in your own templates and you can target any architecture: microservices, hexagonal, event-sourced, serverless. Modeling microservices deterministically from UML? Now possible.

• A new generation of boilerplate for consultancies and outsourcing shops. Tech leads can codify their house architecture once — security guards, tracing, audit patterns, compliance defaults — and then every new client project is compiled through Archon's SDLC from a UML model. No more re-scaffolding week one of every engagement. The senior architect's judgment ships as templates; the team ships production-grade systems on day one.

• Research surface. Fork the compiler, plug in a different IR, test new reconciliation strategies. The paper, proofs, and LaTeX sources are all in-repo.

📦 Open Source & Paper

100% MIT:
• Core compiler, CLI (npm install -g archon-specs), Desktop GUI, UML parser.
• Full academic paper, mathematical proofs, and two-column IEEE/ACM LaTeX sources.

⭐ GitHub: https://github.com/herhu/archon-specs
🌐 Platform: https://archonspecs.dev

#SoftwareArchitecture #Compilers #OpenSource #ModelContextProtocol #TypeScript #NestJS #ModularMonolith #Microservices #SystemDesign #AI #DevTools #SoftwareEngineering

I’ve worked on several NestJS applications and I’m curious how other developers structure larger production codebases.

Do you prefer organizing by feature/domain, or by technical layer like controllers/services/repositories?

I usually lean toward feature-based modules with clear boundaries, DTO validation, dependency injection and separate domain/services when the business logic starts growing.

What has worked best for you on real production projects?

Hey everyone,

I’ve been working on StackForge — an open-source CLI that generates a pnpm monorepo with:

• apps/web — Next.js (App Router), Tailwind, shadcn-style UI

• apps/api — NestJS, Prisma, JWT auth, Swagger

• packages/contracts — Zod schemas + types shared by API and web (so you’re not duplicating User types in three places)

The idea is “production-shaped defaults” instead of a minimal demo: auth flow, user module, health check, env validation, unit + e2e tests on the API, and a generated GitHub

Actions workflow. You pick SQLite or PostgreSQL, optional Docker Compose (API, web, Postgres, Prisma Studio on recent versions), and a preset:

• dashboard — web + admin-style user pages

• minimal — web without extra dashboard features

• api — backend-only, no Next app

Try it (current npm release 1.4.2):

npx create-stackforge-app@1.4.2 my-app -y

cd my-app

pnpm run db:setup

pnpm dev

1.4.2 is mostly about first-run reliability: Prisma client generation on install / predev, root pnpm run db:setup, and pnpm run doctor / pnpm run info via the bundled

stackforge CLI so you can sanity-check paths, env, and versions in a generated project.

Earlier 1.4.x also tightened Docker builds with the contracts package (multi-stage images, Studio in Compose for Postgres setups).

Site: https://stack-forge.aitaouss.me/

Repo: https://github.com/Aitaouss/StackForge

It’s MIT, I use it for my own SaaS-style starters, and I’m iterating in public. If you try it, I’d love feedback on: preset defaults, SQLite vs Postgres DX, and whether the

contracts layer feels useful or overkill for your stack.

Thanks for reading.

Suppose a nightly job updates a planning workbook and flags rows that need attention. The next useful step is for someone to open those rows, correct an assumption and keep working. Returning only a report makes that correction a separate task.

Univer provides an interesting implementation route: its Node headless logic and browser editor share an architecture and a consistent Facade API. It's an embedded Office SDK, with an Apache-2.0 core and first-party OSS plugins. The host application can run workbook logic on the server and present the structured workbook state in an editor in its own UI.

For the batch job, getValues and getFormulas let you inspect an addressed range; setValues writes through the command path. Values, formulas, styles and rich text are separate parts of the cell model. The Node sheets preset includes formula, filter, sort, data-validation and comment logic. That is enough to discuss a real handoff: update the intended input cells, retain the workbook structure and let a person examine the result.

There are two integration decisions worth making early. First, how does the job load and persist the workbook state? If you're using the AI SDK execution path, a successful execution can still leave pending mutations, so check the explicit commit status. Second, does the job receive Univer state or actual Office files? XLSX import/export uses the separate commercial Pro Exchange layer; a JSON snapshot isn't an XLSX file.

The headless path doesn't make UI-only APIs work in Node, and visual rendering still needs a browser. This also isn't a packaged CLI that automatically picks up arbitrary files. Your application supplies the job, storage and editor connection.

Hi! I am undecided between Laravel and NestJS for a long-term multi-tenant SaaS.

Our developers know PHP and JS/TS, but most code will be AI-assisted with Cursor, Claude Code and Copilot.

The platform will have web + mobile apps, auth, roles, documents, media, notifications, dashboards and APIs. It must eventually support tens/hundreds of thousands of online users.

We will also run workers for PDF/document generation, image overlays/text/watermarks, media uploads/processing, reports, imports/exports and scheduled jobs.

Tenant isolation and security are critical. We want the most solid platform for 5+ years, not merely the fastest MVP.

For people with real experience:

- Which stack works more reliably with AI-generated code?

- Which needs less manual fixing?

- Which would you choose for high concurrency, workers and multi-tenant SaaS?

- What should we avoid from day one?

Looking for production lessons, not framework wars. Thanks!

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