Forem: Diego Liascovich

🛠️ Advanced Node.js Debugging: Beyond console.log

Diego Liascovich — Thu, 10 Jul 2025 12:43:58 +0000

By Diego Liascovich

Full-Stack Developer | Microservices | Angular | Node.js

In this post, we’ll explore powerful, professional ways to debug Node.js applications, step by step — and all without relying on console.log.

🧠 Why You Should Ditch `console.log`

Clutters code
Slows performance
Doesn't pause execution
Not useful for complex stack traces or state inspection

🔍 1. The `debugger` Statement

Place debugger; in your Node.js code:

function calculateTotal(items) {
  const total = items.reduce((sum, item) => sum + item.price, 0);
  debugger; // Execution will pause here
  return total;
}

Then run your app with:

node inspect index.js

This opens the built-in debugger in the terminal.

🧪 2. Chrome DevTools + `--inspect`

Use the V8 inspector in Chrome to debug with a GUI:

Step 1: Add `debugger` to your code

debugger;

Step 2: Run with `--inspect`

node --inspect index.js

Step 3: Open Chrome and go to:

chrome://inspect

Click “Open dedicated DevTools for Node” and you’ll see a full debugger just like front-end JS debugging.

🖥️ 3. Debugging with VSCode (Recommended)

VSCode provides the most comfortable experience.

Step 1: Add `.vscode/launch.json`

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Debug My App",
      "program": "${workspaceFolder}/index.js"
    }
  ]
}

Step 2: Add breakpoints

Click in the gutter of VSCode next to the lines you want to inspect.

Step 3: Press `F5` to start debugging

You’ll get:

Call stack
Watches
Scope
Live variable inspection

🧭 4. Remote Debugging

Useful when debugging apps running inside Docker or in the cloud.

Run Node.js with:

node --inspect=0.0.0.0:9229 index.js

Then from your local machine:

Open chrome://inspect
Add the remote target (IP:9229)

Make sure the port is exposed and secured! Never expose --inspect in production without IP restriction.

🔁 5. Using `ndb`: GUI Debugging Made Easy

ndb is a standalone debugger from the Chrome team.

npm install -g ndb
ndb index.js

You’ll get:

Source-mapped debugging
Breakpoints
Heap snapshots
Console context

🧰 6. Smart Logging with `debug`

Instead of polluting your app with console.log, use the debug library:

npm install debug

const debug = require('debug')('app:init');
debug('Initializing app...');

Enable output with:

DEBUG=app:* node index.js

You can turn logs on/off per namespace (app:*, db:*, etc.).

🧪 7. Debugging Tests

If you’re testing with Jest, Mocha, or Vitest:

node --inspect-brk ./node_modules/.bin/jest tests/example.spec.js

Or with TypeScript:

node --inspect-brk -r ts-node/register src/index.ts

Then attach Chrome or VSCode.

🧼 Summary: Debug Like a Pro

Tool	Use Case	GUI	Breakpoints	Live Vars
`inspect`	Built-in debugger	❌	✅	🟡 Console only
DevTools	Full browser debugger	✅	✅	✅
VSCode	IDE-native debugging	✅	✅	✅
`ndb`	Lightweight GUI	✅	✅	✅
`debug`	Clean runtime logging	❌	❌	✅ (logs)

💡 Pro Tips

Use debugger; instead of console.log to stop and inspect.
Prefer debug or winston over console.log in production.
Always use .vscode/launch.json for repeatable debugging.

🔐 Secure Web Application Flow with JWT: From Frontend to Backend

Diego Liascovich — Thu, 10 Jul 2025 12:41:54 +0000

By Diego Liascovich

Full-Stack Developer | Microservices | Angular | Node.js

Modern web applications rely heavily on JSON Web Tokens (JWT) for stateless authentication and secure communication between the frontend and backend.

In this article, we’ll explore the step-by-step security flow using JWT, from the moment a user logs in to the backend verifying their access, including refresh token strategies and best practices.

🔑 1. User Login Request

The user enters their credentials on the frontend (e.g., Angular, React).

The frontend sends a POST /login request to the backend:

POST /login
{
  "email": "user@example.com",
  "password": "123456"
}

🧠 2. Backend Authenticates and Issues JWT

Backend validates credentials.
If valid, it generates a signed JWT (e.g. using HMAC SHA-256).
Optional: also returns a refresh token.

{
  "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "refreshToken": "..." (optional)
}

JWT contains non-sensitive info like userId, role, exp.

📦 3. Frontend Stores the Token

Options:

localStorage or sessionStorage (easier, but vulnerable to XSS)
HttpOnly Secure Cookie (safer against XSS)

✅ Recommended: Use cookies with HttpOnly, Secure, and SameSite=Strict when possible.

🔐 4. Accessing Protected Resources

The frontend includes the accessToken in the Authorization header:

GET /orders
Authorization: Bearer <access_token>

🔎 5. Backend Verifies JWT

Steps the backend performs:

Extracts token from Authorization header.
Verifies the signature using the secret.
Checks exp and optional claims like role.

If valid → user is authorized.

If invalid/expired → responds with 401 Unauthorized.

🔁 6. Refreshing the Token (Optional)

If the accessToken is expired, the frontend can request a new one using the refreshToken:

POST /refresh-token
Authorization: Bearer <refresh_token>

The backend verifies the refresh token and responds with a new accessToken.

🚪 7. Logout Flow

Frontend clears the token from storage.

If using cookies: optionally hit a /logout endpoint to invalidate the refresh token on the server.

📦 Example JWT Payload

{
  "sub": "user_123",
  "email": "user@example.com",
  "role": "admin",
  "iat": 1721234567,
  "exp": 1721242167
}

✅ Best Practices

✅ Use HTTPS always.
✅ Use short accessToken lifespan (5–15 mins).
✅ Sign tokens securely (HS256, RS256).
✅ Store tokens safely (prefer HttpOnly cookies).
✅ Validate tokens on every request.

🧭 Summary

JWT enables secure, stateless authentication — but only if implemented correctly.

From login to logout, your frontend and backend should follow a strict protocol for storing, sending, and validating tokens. When done right, JWTs make modern apps both user-friendly and secure. 🔐

Let me know if you'd like to see full implementation examples in Angular and Node.js!

Building a Clean gRPC API in Node.js

Diego Liascovich — Wed, 09 Jul 2025 10:12:23 +0000

By Diego Liascovich

Full-Stack Developer | Microservices | Angular | Node.js

gRPC is a high-performance, language-agnostic RPC framework developed by Google. It allows different services or applications—possibly written in different languages—to communicate through well-defined contracts using Protocol Buffers.

In this post, we'll cover:

What gRPC is and how it works
Why it's useful in modern backend architectures
How to implement a simple BookService API using Node.js, gRPC, Docker, and Clean Architecture principles

🚀 What Is gRPC?

gRPC stands for gRPC Remote Procedure Calls. It uses HTTP/2 for transport, Protocol Buffers (protobuf) as the interface definition language, and supports multiple languages.

🧱 Components of gRPC

.proto file: Defines services and message schemas
Server: Implements service logic
Client: Invokes remote methods
Protocol Buffers: Efficient binary serialization format

⚙️ Why Use gRPC?

✅ Strongly-typed messages (via Protobuf)
✅ Efficient binary communication
✅ Multi-language support (Node, Go, Java, Python, etc.)
✅ Streaming support (client/server/bidirectional)
✅ Ideal for microservices in internal networks

📘 Our Use Case: Book Service

We’ll build a simple BookService API with two RPC methods:

GetBook(id): returns a book by ID
ListBooks(): returns all books

All data will be mocked in memory, simulating a database.

🗂️ Project Structure

grpc-books/
├── proto/
│   └── book.proto
├── proto-loader.js
├── src/
│   ├── application/
│   │   └── bookService.js
│   ├── domain/
│   │   └── book.js
│   ├── infrastructure/
│   │   └── bookRepository.js
│   ├── interfaces/
│   │   └── grpc/
│   │       └── bookHandler.js
│   └── server.js
├── Dockerfile
├── docker-compose.yml
└── package.json

📄 book.proto

syntax = "proto3";

package books;

service BookService {
  rpc GetBook (GetBookRequest) returns (Book);
  rpc ListBooks (Empty) returns (BookList);
}

message GetBookRequest {
  string id = 1;
}

message Empty {}

message Book {
  string id = 1;
  string title = 2;
  string author = 3;
  int32 year = 4;
}

message BookList {
  repeated Book books = 1;
}

🧠 Domain: Book Entity

// src/domain/book.js
class Book {
  constructor(id, title, author, year) {
    this.id = id;
    this.title = title;
    this.author = author;
    this.year = year;
  }
}
module.exports = Book;

🏗️ Infrastructure: Mock Repository

// src/infrastructure/bookRepository.js
const Book = require('../domain/book');

const books = [
  new Book('1', '1984', 'George Orwell', 1949),
  new Book('2', 'The Hobbit', 'J.R.R. Tolkien', 1937),
  new Book('3', 'Clean Code', 'Robert C. Martin', 2008),
];

class BookRepository {
  findById(id) {
    return books.find(b => b.id === id);
  }

  findAll() {
    return books;
  }
}

module.exports = new BookRepository();

💼 Application: Book Service

// src/application/bookService.js
const bookRepo = require('../infrastructure/bookRepository');

class BookService {
  getBook(id) {
    const book = bookRepo.findById(id);
    if (!book) throw new Error('Book not found');
    return book;
  }

  listBooks() {
    return bookRepo.findAll();
  }
}
module.exports = new BookService();

🔌 Interface: gRPC Handler

// src/interfaces/grpc/bookHandler.js
const bookService = require('../../application/bookService');

function GetBook(call, callback) {
  try {
    const book = bookService.getBook(call.request.id);
    callback(null, book);
  } catch (err) {
    callback({ code: 5, message: err.message }); // NOT_FOUND
  }
}

function ListBooks(call, callback) {
  const books = bookService.listBooks();
  callback(null, { books });
}

module.exports = { GetBook, ListBooks };

📦 Proto Loader

// proto-loader.js
const path = require('path');
const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');

const PROTO_PATH = path.join(__dirname, 'proto', 'book.proto');

const packageDefinition = protoLoader.loadSync(PROTO_PATH, {
  keepCase: true,
  longs: String,
  enums: String,
  defaults: true,
  oneofs: true,
});

module.exports = grpc.loadPackageDefinition(packageDefinition).books;

🖥️ Server

// src/server.js
const grpc = require('@grpc/grpc-js');
const proto = require('../proto-loader');
const bookHandler = require('./interfaces/grpc/bookHandler');

function main() {
  const server = new grpc.Server();
  server.addService(proto.BookService.service, {
    GetBook: bookHandler.GetBook,
    ListBooks: bookHandler.ListBooks,
  });

  const address = '0.0.0.0:50051';
  server.bindAsync(address, grpc.ServerCredentials.createInsecure(), () => {
    console.log(`🚀 gRPC server running at ${address}`);
    server.start();
  });
}

main();

🐳 Docker Setup

Dockerfile

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 50051
CMD ["npm", "start"]

docker-compose.yml

version: "3.9"

services:
  grpc-books:
    build: .
    ports:
      - "50051:50051"

🧪 Testing with BloomRPC

Open BloomRPC.
Load the book.proto file.
Set server to localhost:50051.
Use:
- GetBook → payload: { "id": "1" }
- ListBooks → payload: {}

📁 Source Code

👉 View the full repository here

🏗️ Real-World Backend Architecture Patterns You Should Know

Diego Liascovich — Tue, 08 Jul 2025 17:49:39 +0000

By Diego Liascovich

Full-Stack Developer | Microservices | Angular | Node.js

title: "📐 20+ Essential Architecture Patterns for Scalable Systems"
published: true
description: "A deep dive into core software architecture patterns including CQRS, Saga, Event Sourcing, Sidecar, BFF, Circuit Breaker, Canary Releases, and more — with real-world examples."

tags: architecture, backend, microservices, devops, scalability

In modern system design, there’s no one-size-fits-all solution. Choosing the right architecture and deployment patterns is essential for building scalable, resilient, and maintainable systems.

This guide explores 20+ key patterns, including structural, behavioral, and DevOps practices — each with real-world use cases, pros, and cons.

🧱 1. Sidecar Pattern

Type: Infrastructure

Description: A helper process runs alongside your main service, typically in the same pod or VM. Handles logging, proxying, config updates.

When to Use: You want to separate cross-cutting concerns (like TLS or logging) from business logic.

✅ Benefits: Language agnostic, modular, enhances observability

❌ Drawbacks: Resource overhead, complex orchestration

💡 Example: Envoy proxy sidecar in Istio (service mesh)

🔁 2. Saga Pattern

Type: Transaction Management

Description: Breaks distributed transactions into local ones, each with compensating logic for rollback.

When to Use: Long-running workflows involving multiple services

✅ Benefits: Maintains eventual consistency, decouples services

❌ Drawbacks: Complex rollback logic, debugging challenges

💡 Example: Order → Inventory → Payment → Cancel on failure

📤 3. Outbox Pattern

Type: Reliable Messaging

Description: Events are written to a DB outbox table in the same transaction as business data, then published asynchronously.

When to Use: When you need reliable event publishing tied to DB operations

✅ Benefits: Avoids lost events, strong consistency

❌ Drawbacks: Requires polling/CDC, delays in event delivery

💡 Example: Store order in DB → insert event → publish to Kafka

🧠 4. CQRS

Type: Data Modeling

Description: Separates command (write) and query (read) models for better scalability and complexity management.

When to Use: Apps with complex reads/writes or audit requirements

✅ Benefits: Optimized performance, flexibility, read model scaling

❌ Drawbacks: Complexity, event syncing challenges

💡 Example: Write to PostgreSQL, read from Redis or Mongo projection

🔀 5. Scatter-Gather

Type: Data Aggregation

Description: Sends requests in parallel to multiple sources, gathers and combines responses.

When to Use: You need data from multiple systems simultaneously

✅ Benefits: High performance, real-time aggregation

❌ Drawbacks: Timeout management, inconsistent failures

💡 Example: Flight search: query 5 airlines in parallel

🎼 6. Choreography Pattern

Type: Workflow Coordination

Description: Services react to events without centralized control — event-driven flow.

When to Use: Loose coupling, microservices autonomy

✅ Benefits: Flexible, scalable, no central dependency

❌ Drawbacks: Difficult traceability, uncontrolled event flow

💡 Example: UserSignedUp → EmailService & CRMService

🧑‍✈️ 7. Orchestrator Pattern

Type: Workflow Management

Description: A central orchestrator invokes services step by step and controls the workflow.

When to Use: When visibility and central control are needed

✅ Benefits: Traceability, error handling, flow visibility

❌ Drawbacks: Central point of failure, increased coupling

💡 Example: OrderService calls Inventory → Billing → Notifications

🔄 8. Pipes and Filters

Type: Stream/Data Processing

Description: Data flows through a pipeline, where each filter transforms it.

When to Use: ETL, image/audio processing, or data streams

✅ Benefits: Modular, testable components

❌ Drawbacks: Debugging and latency buildup

💡 Example: ETL: Extract → Clean → Normalize → Store

🕒 9. Event Sourcing

Type: State Management

Description: Store all events instead of the current state. Rebuild state by replaying events.

When to Use: You need full audit history or rollback

✅ Benefits: Full traceability, undo/redo, time-travel queries

❌ Drawbacks: Hard to query, event versioning

💡 Example: Account balance rebuilt from: Deposited, Withdrawn events

🌐 10. Ambassador Pattern

Type: Network Proxy

Description: A sidecar proxy handles outbound/inbound communication, authentication, TLS, etc.

When to Use: For consistent service communication and observability

✅ Benefits: Decouples app from infra, adds resilience

❌ Drawbacks: Extra network hop, resource usage

💡 Example: Envoy sidecar for outbound requests with retries

🧩 11. Backend for Frontend (BFF)

Type: API Gateway Pattern

Description: Each client (mobile/web) has a tailored backend optimized for its needs.

When to Use: When different clients need different formats or aggregations

✅ Benefits: Faster, cleaner frontends; avoids overfetching

❌ Drawbacks: More backend services to maintain

💡 Example: Mobile BFF combines user, cart, and product APIs

⚡ 12. Circuit Breaker

Type: Resilience/Fault Tolerance

Description: If a service fails too often, calls to it are stopped temporarily.

When to Use: Unstable external dependencies

✅ Benefits: Prevents cascading failure, protects resources

❌ Drawbacks: Adds complexity and tuning challenges

💡 Example: Use opossum or resilience4j to wrap outbound calls

🚀 13. Rolling Deployment

Type: Deployment Strategy

Description: Gradually replace old app versions with new ones without downtime.

When to Use: Production updates with low risk

✅ Benefits: Zero-downtime

❌ Drawbacks: Rollback may be partial or slower

💡 Example: Kubernetes rolling updates

💚 14. Blue-Green Deployment

Type: Deployment Strategy

Description: Deploy to a staging environment (green), test, then switch live traffic from blue.

When to Use: For safe, instant rollback

✅ Benefits: Fast recovery, easy switch

❌ Drawbacks: Requires double infrastructure

💡 Example: Switch load balancer to green environment after test pass

🐤 15. Canary Release

Type: Progressive Delivery

Description: Roll out new code to a small segment of users first.

When to Use: To test changes in production with low risk

✅ Benefits: Real user feedback, safer deployment

❌ Drawbacks: Monitoring and traffic routing complexity

💡 Example: Deploy to 5% of traffic, monitor, then expand

💥 16. Chaos Engineering

Type: Resilience Testing

Description: Intentionally introduce failures to test system response.

When to Use: To proactively test fault tolerance

✅ Benefits: Reveals hidden risks, improves recovery

❌ Drawbacks: Requires safeguards; risky in prod

💡 Example: Netflix’s Chaos Monkey kills instances randomly

🔁 17. Retry Pattern

Type: Fault Tolerance

Description: Retry transient failures, often with exponential backoff

When to Use: For flaky or unstable services

✅ Benefits: Handles temporary glitches

❌ Drawbacks: Retry storms, latency buildup

💡 Example: Retry payment API call 3 times with backoff

🪦 18. Dead Letter Queue (DLQ)

Type: Messaging Reliability

Description: Failed messages are sent to a DLQ for later analysis or reprocessing

When to Use: When you can’t afford message loss

✅ Benefits: Ensures recoverability

❌ Drawbacks: Requires monitoring and cleanup logic

💡 Example: Unprocessable Kafka/RabbitMQ messages redirected to DLQ

🚦 19. Throttling

Type: API Protection

Description: Controls the rate of operations per user/requester

When to Use: Prevent resource exhaustion or DoS abuse

✅ Benefits: Maintains system stability

❌ Drawbacks: Can degrade user experience

💡 Example: 5 requests per second per IP

⏱️ 20. Rate Limiting

Type: Usage Control

Description: Set hard request caps over time windows

When to Use: Prevent DDoS or ensure fair usage

✅ Benefits: Avoid abuse, preserve performance

❌ Drawbacks: Legit users might be blocked

💡 Example: 1000 requests/hour API key limit

📊 Comparison Table of Architecture Patterns

Pattern	Type	Main Benefits	Main Drawbacks
Sidecar	Infrastructure	Modularity, language agnostic	Extra resources, operational complexity
Saga	Transaction	Eventual consistency, decoupling	Complex rollback, debugging
Outbox	Reliable Messaging	Guarantees event delivery	Requires polling or CDC
CQRS	Data Modeling	Scalability, performance	Increased complexity
Scatter-Gather	Data Aggregation	Parallelism, speed	Timeout and failure handling
Choreography	Workflow	Loose coupling, extensible	Hard to trace
Orchestrator	Workflow	Centralized control, traceable	Single point of failure
Pipes and Filters	Data Processing	Modular, testable	Latency, debugging difficulty
Event Sourcing	State Management	Full audit trail	Query complexity, event versioning
Ambassador	Proxy	Decouples networking logic	Adds network hop
Backend for Frontend	API Composition	Optimized UX	More services to maintain
Circuit Breaker	Fault Tolerance	Prevents cascading failures	Configuration complexity
Rolling Deployment	Deployment	Zero downtime	Slow rollback
Blue-Green Deployment	Deployment	Instant rollback	Double resource use
Canary Release	Deployment	Safer releases	Complex traffic routing
Chaos Engineering	Resilience Testing	Improves robustness	Risky without safeguards
Retry Pattern	Fault Tolerance	Handles transient failures	Potential retry storms
Dead Letter Queue	Messaging	Prevents data loss	Requires manual handling
Throttling	Rate Control	Protects backend	May degrade user experience
Rate Limiting	Rate Control	Fair usage

📘 Final Thoughts

Architecture is all about tradeoffs. The right pattern depends on your scale, goals, and team structure.

Implementing the Repository Pattern with Mongoose in Node.js

Diego Liascovich — Tue, 08 Jul 2025 17:47:58 +0000

By Diego Liascovich

Full-Stack Developer | Microservices | Angular | Node.js

The Repository Pattern serves as an intermediary between your application's business logic and the persistence layer (like MongoDB, PostgreSQL, etc.). This abstraction makes your application:

Decoupled from the data source
Easier to test (you can mock the repository)
More maintainable and flexible

🧾 Real Case: User Management with MongoDB and Mongoose

We will use TypeScript with Node.js and Mongoose to implement the pattern.

📁 Project Structure

src/
├── domain/
│   ├── models/
│   │   └── user.entity.ts
│   └── repositories/
│       └── user.repository.interface.ts
├── infrastructure/
│   ├── models/
│   │   └── user.model.ts
│   └── repositories/
│       └── user.repository.ts
├── application/
│   └── services/
│       └── user.service.ts
└── main.ts

1. `user.entity.ts` – Domain Entity

export interface User {
  id: string;
  name: string;
  email: string;
  createdAt: Date;
}

2. `user.repository.interface.ts` – Repository Interface

import { User } from '../models/user.entity';

export interface IUserRepository {
  findById(id: string): Promise<User | null>;
  findAll(): Promise<User[]>;
  create(user: Omit<User, 'id' | 'createdAt'>): Promise<User>;
  delete(id: string): Promise<boolean>;
}

3. `user.model.ts` – Mongoose Schema and Model

import mongoose, { Schema } from 'mongoose';

const UserSchema = new Schema({
  name: String,
  email: String,
  createdAt: { type: Date, default: Date.now }
});

export const UserModel = mongoose.model('User', UserSchema);

4. `user.repository.ts` – Mongoose Implementation

import { IUserRepository } from '../../domain/repositories/user.repository.interface';
import { User } from '../../domain/models/user.entity';
import { UserModel } from '../models/user.model';

export class UserRepository implements IUserRepository {
  async findById(id: string): Promise<User | null> {
    return await UserModel.findById(id).lean();
  }

  async findAll(): Promise<User[]> {
    return await UserModel.find().lean();
  }

  async create(data: Omit<User, 'id' | 'createdAt'>): Promise<User> {
    const created = new UserModel(data);
    const saved = await created.save();
    return saved.toObject();
  }

  async delete(id: string): Promise<boolean> {
    const result = await UserModel.findByIdAndDelete(id);
    return !!result;
  }
}

5. `user.service.ts` – Business Logic

import { IUserRepository } from '../../domain/repositories/user.repository.interface';
import { User } from '../../domain/models/user.entity';

export class UserService {
  constructor(private readonly userRepo: IUserRepository) {}

  async listUsers(): Promise<User[]> {
    return await this.userRepo.findAll();
  }

  async registerUser(name: string, email: string): Promise<User> {
    return await this.userRepo.create({ name, email });
  }
}

6. `main.ts` – Example Usage

import mongoose from 'mongoose';
import { UserRepository } from './infrastructure/repositories/user.repository';
import { UserService } from './application/services/user.service';

(async () => {
  await mongoose.connect('mongodb://localhost:27017/repository-example');

  const userRepo = new UserRepository();
  const userService = new UserService(userRepo);

  const newUser = await userService.registerUser('Padie78', 'Padie78@example.com');
  console.log('User created:', newUser);

  const allUsers = await userService.listUsers();
  console.log('All users:', allUsers);
})();

✅ Benefits of This Architecture

Decoupling: You can easily switch the database or mock the repository.
Unit Testing: You can mock IUserRepository in your tests.
Flexibility: Your business logic is not tied to any specific DB implementation.

Most Common Communication Errors Between Frontend and Backend

Diego Liascovich — Tue, 08 Jul 2025 17:31:59 +0000

By Diego Liascovich

Full-Stack Developer | Microservices | Angular | Node.js

Effective communication between frontend and backend is essential for building robust and scalable applications. Yet, it's common for mismatches and misunderstandings to arise, causing bugs, delays, and poor user experience.

In this post, we'll explore the most frequent communication errors between frontend and backend teams (or codebases), and how to avoid them.

🔁 1. API Contract Mismatches

🔸 Structure Differences

The frontend expects a certain shape of data, but the backend sends something else.

Example:

// Frontend expects:
{ "username": "john_doe" }
// Backend sends:
{ "user_name": "john_doe" }

🔸 Missing or Outdated Documentation

APIs without reliable documentation lead to incorrect usage.

🔸 No Versioning

Backend changes an API response or behavior without versioning, breaking frontend compatibility.

🕒 2. Timing and Async Handling Errors

🔸 Timeouts

The backend takes too long to respond, and the frontend doesn't handle the timeout gracefully.

🔸 Race Conditions

Multiple simultaneous requests lead to inconsistent UI or state because their order isn't controlled.

🚫 3. Validation and Error Handling

🔸 Inconsistent Error Formats

Backend responses vary or don't use proper HTTP status codes.

Bad Practice:
Returning 200 OK with an error in the response body.

🔸 Weak or Conflicting Validation

Missing validation in frontend or backend.
Validation rules differ on both sides (e.g., regex for emails).

🔐 4. Authentication & Authorization Errors

🔸 Unhandled Token Expiration

Frontend doesn’t detect when the token is expired (401 Unauthorized), and fails silently or behaves unpredictably.

🔸 Role Mismatches

Frontend allows actions that backend denies — or backend allows what frontend should restrict.

📦 5. Data Format Issues

🔸 Date and Time Mismanagement

Timezone inconsistencies and formatting differences (ISO, UTC, etc.) can cause major bugs.

🔸 Incorrect Type Handling

Frontend sends a string, backend expects a number.

🔸 Array, `null`, or `undefined` Confusion

Inconsistent handling of optional or empty fields.

🔄 6. HTTP Method and Status Code Misuse

🔸 Wrong HTTP Verbs

Using GET for actions that should use POST, PUT, or DELETE.

🔸 Incorrect Status Codes

Returning 500 Internal Server Error for validation errors (should be 400 Bad Request).

🌍 7. CORS Issues

Cross-Origin Resource Sharing (CORS) misconfiguration can block frontend requests altogether.

🧪 8. Mocking vs Real Backend Discrepancies

🔸 Mocks Are Not Accurate

Frontend is built using mock data that doesn't match the real backend's behavior or structure.

🔸 Backend Doesn’t Test with Real Frontend

API changes may go unnoticed if not tested in full integration.

✅ How to Avoid These Issues

Use OpenAPI/Swagger for auto-generated and up-to-date documentation.
Validate inputs/outputs using tools like Zod, Joi, or class-validator.
Share types between frontend and backend (e.g. using tRPC, GraphQL, or codegen tools).
Version your APIs to avoid breaking changes.
Write integration tests that include both frontend and backend layers.
Communicate early between teams and document assumptions.

💬 Final Thoughts

Frontend-backend communication is like a contract — and like any contract, if it's not well-defined, it leads to conflict. By improving documentation, validation, and collaboration, you can reduce bugs and ship faster with confidence.

Managing Dynamic Behavior with the State Design Pattern in TypeScript

Diego Liascovich — Tue, 08 Jul 2025 17:25:48 +0000

By Diego Liascovich

Full-Stack Developer | Microservices | Angular | Node.js

📘 What is the State Design Pattern?

The State Pattern is a behavioral design pattern that lets an object alter its behavior when its internal state changes. The object will appear to change its class.

Rather than using conditionals, each state is encapsulated in a separate class. The object delegates behavior to the current state class.

🧱 Key Components

Context: Holds a reference to the current state and delegates operations.
State Interface: Defines the common interface for all states.
Concrete States: Represent different states with unique behavior.

💡 Real Case: Billing Invoice Lifecycle

A billing invoice can go through different states:

Created
Approved
Paid
Canceled

Each state defines what actions are valid. For example:

A Created invoice can be approved or canceled.
An Approved invoice can be paid or canceled.
A Paid invoice cannot be modified.
A Canceled invoice is read-only.

🛠️ TypeScript Implementation

1. State Interface

// BillingState.ts
export interface BillingState {
  approve(): void;
  pay(): void;
  cancel(): void;
}

2. Concrete States

// CreatedState.ts
import { BillingState } from './BillingState';
import { BillingContext } from './BillingContext';
import { ApprovedState } from './ApprovedState';
import { CanceledState } from './CanceledState';

export class CreatedState implements BillingState {
  constructor(private context: BillingContext) {}

  approve(): void {
    console.log("Invoice approved.");
    this.context.setState(new ApprovedState(this.context));
  }

  pay(): void {
    console.log("Cannot pay a created invoice.");
  }

  cancel(): void {
    console.log("Invoice canceled.");
    this.context.setState(new CanceledState(this.context));
  }
}

// ApprovedState.ts
import { BillingState } from './BillingState';
import { BillingContext } from './BillingContext';
import { PaidState } from './PaidState';
import { CanceledState } from './CanceledState';

export class ApprovedState implements BillingState {
  constructor(private context: BillingContext) {}

  approve(): void {
    console.log("Already approved.");
  }

  pay(): void {
    console.log("Invoice paid.");
    this.context.setState(new PaidState(this.context));
  }

  cancel(): void {
    console.log("Invoice canceled.");
    this.context.setState(new CanceledState(this.context));
  }
}

// PaidState.ts
import { BillingState } from './BillingState';

export class PaidState implements BillingState {
  approve(): void {
    console.log("Invoice already paid. Cannot approve.");
  }

  pay(): void {
    console.log("Invoice already paid.");
  }

  cancel(): void {
    console.log("Invoice already paid. Cannot cancel.");
  }
}

// CanceledState.ts
import { BillingState } from './BillingState';

export class CanceledState implements BillingState {
  approve(): void {
    console.log("Invoice is canceled. Cannot approve.");
  }

  pay(): void {
    console.log("Invoice is canceled. Cannot pay.");
  }

  cancel(): void {
    console.log("Invoice already canceled.");
  }
}

3. Context Class

// BillingContext.ts
import { BillingState } from './BillingState';
import { CreatedState } from './CreatedState';

export class BillingContext {
  private state: BillingState;

  constructor() {
    this.state = new CreatedState(this); // initial state
  }

  setState(state: BillingState) {
    this.state = state;
  }

  approve() {
    this.state.approve();
  }

  pay() {
    this.state.pay();
  }

  cancel() {
    this.state.cancel();
  }
}

✅ Demo Usage

const invoice = new BillingContext();

invoice.approve(); // "Invoice approved."
invoice.pay();     // "Invoice paid."
invoice.cancel();  // "Invoice already paid. Cannot cancel."

🎯 Benefits of Using the State Pattern for Billing

Enforces business rules via state logic.
Avoids complex conditionals.
Each state encapsulates its valid transitions and behavior.
Easy to extend with new states (e.g., "Refunded", "Disputed").

🧠 Implementing the Memento Pattern with a Stepper Form in Angular

Diego Liascovich — Tue, 08 Jul 2025 11:58:21 +0000

In this article, we’ll explore a real-world use case of the Memento Design Pattern using a multi-step form (stepper) in Angular. This pattern helps manage state across steps, allowing users to go back and forth while preserving previous data snapshots.

📘 What is the Memento Pattern?

The Memento Pattern is a behavioral design pattern that allows you to save and restore the previous state of an object without exposing its implementation details. It’s often used in scenarios like undo/redo, form state management, or editor history.

🧩 Components of the Memento Pattern

The pattern consists of three main components:

Originator: The object whose state needs to be saved and restored.
Memento: A snapshot of the Originator's state.
Caretaker: Manages and stores the history of Mementos but does not modify or access their internal state.

💡 Real Case: Stepper Form with Snapshot History

Imagine a multi-step checkout form (e.g., shipping info, payment details, confirmation). We want to:

Capture the form state after each step.
Allow the user to go back and edit previous steps.
Restore the state exactly as it was.

🛠️ Memento Implementation in Angular

1. Create the Memento Classes

// memento.ts
export class FormMemento {
  constructor(public readonly state: any) {}
}

export class FormOriginator {
  private state: any = {};

  setState(state: any) {
    this.state = { ...state };
  }

  save(): FormMemento {
    return new FormMemento(this.state);
  }

  restore(memento: FormMemento) {
    this.state = { ...memento.state };
  }

  getState(): any {
    return this.state;
  }
}

2. Caretaker Service to Store Snapshots

// memento.service.ts
import { Injectable } from '@angular/core';
import { FormMemento } from './memento';

@Injectable({ providedIn: 'root' })
export class MementoService {
  private history: FormMemento[] = [];

  addSnapshot(memento: FormMemento) {
    this.history.push(memento);
  }

  getSnapshot(step: number): FormMemento | null {
    return this.history[step] || null;
  }

  clear() {
    this.history = [];
  }
}

3. Stepper Component Example

// stepper.component.ts
import { Component } from '@angular/core';
import { FormBuilder, FormGroup } from '@angular/forms';
import { FormOriginator } from './memento';
import { MementoService } from './memento.service';

@Component({
  selector: 'app-stepper',
  templateUrl: './stepper.component.html'
})
export class StepperComponent {
  step = 0;
  form: FormGroup;
  originator = new FormOriginator();

  constructor(private fb: FormBuilder, private caretaker: MementoService) {
    this.form = this.fb.group({
      name: [''],
      address: [''],
      payment: ['']
    });
  }

  nextStep() {
    this.originator.setState(this.form.value);
    this.caretaker.addSnapshot(this.originator.save());
    this.step++;
  }

  previousStep() {
    this.step--;
    const snapshot = this.caretaker.getSnapshot(this.step);
    if (snapshot) {
      this.originator.restore(snapshot);
      this.form.setValue(this.originator.getState());
    }
  }

  submit() {
    console.log('Final state:', this.form.value);
  }
}

4. Template Example

<!-- stepper.component.html -->
<form [formGroup]="form">
  <div *ngIf="step === 0">
    <label>Name: <input formControlName="name" /></label>
  </div>

  <div *ngIf="step === 1">
    <label>Address: <input formControlName="address" /></label>
  </div>

  <div *ngIf="step === 2">
    <label>Payment: <input formControlName="payment" /></label>
  </div>

  <div class="buttons">
    <button type="button" (click)="previousStep()" [disabled]="step === 0">Back</button>
    <button type="button" (click)="nextStep()" *ngIf="step < 2">Next</button>
    <button type="submit" (click)="submit()" *ngIf="step === 2">Submit</button>
  </div>
</form>

✅ Benefits of This Approach

Maintains form state cleanly across steps.
Encapsulates logic for state saving/restoring.
Easy to extend (e.g., with undo/redo or validation snapshots).
Promotes separation of concerns via the Memento pattern components.

Robust API Input Validation with Joi in Express.js

Diego Liascovich — Tue, 08 Jul 2025 11:32:02 +0000

By Diego Liascovich

Full-Stack Developer | Microservices | Angular | Node.js

When building REST APIs in Node.js, validating user input is essential to ensure data integrity and application security. In this post, you'll learn how to use Joi to validate incoming requests in a real-world Express.js project.

🔧 What is Joi?

Joi is a powerful validation library for JavaScript. It allows you to create schemas to validate JavaScript objects, including request payloads.

📦 Project Setup

Install the required packages:

npm install express joi

Project structure:

project/
├── app.js
├── routes/
│   └── user.routes.js
├── validators/
│   └── user.validator.js

🧪 Example Use Case: User Registration

We want to validate this user object:

{
  "name": "John Doe",
  "email": "john@example.com",
  "password": "12345678"
}

📁 user.validator.js

// validators/user.validator.js
const Joi = require('joi');

const registerUserSchema = Joi.object({
  name: Joi.string().min(3).max(30).required(),
  email: Joi.string().email().required(),
  password: Joi.string().min(8).required()
});

module.exports = { registerUserSchema };

📁 user.routes.js

// routes/user.routes.js
const express = require('express');
const { registerUserSchema } = require('../validators/user.validator');
const router = express.Router();

router.post('/register', (req, res) => {
  const { error, value } = registerUserSchema.validate(req.body);

  if (error) {
    return res.status(400).json({ error: error.details[0].message });
  }

  // Simulate user creation
  res.status(201).json({ message: 'User registered successfully', data: value });
});

module.exports = router;

📁 app.js

// app.js
const express = require('express');
const userRoutes = require('./routes/user.routes');

const app = express();
app.use(express.json());
app.use('/api/users', userRoutes);

app.listen(3000, () => {
  console.log('Server running on http://localhost:3000');
});

🚀 Test the API

Use Postman or curl to POST to /api/users/register:

curl -X POST http://localhost:3000/api/users/register \
  -H "Content-Type: application/json" \
  -d '{"name":"John Doe", "email":"john@example.com", "password":"12345678"}'

✅ Summary

Joi helps enforce robust input validation in Express applications. With modular validators and clear error messages, it enhances both security and developer experience.

Simplifying Object Creation in TypeScript Using the Builder Pattern

Diego Liascovich — Tue, 08 Jul 2025 11:25:41 +0000

By Diego Liascovich

Full-Stack Developer | Microservices | Angular | Node.js

The Builder design pattern is useful when you need to construct complex objects step-by-step, especially when many optional parameters are involved.

Let’s walk through a real-world case: building a User object in a web application, where some fields are optional depending on context (e.g., user profile, registration, or admin creation).

🎯 Use Case

You're developing a web system where users can be created with various optional fields:

Name
Email
Address
Role
Preferences

Using a traditional constructor with multiple parameters would be messy. The Builder pattern makes this process much cleaner.

📦 `User.ts`

export class User {
  public name?: string;
  public email?: string;
  public address?: string;
  public role?: string;
  public preferences?: Record<string, any>;

  constructor(builder: UserBuilder) {
    this.name = builder.name;
    this.email = builder.email;
    this.address = builder.address;
    this.role = builder.role;
    this.preferences = builder.preferences;
  }
}

🧱 `UserBuilder.ts`

import { User } from './User';

export class UserBuilder {
  public name?: string;
  public email?: string;
  public address?: string;
  public role?: string;
  public preferences?: Record<string, any>;

  setName(name: string): UserBuilder {
    this.name = name;
    return this;
  }

  setEmail(email: string): UserBuilder {
    this.email = email;
    return this;
  }

  setAddress(address: string): UserBuilder {
    this.address = address;
    return this;
  }

  setRole(role: string): UserBuilder {
    this.role = role;
    return this;
  }

  setPreferences(preferences: Record<string, any>): UserBuilder {
    this.preferences = preferences;
    return this;
  }

  build(): User {
    return new User(this);
  }
}

✅ Example Usage

import { UserBuilder } from './UserBuilder';

const user = new UserBuilder()
  .setName('Alice Smith')
  .setEmail('alice@example.com')
  .setRole('admin')
  .setPreferences({ darkMode: true, language: 'en' })
  .build();

console.log(user);

💡 Benefits of Using Builder Here

✅ Readable and Fluent API: No need to deal with long parameter lists.
✅ Flexible: Create different configurations of the object easily.
✅ Safe and Scalable: Easy to extend as new fields are added.

🧠 Final Thoughts

The Builder pattern shines when you’re working with complex object creation that needs flexibility and clarity. It helps you keep your code clean and extensible — a great choice for constructing domain models in modern TypeScript applications.

🧬 Scalable Angular Architecture with Atomic Design and BEM

Diego Liascovich — Mon, 07 Jul 2025 13:46:46 +0000

By Diego Liascovich

Full-Stack Developer | Microservices | Angular | Node.js

When building large-scale Angular applications, having a clean, scalable, and maintainable architecture is key. This post explores how combining Atomic Design and BEM (Block Element Modifier) can help you build robust front-end systems with clear structure and styling consistency.

🚀 Why Architecture Matters in Angular

As your Angular project grows, so do:

The number of components.
The complexity of UI states.
The maintenance overhead.

A proper component and style structure can:

Avoid duplication.
Improve collaboration across teams.
Enhance testing and reusability.

🧪 What Is Atomic Design?

Atomic Design, coined by Brad Frost, is a methodology for creating design systems. It structures UI components into 5 levels:

Atoms – Basic elements (buttons, inputs, labels).
Molecules – Groups of atoms working together (input + label).
Organisms – Complex components (header, card, sidebar).
Templates – Page structures with dummy content.
Pages – Final views with real content and data.

This hierarchy promotes reusability, consistency, and scalability.

🎨 What Is BEM (Block Element Modifier)?

BEM is a CSS naming convention:

Block – The standalone entity (e.g., card)
Element – A part of the block (e.g., card__title)
Modifier – A variation of a block or element (e.g., card--primary)

Example:

<div class="card card--primary">
  <h3 class="card__title">Title</h3>
  <p class="card__content">Content</p>
</div>

It brings:

Predictable, non-conflicting class names
Easier style scoping and maintenance
Compatibility with component-based systems like Angular

🏗️ Project Structure in Angular with Atomic Design

Here’s a sample structure:

src/
├── app/
│   ├── core/                 # Services, guards, global logic
│   ├── shared/               # Reusable atomic components
│   │   ├── atoms/
│   │   ├── molecules/
│   │   ├── organisms/
│   │   ├── templates/
│   │   └── pages/
│   ├── features/             # Feature-specific modules
│   └── app.component.ts
├── assets/
│   └── styles/
│       ├── _variables.scss
│       ├── _mixins.scss
│       ├── _typography.scss
│       └── base.scss
└── index.html

Each component has its own folder:

molecules/
└── input-field/
    ├── input-field.component.ts
    ├── input-field.component.html
    ├── input-field.component.scss  <-- Follows BEM
    └── input-field.component.spec.ts

✅ Benefits of Atomic Design + BEM in Angular

Benefit	Description
🔁 Reusability	Atoms and molecules can be reused across many views.
🎯 Consistency	Design and naming are standardized.
🧼 Separation of Concerns	UI hierarchy is clear; styles are scoped.
🧪 Easier Testing	Smaller units = better unit tests.
📦 Scalability	Feature and UI growth is more manageable.
👥 Team Collaboration	Devs and designers can speak the same "component language".

⚠️ Potential Drawbacks

Issue	Mitigation
🧩 Overhead for small apps	Use only parts of Atomic Design as needed.
📂 More folders & files	Use index.ts files for cleaner imports.
📚 Learning curve for new devs	Add documentation and folder readme files.

🛠️ Tips for Working with Atomic + BEM

Stick to clear folder naming (atoms, organisms, etc.).
Use SCSS mixins and variables to unify styles.
Keep a component catalog to avoid duplicate creation.
Use Angular Standalone Components and Signals where it makes sense (Angular 15+).
Combine with Storybook for UI documentation.

📦 Conclusion

Combining Atomic Design with BEM in Angular gives you a powerful architectural base for large-scale applications. It promotes modularity, consistency, and long-term maintainability.

💬 What do you think?

Have you tried combining Atomic Design and BEM in your Angular projects? Share your thoughts, improvements, or questions in the comments!

🚀 How I Migrated an Angular App from RxJS Observables to Signals: Real Case Study

Diego Liascovich — Mon, 07 Jul 2025 13:34:03 +0000

By Diego Liascovich

Full-Stack Developer | Microservices | Angular | Node.js

In this post, I share how I migrated a real-world Angular application from heavy use of Observables and async pipes to the new reactive model based on signal() introduced in Angular 16+.

I walk through real decisions, code examples (before/after), and practical lessons learned.

🧠 Why Migrate from Observables to Signals?

RxJS is powerful, but can get overly complex with:

switchMap, combineLatest, Subject, unsubscribe, etc.
Harder debugging and lifecycle issues.
Performance pitfalls if subscriptions aren't handled properly.

With signals:

No need to manually subscribe or unsubscribe.
More predictable rendering.
Cleaner code and localized reactive state.

🏗️ Real App Context

A real Angular 15 app used for managing orders and invoices (orders, billings), using RxJS, was migrated to Angular 17.

It used BehaviorSubject, Observable, combineLatest, and async pipe extensively for data and UI state.

🔁 Before: RxJS-Based Code

// orders.service.ts
private ordersSubject = new BehaviorSubject<Order[]>([]);
orders$ = this.ordersSubject.asObservable();

loadOrders() {
  this.http.get<Order[]>('/api/orders')
    .subscribe(data => this.ordersSubject.next(data));
}

<!-- orders.component.html -->
<div *ngIf="orders$ | async as orders">
  <app-order *ngFor="let order of orders" [data]="order"></app-order>
</div>

✅ After: Signal-Based Code

// orders.service.ts
import { signal } from '@angular/core';

orders = signal<Order[]>([]);

loadOrders() {
  this.http.get<Order[]>('/api/orders')
    .subscribe(data => this.orders.set(data));
}

// orders.component.ts
readonly orders = this.ordersService.orders;

<!-- orders.component.html -->
<div *ngFor="let order of orders()">
  <app-order [data]="order"></app-order>
</div>

💡 Migrating Derived Logic (e.g., combineLatest)

Before:

// Combining filter and data
readonly filteredOrders$ = combineLatest([
  this.orders$,
  this.filter$
]).pipe(
  map(([orders, filter]) => orders.filter(order => order.status === filter))
);

After (with computed and signal):

readonly filter = signal('pending');

readonly filteredOrders = computed(() =>
  this.orders().filter(order => order.status === this.filter())
);

🔧 Important Considerations

🧹 No More Manual Subscriptions

With signal(), Angular handles lifecycle cleanup. No need for takeUntil, unsubscribe, or memory leak worries.

🔄 Mixing RxJS and Signals

To convert an Observable to a Signal:

readonly user$ = this.authService.user$;
readonly user = toSignal(this.user$, { initialValue: null });

To go the other way:

const user$ = fromSignal(this.user);

⚠️ When Not to Migrate (Yet)

Your app heavily depends on NgRx or RxJS-centric libs.
You have mature RxJS-based logic with full test coverage.
You're using Angular < 16.

🧭 Conclusion

Migrating to Signals allowed me to:

Simplify component code.
Eliminate manual subscriptions.
Improve app performance and readability.

You don’t need to migrate all at once. You can combine RxJS and Signals in the same app and migrate incrementally.

🙌 Enjoyed this?

If you're thinking of migrating your Angular app to Signals, I hope this post gives you some real insight and confidence.

Drop a comment if you have questions or want to share your experience!

Forem: Diego Liascovich

🛠️ Advanced Node.js Debugging: Beyond console.log

🧠 Why You Should Ditch console.log

🔍 1. The debugger Statement

🧪 2. Chrome DevTools + --inspect

Step 1: Add debugger to your code

Step 2: Run with --inspect

Step 3: Open Chrome and go to:

🖥️ 3. Debugging with VSCode (Recommended)

Step 1: Add .vscode/launch.json

Step 2: Add breakpoints

Step 3: Press F5 to start debugging

🧭 4. Remote Debugging

🔁 5. Using ndb: GUI Debugging Made Easy

🧰 6. Smart Logging with debug

🧪 7. Debugging Tests

🧼 Summary: Debug Like a Pro

💡 Pro Tips

🔐 Secure Web Application Flow with JWT: From Frontend to Backend

🔑 1. User Login Request

🧠 2. Backend Authenticates and Issues JWT

📦 3. Frontend Stores the Token

🔐 4. Accessing Protected Resources

🔎 5. Backend Verifies JWT

🔁 6. Refreshing the Token (Optional)

🚪 7. Logout Flow

📦 Example JWT Payload

✅ Best Practices

🧭 Summary

Building a Clean gRPC API in Node.js

🚀 What Is gRPC?

🧱 Components of gRPC

⚙️ Why Use gRPC?

📘 Our Use Case: Book Service

🗂️ Project Structure

📄 book.proto

🧠 Domain: Book Entity

🏗️ Infrastructure: Mock Repository

💼 Application: Book Service

🔌 Interface: gRPC Handler

📦 Proto Loader

🖥️ Server

🐳 Docker Setup

Dockerfile

docker-compose.yml

🧪 Testing with BloomRPC

📁 Source Code

🏗️ Real-World Backend Architecture Patterns You Should Know

tags: architecture, backend, microservices, devops, scalability

🧱 1. Sidecar Pattern

🔁 2. Saga Pattern

📤 3. Outbox Pattern

🧠 4. CQRS

🔀 5. Scatter-Gather

🎼 6. Choreography Pattern

🧑‍✈️ 7. Orchestrator Pattern

🔄 8. Pipes and Filters

🕒 9. Event Sourcing

🌐 10. Ambassador Pattern

🧩 11. Backend for Frontend (BFF)

⚡ 12. Circuit Breaker

🚀 13. Rolling Deployment

💚 14. Blue-Green Deployment

🐤 15. Canary Release

💥 16. Chaos Engineering

🔁 17. Retry Pattern

🪦 18. Dead Letter Queue (DLQ)

🚦 19. Throttling

⏱️ 20. Rate Limiting

📊 Comparison Table of Architecture Patterns

📘 Final Thoughts

Implementing the Repository Pattern with Mongoose in Node.js

🧾 Real Case: User Management with MongoDB and Mongoose

📁 Project Structure

1. user.entity.ts – Domain Entity

2. user.repository.interface.ts – Repository Interface

3. user.model.ts – Mongoose Schema and Model

4. user.repository.ts – Mongoose Implementation

5. user.service.ts – Business Logic

6. main.ts – Example Usage

🧠 Why You Should Ditch `console.log`

🔍 1. The `debugger` Statement

🧪 2. Chrome DevTools + `--inspect`

Step 1: Add `debugger` to your code

Step 2: Run with `--inspect`

Step 1: Add `.vscode/launch.json`

Step 3: Press `F5` to start debugging

🔁 5. Using `ndb`: GUI Debugging Made Easy

🧰 6. Smart Logging with `debug`

1. `user.entity.ts` – Domain Entity

2. `user.repository.interface.ts` – Repository Interface

3. `user.model.ts` – Mongoose Schema and Model

4. `user.repository.ts` – Mongoose Implementation

5. `user.service.ts` – Business Logic

6. `main.ts` – Example Usage

🔸 Array, `null`, or `undefined` Confusion

📦 `User.ts`

🧱 `UserBuilder.ts`