DEV Community: bilel salem

From Prompt to Pull Request: Using Claude Design, Claude Code, and GitHub Together

bilel salem — Wed, 06 May 2026 16:50:24 +0000

Why this matters

For years, the design-to-engineering handoff has been the most expensive translation step in product work. A designer mocks something up in Figma. An engineer rebuilds it in React, makes a dozen small judgment calls about spacing and states the design didn't cover, and ships something that's kind of the same. Two weeks later, the designer notices the buttons are 2px off and the empty state is missing entirely.

Anthropic shipped Claude Design to collapse that gap. It's a design tool that talks to a coding agent (Claude Code) that talks to your repo. Same model family at every step — no JPEGs being thrown over a wall.

This article walks through the full pipeline:

Building a prototype in Claude Design
Handing it off to Claude Code
Wiring the whole thing to GitHub so PRs get opened automatically

If you've already got a Pro/Max/Team/Enterprise Claude subscription, you have access. Let's go.

What Claude Design actually is

Claude Design lives at claude.ai/design and is a separate surface from the regular Claude chat. It's part of Anthropic Labs (research preview), powered by Claude Opus 4.7, and shipped publicly in mid-April 2026.

The mental model: you describe what you want in plain language, Claude renders it on an interactive canvas as real HTML/CSS/JS, and you refine it through a mix of chat, inline comments, direct edits, and "tweak knobs" — sliders for things like spacing, color, and corner radius that you can attach to any property of the design.

A few things to know up front:

Everything is code under the hood. Designs are generated as code, not pixels. That's why the handoff to engineering works.
Outputs include slides, landing pages, prototypes, mobile app mockups, and full design systems. It's not just for screens.
Exports are flexible. ZIP, PDF, PPTX, standalone HTML, Canva (via partnership), share URLs (view/comment/edit), and — most importantly — handoff to Claude Code.
It has its own usage limits. As of the research preview, Claude Design's quota is independent of your regular Claude chat usage.

Step 1 — Set up your design system

The single biggest factor in output quality is your design system. Claude Design without a design system gives you generic, AI-flavored output. Claude Design with a real design system gives you something that looks like it belongs to your product.

You have four ways to set one up:

Generate one from scratch by uploading brand assets, style guide snapshots, or even just inspiration images. Claude will extract colors, typography, spacing, and component patterns.
Upload an existing design system as a folder of components, tokens, or a Figma .fig export.
Link a GitHub repo so Claude reads your real components and tokens directly from code.
Pick an open-source design system (shadcn/ui, Material, etc.) as your starting point.

Then, in your organization settings, open the design system, refine it via the Remix chat panel on the left, and flip the Published toggle on. Once published, every new project in that workspace inherits it automatically.

A practical tip: when extracting from brand assets, include real finished work — a live landing page, a marketing site, a real shipped screen. A color palette and a logo aren't enough. Brands have feel, and feel comes from finished work.

Step 2 — Build the prototype

Once your design system is in place, you start a new project and describe what you want. The prompts that work best are specific about scope and structure:

"Design a settings page for a SaaS dashboard with a left sidebar nav (Account, Billing, Notifications, Integrations), a main content panel where each section is expandable, and a sticky save bar at the bottom."

"Map out the flow for a user upgrading from free to paid: dashboard upgrade prompt → plan comparison → payment form → confirmation → updated dashboard with premium features unlocked. Generate each screen in context."

"Build a landing page hero in two variations — one feature-led, one outcome-led — so I can A/B them."

Claude renders the result on the canvas and you start iterating.

Refining: the part where Claude Design earns its keep

Three tools matter here:

Inline comments — click any element and leave a note. "Make this CTA more prominent" attached to the actual button.
Direct edits — change text inline, drag to resize, recolor without going through chat.
The tweaks panel — sliders and toggles for live adjustments. The real superpower: you can ask Claude to add new controls to the panel itself. Want a glow slider? A density toggle? A radius knob? Just say so. Most AI design tools have a fixed property panel; this one lets you grow it.

Once you've got something you like on one screen, ask Claude to "apply this treatment across the full design" and it propagates the changes.

Before you hand anything off, run through edge cases explicitly: empty states, error states, loading states, different data volumes, and responsive variants at 375px / 768px / 1280px. A prompt like "show me how this handles the empty state when the user has no data yet" takes 30 seconds and saves an engineer half a day.

Step 3 — Link your codebase

This is where Claude Design separates itself from every other AI design tool.

In the project, click Import. You get two options:

From GitHub — connect your repository. Claude reads your components, your styling approach (Tailwind, CSS modules, styled-components — it figures it out), your spacing scale, your file structure, and your naming conventions.
From a local directory — drag-and-drop a folder if you can't connect the repo directly.

Once linked, your codebase is part of the project's context. Now your prompts can reference real components:

"Use our ProductCard component for the grid, follow the same layout pattern as the existing SettingsPage, and reuse the useUser hook for the avatar."

The output stops being generic React-flavored mockups and starts looking like something pulled from your repo. That's the whole point — when the prototype is already built with your real patterns, the gap between "prototype" and "shippable code" shrinks dramatically, which is exactly the framing Anthropic uses.

Step 4 — Hand off to Claude Code

Here's the moment that makes the whole pipeline interesting.

When the prototype is in good shape, you hit Share → Handoff to Claude Code. Claude Design generates a handoff bundle: the design files (HTML/CSS/JS), screenshots of each state, and a README that tells the coding agent what stack to target and what conventions to follow.

You have two options for where the bundle goes:

Claude Code Web — fully in the browser, the bundle opens in a Claude Code session that can read it natively.
Local Claude Code — download the bundle, drop it into your repo, and run claude in the directory.

Either way, Claude Code now has:

The design intent (encoded in the HTML/CSS/JS output)
Your codebase context (if you linked it)
The README with explicit stack instructions
The conversation history from Claude Design — so it knows why you made the design decisions you made

That last part matters more than people realize. When you said "we went with tabs instead of a sidebar because users need to see all sections at once," that reasoning carries through. Claude Code doesn't just rebuild the pixels; it preserves the intent.

Tip: write your own handoff README

The default README is fine. A hand-crafted one is the difference between "merged this week" and "rewrite from scratch." A good handoff README spells out:

Target stack (Next.js 16 App Router, TypeScript, Tailwind, shadcn/ui, etc.)
Where new components should live in the file tree
Naming conventions (kebab-case files, PascalCase components, etc.)
Definition of done — accessibility scan passes, renders at 3 breakpoints without horizontal scroll, all interactions work, bundle size delta within budget
Questions Claude Code should ask before coding rather than guessing — "what's the error state?", "what's the loading state?", "what should happen on form validation failure?"

Here's a stripped-down template you can paste into the bundle:

# [Feature] — Claude Code Handoff

## Stack
- Next.js 16 (App Router), TypeScript, Tailwind, shadcn/ui
- Components live in /components/[feature]/
- Use existing Button, Card, Dialog from /components/ui/

## Definition of done
- [ ] Renders at 375 / 768 / 1280px without horizontal scroll
- [ ] All interactions from the prototype work
- [ ] Empty/loading/error states implemented
- [ ] Axe accessibility scan: 0 violations
- [ ] PR includes before/after screenshots

## Ask before implementing
1. What's the error state for failed payments?
2. What happens when the user has 0 items?
3. Should we support `prefers-reduced-motion`?

That five-minute investment is worth more than any prompt-engineering trick.

Step 5 — Wire it to GitHub

Now the loop closes. There are two GitHub connections worth knowing about, and they do different things.

A) Linking your repo into Claude Design (read access)

This is the codebase import we covered in Step 3. Claude Design reads your repo so prototypes use your real components. It's read-only context — Claude Design doesn't push commits.

B) Claude Code GitHub Actions (write access)

This is where Claude Code actually opens PRs in your repo. You install the official Claude GitHub App and a workflow file, and from then on you can mention @claude in any issue or pull request and it picks up the task.

The fastest setup: open your terminal, install Claude Code, and run:

claude
> /install-github-app

This walks you through:

Installing the Claude GitHub app (https://github.com/apps/claude) on your repo. It needs read & write permissions for Contents, Issues, and Pull Requests. You need to be a repo admin.
Adding ANTHROPIC_API_KEY to your repository secrets.
Dropping a claude.yml workflow file into .github/workflows/.

If the auto-installer fails or you'd rather wire it up by hand, the manual setup is documented in the Claude Code GitHub Actions guide. The workflow defaults to Sonnet — if you want Opus 4.7, set model: claude-opus-4-7 in your workflow config.

Once it's installed, the magic moment looks like this:

You (in a GitHub issue): "@claude implement the prototype in design/handoff/settings-page.zip using our existing component library. Match the spec in the README and open a PR against main."

Claude reads the issue, clones the repo, ingests the handoff bundle, writes the code, runs your tests, and opens a PR. You review it like any other PR. If something's off, you comment on the diff and Claude pushes a new commit.

A few setup notes worth taking seriously:

Strip write permissions for review-only setups. If you only want Claude to review PRs, not modify them, give the action read-only access. Some teams cryptographically sign Claude's commits to keep an audit trail.
Set a reasonable timeout. 10–15 minutes is sane. Without it, runaway workflows eat your Actions minutes.
Add a CLAUDE.md at your repo root. This is the equivalent of a project-wide system prompt. Document your conventions, banned patterns, test commands, and lint rules. Claude reads it on every run.

The full loop, end to end

Here's what the workflow looks like on a real day:

Idea. A teammate posts in Slack: "We need a settings page redesign before the demo Friday."
Prototype. You open claude.ai/design, describe the page, iterate for 20 minutes with the tweaks panel until the spacing feels right.
Link the repo. You connect the GitHub repo so Claude uses your real Card, Tabs, and Input components.
Show stakeholders. You share the project URL with comment access. PM leaves three comments inline. You address them in five minutes.
Write the handoff README. Stack, file paths, definition of done, questions to ask.
Hit "Handoff to Claude Code." The bundle drops into a Claude Code Web session — or you download it locally.
Open a GitHub issue. "@claude implement settings page redesign from this bundle." Attach the bundle.
Review the PR. Claude opens it within minutes. You leave inline comments, Claude pushes fixes.
Merge. Done. Same day.

Before this pipeline existed, that's a one-week ticket. With it, it's a one-day ticket — and the design intent doesn't get lost in translation.

Where it breaks (be honest with yourself)

Claude Design isn't magic and it isn't right for everything:

Agencies that bill clients for Figma files. If your deliverable is a .fig file with hand-off-able layers, this isn't your tool yet.
Locked enterprise design systems with a design ops team gatekeeping changes. Claude Design wants to read your system from code, which doesn't fit that governance model.
Pixel-perfect brand work. For a hero image with custom illustration and bespoke type, you still want a designer in Figma and Illustrator.
Taste. Claude can generate ten dashboard variations in ten minutes. It can't tell you which one to ship for your users. That's still your job — and it's the part that's about to become more valuable, not less.

Tips that actually move the needle

A short list, ranked by ROI:

Invest in your design system before anything else. The output is only as good as the input.
Name things clearly during the design conversation. "ProductCard" sticks. "that thing" doesn't.
Document decisions in the chat, not just the design. Reasoning travels with the handoff.
Always generate edge states before handoff. Empty, loading, error, overflow.
Write your own handoff README. Five minutes saves three hours.
Add a CLAUDE.md to your repo. It's the highest-leverage file you can add to a repo right now.
Use the @claude mention in GitHub for the small stuff first. Build trust on tiny refactors before handing it a feature.

The bigger picture

Anthropic is quietly stitching together a knowledge-worker stack: Claude for chat and reasoning, Claude Code for engineering, Claude Cowork for async collaboration, and now Claude Design for visual work. The pattern is the same one Microsoft ran with Office decades ago — adjacent tools, shared substrate, compounding value when you use more than one.

The design-to-code closed loop is the first synergy that's actually visible. It's a bet that the next generation of product teams will own their design system in code, not in a dedicated design tool — and that bet looks increasingly correct.

If you're a builder, this is the workflow worth learning right now. The teams that internalize it will move at a different pace than the teams that don't.

Got questions or want to share your own workflow? I'm at bilelsalem.me.

Cracking the MERN Interview: React 19, Next.js 15, Supabase, PostgreSQL & Design Patterns Cheat Sheet

bilel salem — Fri, 26 Sep 2025 10:02:19 +0000

I. Backend Optimization

1. Caching

Use Redis or in-memory caching for reusable queries (e.g., top products, categories).
Prevents unnecessary DB hits.
Can also cache at API gateway level or Next.js cache layer.

2. Sharding

Split data horizontally across multiple servers.
Example: Users with IDs 0–1M on DB1, 1M–2M on DB2.
Improves scalability for write-heavy apps.

3. DB Replicas

Write DB (Postgres) + Read replicas (NoSQL or Postgres replicas).
Scale read traffic with replicas.
Use eventual consistency where real-time sync is not critical.

4. Microservices

Split heavy modules (e.g., auth, socket, notifications).
Communicate via Kafka / RabbitMQ.
Improves resilience: one service failing won’t kill the app.

II. Code-Level Best Practices

Push validation & blocking logic into middleware/guards, not services.
Heavy calculations → move to DB side (SQL aggregations, indexes).
Keep request flow minimal (reject invalid requests early).

III. Frontend Optimization

1. Data Fetching

Minimize useEffect usage.
Prefer TanStack Query or React use() for declarative fetching.
Benefit: caching, retries, background refresh, fewer re-renders.

2. Virtualization

Use libraries like react-window or react-virtualized for long lists.
Only render items in viewport (e.g., task manager with 1000+ tasks).

3. SSR / ISR

SSR: Fetch fresh data on every request (dynamic).
SSG: Pre-generate static pages at build time (fast).
ISR: Best of both → regenerate after revalidate interval.

IV. TanStack Query

1. Benefits vs `useEffect`

Built-in caching.
Silent background revalidation.
No manual loading state, avoids flicker.

2. Stale vs Fresh Data

Stale: Data older than staleTime, eligible for re-fetch.
Fresh: Recently fetched, served instantly.

3. Invalidate Queries

After mutation (create/update/delete), call:

  queryClient.invalidateQueries(['products'])

Forces refetch of updated list.

V. Supabase

1. Core Features

Authentication & Authorization out of the box.
Realtime (via Postgres subscriptions).
Cloud integrations (email, phone, storage).
Built-in SQL editor & API SDK.

2. Row-Level Security (RLS)

Granular rules: who can read/write which rows.
Example: A user can only see their own orders.
Protects DB directly, not just API layer.

VI. PostgreSQL Essentials

1. Indexes

Speed up searches like a dictionary reference.
Primary key index → unique IDs.
Composite index → combine fields (username + email).
GIN index → full-text search (e.g., search “keyword” inside paragraph).

VII. Next.js 15 Advanced

1. Server Actions

Skip API routes → hit DB directly.
No HTTP overhead = faster & safer.
Called via useTransition from client.

2. Built-in Caching

Next.js caches server action results by default.
Avoids duplicate DB queries.

3. State Management

Remote: Server Actions + cache.
Local (client): Context API.
Local (server): Params, cookies.

VIII. React 19 Features

1. `use()` Hook

Replace useEffect + useState for data fetching.
Works in server + client components.
Example:

  const data = use(fetchUser())

Suspense pauses UI until ready → smoother UX.

2. Suspense

Show fallback (loading...) until data loads.
Prevents partial/flickering UI.

3. React Compiler

New optimization → auto-memoizes expensive renders.
Reduces need for useMemo & useCallback.

IX. NestJS Concepts

1. Guards

Run before controller.
Used for auth, permissions, points validation.

2. Middleware

Run before controller OR before response leaves server.
Generic → can log, validate, modify requests/responses.

3. Interceptors

Used for transforming response/request.
Example: file upload, logging, wrapping responses.

X. Design Patterns (Refactoring Guru style)

1. Singleton

Only one instance.
Example: DB connection.

2. Observer

One-to-many dependency.
Example: RxJS streams in NestJS.

3. Strategy

Swap algorithms easily.
Example: Payment methods (Stripe, PayPal).

4. Decorator

Add behavior dynamically.
Example: NestJS @Controller, React HOCs.

5. Factory

Create objects without knowing exact class.
Example: NotificationFactory → Email/SMS/Push.

6. Adapter

Makes incompatible interfaces work.
Example: Wrap legacy API to work with new interface.

7. Proxy

Control access to object.
Example: API rate limiter, caching layer.

8. Builder

Build complex objects step by step.
Example: Build User with optional props.

XI. Practical Mixed Questions

How to optimize frontend with heavy data lists?
→ Virtualization + TanStack Query cache + Suspense.
How to secure Supabase DB?
→ RLS + role-based auth + JWT in headers.
When would you use ISR over SSR?
→ If data changes occasionally (products, blogs). SSR if data changes on every request (stock price).
Explain Strategy Pattern with code.
→ PaymentStrategy interface → StripePayment & PaypalPayment classes → dynamically injected.
Why prefer Server Actions over API routes in Next.js?
→ Faster, secure (no network), less boilerplate.

✅ Solving Image Download with a Server-Side Proxy in Next.js

bilel salem — Sat, 12 Jul 2025 10:28:17 +0000

🧩 The Problem: CORS Restrictions When Downloading Images

When working with web applications, you might want to allow users to download an image hosted on an external server. However, directly fetching and downloading an image from a third-party source in the browser often triggers CORS (Cross-Origin Resource Sharing) issues. This happens because:

Browsers enforce CORS policies to prevent unauthorized access to external resources.
If the external server doesn't allow your domain, your request is blocked, especially if it involves modifying headers or triggering a download.

❌ Typical Client-Side Approach Fails:

const response = await fetch("https://external-server.com/image.jpg");
// ❌ Blocked by CORS

So how do we safely download an image from an external server?

💡 The Solution: Server-Side Proxy

Instead of downloading the image directly from the frontend, we implemented a server-side proxy in a Next.js API route. This approach has several benefits:

Bypasses CORS: Server-to-server requests are not bound by CORS rules.
Custom headers: You can control content-disposition and other headers.
Security & Abstraction: The client never interacts directly with the external image host.

🛠️ Step-by-Step Implementation

1. Create a Proxy API Route: `/api/download-image/route.ts`

This API endpoint acts as a middleman between the client and the image server.

✅ Logic:

Accepts two query params: url (the image URL), and filename (optional, for saving the file).
Fetches the image from the external source.
Sets appropriate response headers to force a download.
Pipes the image back to the client.

📄 Example: `app/api/download-image/route.ts`

import { NextRequest } from "next/server";

export async function GET(req: NextRequest) {
  const { searchParams } = new URL(req.url);
  const url = searchParams.get("url");
  const filename = searchParams.get("filename") || "downloaded-image";

  if (!url) {
    return new Response("Missing image URL", { status: 400 });
  }

  try {
    const response = await fetch(url);
    if (!response.ok) throw new Error("Image fetch failed");

    const contentType = response.headers.get("content-type") || "application/octet-stream";
    const buffer = await response.arrayBuffer();

    return new Response(buffer, {
      headers: {
        "Content-Type": contentType,
        "Content-Disposition": `attachment; filename="${filename}"`,
        "Cache-Control": "no-cache",
      },
    });
  } catch (error) {
    return new Response("Error downloading image", { status: 500 });
  }
}

2. Update the Frontend Download Function

Instead of hitting the external image URL directly, your frontend now calls your proxy endpoint.

✅ Function Example:

const downloadImage = async (imageUrl: string, filename: string) => {
  const proxyUrl = `/api/download-image?url=${encodeURIComponent(imageUrl)}&filename=${encodeURIComponent(filename)}`;
  const link = document.createElement("a");
  link.href = proxyUrl;
  link.download = filename;
  document.body.appendChild(link);
  link.click();
  document.body.removeChild(link);
};

🔍 What This Does:

Constructs the proxy URL.
Triggers a download via a hidden anchor element.
The proxy handles the image fetch and sets the proper headers.

🧪 Example Usage

<button
  onClick={() =>
    downloadImage("https://example.com/image.jpg", "cool-image.jpg")
  }
>
  Download Image
</button>

✅ Benefits Recap

Feature	Why It Matters
🚫 No CORS issues	Server-to-server communication bypasses CORS
🎯 Filename control	Set desired filename with Content-Disposition
🔐 More secure	Client doesn't interact directly with external servers
🧩 Easily extensible	Add auth, image validation, logging, etc.

📌 Conclusion

Downloading images from third-party sources on the frontend can be tricky due to CORS restrictions, but implementing a server-side proxy in Next.js offers a clean, scalable solution. Whether you're building a design tool, a content editor, or just need to enable image exports, this method ensures a smooth and secure user experience.

⚙️ Tip: You can reuse this pattern for other file types (PDFs, audio, video) too!

A Unified, Type-Safe Database Adapter System for Multi-DB Applications

bilel salem — Thu, 19 Jun 2025 13:46:03 +0000

Database Adapters System

A flexible, database-agnostic interface that allows your application to work with multiple database types through a unified API.

Overview
Architecture
Supported Databases
Quick Start
Usage Examples
Creating Custom Adapters
Migration Guide
API Reference
Best Practices

Overview

The Database Adapters System provides a generic interface that abstracts database-specific operations, allowing you to:

Switch between databases without changing business logic
Support multiple databases in the same application
Maintain type safety across all database operations
Preserve backward compatibility with existing MongoDB code
Extend easily to support new database types

Architecture

┌─────────────────────┐
│   Business Logic    │
├─────────────────────┤
│ IDatabaseService    │  ← Generic Interface
├─────────────────────┤
│ DatabaseService     │  ← Implementation
├─────────────────────┤
│   Database Adapters │
├─────────────────────┤
│ MongoDB │ PostgreSQL│  ← Database-specific
│  MySQL  │  SQLite   │     adapters
└─────────────────────┘

Core Components

Generic Types (src/common/types/common.types.ts)

- `DatabaseOperator` - Standardized query operators
- `DatabaseCondition` - Generic condition structure
- `DatabaseQuery` - Complete query specification
- `DatabaseAdapter` - Adapter interface contract

Database Service (src/common/database/services/database.service.ts)

- Unified API for all database operations
- Adapter management and switching
- Backward compatibility layer

Adapters (src/common/database/adapters/)

- `MongoDBAdapter` - MongoDB translation
- `PostgreSQLAdapter` - PostgreSQL SQL generation
- Extensible for additional databases

Factory (src/common/database/factories/database-adapter.factory.ts)
- Centralized adapter creation and management
- Runtime adapter switching support

Supported Databases

Database	Status	Adapter Class	Notes
MongoDB	✅ Full	`MongoDBAdapter`	Default, backward compatible
PostgreSQL	✅ Full	`PostgreSQLAdapter`	SQL generation with parameters
MySQL	🚧 Planned	`MySQLAdapter`	Coming soon
SQLite	🚧 Planned	`SQLiteAdapter`	Coming soon
Redis	🚧 Planned	`RedisAdapter`	For caching/sessions

Quick Start

1. Basic Usage (MongoDB - Default)

import { DatabaseService } from 'src/common/database/services/database.service';

@Injectable()
export class UserService {
    constructor(private readonly databaseService: DatabaseService) {}

    async findActiveUsers() {
        // Create a simple filter - works with any database
        const filter = this.databaseService.filterEqual('status', 'active');
        return filter; // MongoDB: { status: { $eq: 'active' } }
    }
}

2. Switching to PostgreSQL

import { DatabaseService } from 'src/common/database/services/database.service';
import { DatabaseAdapterFactory } from 'src/common/database/factories/database-adapter.factory';

@Injectable()
export class UserService {
    constructor(
        private readonly databaseService: DatabaseService,
        private readonly adapterFactory: DatabaseAdapterFactory
    ) {
        // Switch to PostgreSQL
        const pgAdapter = this.adapterFactory.createAdapter('postgresql');
        this.databaseService.setAdapter(pgAdapter);
    }

    async findActiveUsers() {
        const filter = this.databaseService.filterEqual('status', 'active');
        return filter; // PostgreSQL: { whereClause: 'WHERE status = $1', parameters: ['active'] }
    }
}

Usage Examples

Building Complex Queries

import { DatabaseOperator } from 'src/common/types/common.types';

// Create individual conditions
const conditions = [
    this.databaseService.createCondition(
        'age',
        DatabaseOperator.GREATER_THAN,
        18
    ),
    this.databaseService.createCondition(
        'email',
        DatabaseOperator.CONTAINS,
        '@company.com'
    ),
    this.databaseService.createCondition('status', DatabaseOperator.IN, [
        'active',
        'premium',
    ]),
];

// Build complex query
const query = this.databaseService.buildQuery(conditions, 'AND', {
    limit: 10,
    offset: 0,
    sort: [{ field: 'createdAt', direction: 'DESC' }],
});

// Execute with current adapter
const result = this.databaseService.executeQuery(query);

Common Filter Operations

// Text search
const nameFilter = this.databaseService.filterContain('name', 'John', {
    caseSensitive: false,
    fullWord: false,
});

// Date range
const dateFilter = this.databaseService.filterDateBetween(
    'createdAt',
    'updatedAt',
    new Date('2023-01-01'),
    new Date('2023-12-31')
);

// Array operations
const categoryFilter = this.databaseService.filterIn('category', [
    'tech',
    'business',
]);
const excludeFilter = this.databaseService.filterNin('status', [
    'banned',
    'deleted',
]);

// Existence checks
const profileFilter = this.databaseService.filterExists('profile', true);

// Numeric comparisons
const scoreFilter = this.databaseService.filterGreaterThan('score', 100);

Runtime Adapter Switching

@Injectable()
export class DatabaseManager {
    constructor(
        private readonly databaseService: DatabaseService,
        private readonly adapterFactory: DatabaseAdapterFactory
    ) {}

    async switchDatabase(dbType: string) {
        if (this.adapterFactory.isSupported(dbType)) {
            const adapter = this.adapterFactory.createAdapter(dbType);
            this.databaseService.setAdapter(adapter);
            console.log(`Switched to ${dbType} adapter`);
        } else {
            throw new Error(`Unsupported database type: ${dbType}`);
        }
    }

    getSupportedDatabases(): string[] {
        return this.adapterFactory.getSupportedTypes();
    }
}

Creating Custom Adapters

1. Implement the DatabaseAdapter Interface

import { Injectable } from '@nestjs/common';
import {
    DatabaseAdapter,
    DatabaseQuery,
    DatabaseCondition,
    DatabaseSort,
    DatabaseOperator,
} from 'src/common/types/common.types';

@Injectable()
export class MySQLAdapter implements DatabaseAdapter {
    readonly name = 'mysql';

    translateQuery(query: DatabaseQuery): { sql: string; parameters: any[] } {
        // Implement MySQL-specific query translation
        const conditions = query.conditions.map(condition =>
            this.translateCondition(condition)
        );

        const whereClause =
            conditions.length > 0
                ? `WHERE ${conditions.map(c => c.condition).join(` ${query.logic || 'AND'} `)}`
                : '';

        const parameters = conditions.flatMap(c => c.parameters);

        return {
            sql: whereClause,
            parameters,
        };
    }

    translateCondition(condition: DatabaseCondition): {
        condition: string;
        parameters: any[];
    } {
        const { field, operator, value } = condition;

        switch (operator) {
            case DatabaseOperator.EQUAL:
                return { condition: `${field} = ?`, parameters: [value] };

            case DatabaseOperator.GREATER_THAN:
                return { condition: `${field} > ?`, parameters: [value] };

            case DatabaseOperator.CONTAINS:
                return {
                    condition: `${field} LIKE ?`,
                    parameters: [`%${value}%`],
                };

            // Add more operators as needed
            default:
                throw new Error(`Unsupported operator: ${operator}`);
        }
    }

    translateSort(sort: DatabaseSort[]): string {
        if (sort.length === 0) return '';

        const orderClauses = sort.map(s => `${s.field} ${s.direction}`);
        return `ORDER BY ${orderClauses.join(', ')}`;
    }
}

2. Register the Adapter

// In your module or service
import { MySQLAdapter } from './adapters/mysql.adapter';

@Injectable()
export class DatabaseSetupService {
    constructor(private readonly adapterFactory: DatabaseAdapterFactory) {
        // Register custom adapter
        this.adapterFactory.registerAdapter('mysql', () => new MySQLAdapter());
    }
}

3. Use the Custom Adapter

const mysqlAdapter = this.adapterFactory.createAdapter('mysql');
this.databaseService.setAdapter(mysqlAdapter);

// Now all operations use MySQL adapter
const filter = this.databaseService.filterEqual('id', 123);
// Output: { sql: 'WHERE id = ?', parameters: [123] }

Migration Guide

From MongoDB-Specific to Generic

Before (MongoDB-specific)

// Old way - MongoDB only
const mongoFilter = {
    status: { $eq: 'active' },
    age: { $gt: 18 },
    email: { $regex: /.*@company\.com/i },
};

After (Database-agnostic)

// New way - works with any database
const conditions = [
    this.databaseService.createCondition(
        'status',
        DatabaseOperator.EQUAL,
        'active'
    ),
    this.databaseService.createCondition(
        'age',
        DatabaseOperator.GREATER_THAN,
        18
    ),
    this.databaseService.createCondition(
        'email',
        DatabaseOperator.CONTAINS,
        '@company.com'
    ),
];

const query = this.databaseService.buildQuery(conditions, 'AND');
const filter = this.databaseService.executeQuery(query);

Backward Compatibility

All existing MongoDB code continues to work:

// These still work unchanged
const legacyFilter = this.databaseService.filterEqual('status', 'active');
const legacySearch = this.databaseService.filterContain('name', 'John');
const legacyDate = this.databaseService.filterDateBetween(
    'start',
    'end',
    date1,
    date2
);

API Reference

DatabaseOperator Enum

enum DatabaseOperator {
    EQUAL = 'eq',
    NOT_EQUAL = 'ne',
    GREATER_THAN = 'gt',
    GREATER_THAN_OR_EQUAL = 'gte',
    LESS_THAN = 'lt',
    LESS_THAN_OR_EQUAL = 'lte',
    IN = 'in',
    NOT_IN = 'nin',
    CONTAINS = 'contains',
    STARTS_WITH = 'startsWith',
    ENDS_WITH = 'endsWith',
    REGEX = 'regex',
    EXISTS = 'exists',
    IS_NULL = 'isNull',
    BETWEEN = 'between',
}

IDatabaseService Interface

Generic Query Methods

createCondition<T>(field, operator, value, options?) - Create a condition
buildQuery(conditions, logic?, options?) - Build complex query
executeQuery(query) - Execute query with current adapter

Convenience Methods

filterEqual<T>(field, value) - Equal filter
filterNotEqual<T>(field, value) - Not equal filter
filterContain(field, value, options?) - Text contains filter
filterIn<T>(field, values) - IN filter
filterNin<T>(field, values) - NOT IN filter
filterDateBetween(start, end, startDate, endDate) - Date range filter
filterGreaterThan<T>(field, value) - Greater than filter
filterLessThan<T>(field, value) - Less than filter
filterExists(field, exists) - Existence filter

Adapter Management

setAdapter(adapter) - Set database adapter
getAdapter() - Get current adapter
getSupportedDatabases() - List supported databases

DatabaseAdapterFactory

createAdapter(type) - Create adapter by type
getSupportedTypes() - List all supported types
isSupported(type) - Check if type is supported
registerAdapter(type, factory) - Register custom adapter

Best Practices

1. Adapter Selection Strategy

// Environment-based adapter selection
const dbType = process.env.DATABASE_TYPE || 'mongodb';
const adapter = this.adapterFactory.createAdapter(dbType);
this.databaseService.setAdapter(adapter);

2. Error Handling

try {
    const adapter = this.adapterFactory.createAdapter(dbType);
    this.databaseService.setAdapter(adapter);
} catch (error) {
    console.error(`Failed to initialize ${dbType} adapter:`, error.message);
    // Fallback to default
    const defaultAdapter = this.adapterFactory.createAdapter('mongodb');
    this.databaseService.setAdapter(defaultAdapter);
}

3. Type Safety

// Use specific types for better type safety
interface UserFilter {
    status: 'active' | 'inactive';
    age: number;
    email: string;
}

const userCondition = this.databaseService.createCondition<
    UserFilter['status']
>('status', DatabaseOperator.EQUAL, 'active');

4. Performance Considerations

// Cache adapters for frequently used databases
const adapterCache = new Map<string, DatabaseAdapter>();

function getCachedAdapter(type: string): DatabaseAdapter {
    if (!adapterCache.has(type)) {
        adapterCache.set(type, this.adapterFactory.createAdapter(type));
    }
    return adapterCache.get(type)!;
}

5. Testing Different Adapters

describe('Database Operations', () => {
    const testCases = ['mongodb', 'postgresql'];

    testCases.forEach(dbType => {
        describe(`with ${dbType}`, () => {
            beforeEach(() => {
                const adapter = adapterFactory.createAdapter(dbType);
                databaseService.setAdapter(adapter);
            });

            it('should filter active users', () => {
                const filter = databaseService.filterEqual('status', 'active');
                expect(filter).toBeDefined();
                // Add adapter-specific assertions
            });
        });
    });
});

Open Source & Contributing

This Database Adapter System is being released as an open-source project on GitHub to encourage collaboration and community-driven improvement.

🔗 GitHub Repository: [Coming Soon / https://github.com/bilelsalemdev/universal-db-adapter/tree/main]

Everyone is welcome to contribute — whether it's:

Writing unit and integration tests
Completing or improving existing adapters (e.g., MySQL, SQLite, Redis)
Suggesting enhancements or new features
Reporting issues or edge cases
Improving documentation and usage examples

If you're interested in helping shape a flexible, database-agnostic abstraction layer for modern applications, feel free to fork the repo, submit PRs, or start a discussion.

Let’s build it together! 💪

Why You Should Inject Interfaces, Not Classes, in NestJS Applications ?

bilel salem — Sat, 14 Jun 2025 14:22:24 +0000

Injecting interfaces instead of concrete classes in NestJS constructors (or any DI-based architecture) promotes decoupling, flexibility, and testability. However, because interfaces don't exist at runtime in TypeScript/JavaScript, this approach has practical limitations and requires additional setup (like useClass, useExisting, or useFactory).

✅ Benefits of Injecting Interfaces Instead of Classes

1. Loose Coupling

Problem: Injecting concrete classes tightly couples your service to a specific implementation.
Benefit: Injecting an interface allows you to depend on a contract, not a specific implementation.
Example:

  constructor(private readonly userService: IUserService) {}

2. Improved Testability

You can easily mock implementations in tests by providing a test-specific class or object.
Example:

  providers: [
    {
      provide: IUserService,
      useClass: MockUserService,
    },
  ]

3. Implementation Swapping

Swap one implementation for another without changing the consuming code.
Useful for different environments (e.g., mock vs. real, in-memory vs. database, local vs. cloud).

4. Domain-Driven Design (DDD) Alignment

Encourages defining clear contracts (interfaces) between domain services, infrastructure, and application layers.
Supports clean architecture and separation of concerns.

5. Avoid Circular Dependencies

When using interfaces and useClass or useExisting, you can often structure the code to avoid circular imports.

⚠️ Caveat in TypeScript and NestJS

TypeScript interfaces do not exist at runtime, so you cannot inject an interface directly using the interface name alone.
You must use tokens, often created with a Symbol or InjectionToken.

🛠 How to Inject an Interface in NestJS

// user-service.interface.ts
export interface IUserService {
  getUserById(id: string): Promise<User>;
}

// create a token
export const IUserServiceToken = Symbol('IUserService');

// in module
{
  provide: IUserServiceToken,
  useClass: UserService, // or a mock in test
}

// in constructor
constructor(@Inject(IUserServiceToken) private readonly userService: IUserService) {}

🧠 Summary

Benefit	Explanation
🔗 Loose Coupling	Decouples consumer from implementation
🧪 Testability	Easier mocking and unit testing
🔄 Flexibility	Swap implementations easily
📐 Clean Architecture	Enforces contracts, aligns with DDD
🔁 Avoid Circular Dependencies	Reduces tight runtime coupling

Deno vs Bun vs Node.js: The Ultimate Runtime Showdown

bilel salem — Sun, 08 Jun 2025 21:14:33 +0000

Introduction: The JavaScript Runtime Evolution

The JavaScript runtime landscape has exploded with competition:

Node.js (2009): The established veteran
Deno (2018): Secure TypeScript-first runtime
Bun (2022): All-in-one speed demon

This 4,000+ word technical guide compares them across 6 critical dimensions with:

Reproducible benchmarks (HTTP servers, file ops, DB queries)
Architecture diagrams
Real-world migration examples
Decision frameworks for different use cases

1. Architectural Breakdown

Node.js: The CommonJS Legacy

Key Characteristics:

CommonJS modules (require())
Callback-first non-blocking I/O
Massive npm registry (1.5M+ packages)

Deno: Secure TypeScript Runtime

Key Innovations:

Built-in TypeScript compiler
Secure-by-default (file/network permissions)
Web-standard APIs (fetch, WebSocket)

Bun: The All-in-One Runtime

Breakthrough Features:

JavaScriptCore engine (Safari's engine)
Native-speed SQLite integration
Drop-in Node.js compatibility

2. Performance Benchmarks

Test Environment

M1 Max (32GB RAM)
Runtime versions:
- Node.js 20.11
- Deno 1.40
- Bun 1.0.22

HTTP Server Throughput

// Node.js
const http = require('http');
http.createServer((req, res) => res.end('Hello')).listen(3000);

// Deno
Deno.serve({ port: 3000 }, () => new Response('Hello'));

// Bun
Bun.serve({ port: 3000, fetch: () => new Response('Hello') });

Results (Requests/sec):

Concurrency	Node.js	Deno	Bun
1	12,345	14,567	28,901
100	9,876	11,234	24,567

Key Insight: Bun's runtime architecture (JavaScriptCore + Zig-native HTTP server) outperforms Node's (V8 + libuv) in HTTP throughput benchmarks.

Filesystem Operations

// Reading 10,000 files
// Node.js
const fs = require('fs/promises');
await Promise.all(files.map(f => fs.readFile(f)));

// Deno
await Promise.all(files.map(f => Deno.readTextFile(f)));

// Bun
await Promise.all(files.map(f => Bun.file(f).text()));

Results (ms):

Operation	Node.js	Deno	Bun
Read	420	380	210
Write	510	490	230

3. Feature Comparison

TypeScript Support

Feature	Node.js	Deno	Bun
Native TS	❌	✅	✅
Config Needed	✅	❌	❌
Compile Speed	Slow	Fast	Fastest

Deno Example:

// Runs directly
deno run app.ts

Package Management

# Node.js
npm install lodash

# Deno 
import lodash from "npm:lodash";

# Bun
bun add lodash  # 28x faster than npm

Installation Speed (sec):

Package	npm	Deno	Bun
lodash	2.1	1.8	0.07

Web Compatibility

// All runtimes support:
fetch('https://api.example.com')
  .then(res => res.json())

API Coverage:

API	Node.js	Deno	Bun
WebSocket	✅	✅	✅
localStorage	❌	✅	✅
WebWorker	✅	✅	✅

4. Security Models

Permission Systems

Node.js:

# Full system access by default
node script.js

Deno:

# Explicit permissions
deno run --allow-net app.ts

Bun:

# Node.js-compatible with gradual security
bun run --untrusted-code-mitigations script.js

Security Scorecard:

Feature	Node.js	Deno	Bun
Default Sandbox	❌	✅	⚠️
Permission Flags	❌	✅	✅
WASM Isolation	❌	✅	✅

5. Real-World Use Cases

API Server Development

Node.js:

// Express.js example
const app = require('express')();
app.get('/', (req, res) => res.json({ status: 'ok' }));
app.listen(3000);

Deno:

// Oak framework
import { Application } from "oak";
const app = new Application();
app.use(ctx => ctx.response.body = { status: 'ok' });
await app.listen({ port: 3000 });

Bun:

// Elysia.js
import { Elysia } from 'elysia';
new Elysia().get('/', () => ({ status: 'ok' })).listen(3000);

Framework Ecosystem:

Runtime	Popular Frameworks
Node.js	Express, Fastify, NestJS
Deno	Oak, Hono, Fresh
Bun	Elysia, Hono, Express

6. Migration Guide

Node.js → Deno

Change require() to ES imports
Add file extensions (.js → .ts)
Set permissions in deno.json

Example:

- const fs = require('fs');
+ import { readFile } from 'node:fs/promises';

Node.js → Bun

Replace npm with bun commands
Optional: Use Bun's native APIs
Test edge cases (Node.js core module differences)

Example:

# Before
npm start

# After
bun run start

Decision Framework

Choose Node.js When:

You need maximum ecosystem compatibility
Enterprise stability is critical
Using legacy CommonJS modules

Choose Deno When:

Security is top priority
Building TypeScript-first applications
Want browser-compatible APIs

Choose Bun When:

Performance is the primary concern
Need an all-in-one toolkit (test runner, bundler)
Developing new projects without legacy constraints

Selection Algorithm:

Benchmark Setup Instructions

1. Install Runtimes

# Node.js
nvm install 20

# Deno
curl -fsSL https://deno.land/x/install/install.sh | sh

# Bun
curl -fsSL https://bun.sh/install | bash

2. Run HTTP Tests

# Node.js
node server.js

# Deno
deno run --allow-net deno-server.ts

# Bun
bun run bun-server.js

3. Execute Benchmarks

# Using autocannon
autocannon -c 100 -d 30 http://localhost:3000

The Verdict

While Node.js remains the safest choice for enterprise applications:

Bun is 3x faster for new projects
Deno provides superior security for sensitive applications
Node.js has the deepest ecosystem for complex integrations

Final Recommendation:

Use Bun for greenfield projects, Deno for security-first apps, and Node.js for legacy systems.

Which runtime are you using? Share your benchmarks below! 🚀

NestJS vs Express.js: When To Use Each

bilel salem — Fri, 30 May 2025 10:15:18 +0000

Introduction: The Node.js Framework Dilemma

In the Node.js ecosystem, two frameworks dominate backend development:

Express.js: The lightweight, unopinionated veteran (since 2010)
NestJS: The structured TypeScript alternative (since 2017)

This 3,000+ word technical guide compares them across 5 critical dimensions with:

Reproducible benchmarks (including test code)
Architecture diagrams
Real-world use case analysis
Decision frameworks for different project types

1. Architectural Philosophy

Express.js: Minimalism as a Virtue

// Typical Express.js app
const express = require('express');
const app = express();

app.use(express.json());
app.get('/users', (req, res) => {
  res.json([{ id: 1, name: 'John' }]);
});

app.listen(3000);

Key Characteristics:

� Unopinionated structure: No enforced patterns
⛓ Middleware pipeline: Linear request processing
🧩 Manual everything: Routing, DI, testing

NestJS: Structure at Scale

// Typical NestJS module
@Module({
  imports: [DatabaseModule],
  controllers: [UserController],
  providers: [UserService],
})
export class UserModule {}

// Injectable service
@Injectable()
export class UserService {
  constructor(private repo: UserRepository) {}
}

Key Characteristics:

🏗 Modular architecture: Inspired by Angular
💉 Dependency Injection: Built-in IoC container
📜 Decorator-based: @Controller, @Get, etc.

Architectural Decision Matrix:

Requirement	Express.js	NestJS
Prototyping speed	✅	❌
Large team workflow	❌	✅
Long-term maintenance	⚠	✅

2. Performance Benchmarks (With Test Code)

Methodology

Test Environment:

AWS t4g.medium (ARM, 2 vCPUs)
Node.js 20 LTS
Autocannon v7.10.0

Test Cases:

Simple JSON response
DB-connected endpoint (PostgreSQL)
JWT-authenticated route

Express.js Test Server

// express-app.js
const express = require('express');
const app = express();

// Simple endpoint
app.get('/', (req, res) => {
  res.json({ status: 'ok', timestamp: Date.now() });
});

// DB endpoint
app.get('/users', async (req, res) => {
  const users = await db.query('SELECT * FROM users LIMIT 10');
  res.json(users);
});

app.listen(3000);

NestJS Test Server

nest new benchmark-app

// user.controller.ts
@Controller()
export class UserController {
  constructor(private userService: UserService) {}

  @Get()
  getUsers() {
    return this.userService.findAll();
  }
}

Benchmark Results

Test Case	Express.js	NestJS	Delta
Simple JSON (req/sec)	31,200	27,500	-12%
DB Query (req/sec)	4,850	4,620	-5%
Startup Time (ms)	120	480	4x

Key Findings:

Express leads in raw throughput (especially simple requests)
NestJS DI overhead decreases with complex operations
Fastify adapter reduces gap to <5% difference

3. Advanced Features Face-Off

GraphQL Implementation

Express.js:

const { graphqlHTTP } = require('express-graphql');
const { buildSchema } = require('graphql');

const schema = buildSchema(`
  type User {
    id: ID!
    name: String!
  }
`);

app.use('/graphql', graphqlHTTP({ schema }));

NestJS:

@Resolver()
export class UserResolver {
  @Query(() => [User])
  users() {
    return this.userService.findAll();
  }
}

Advantage: NestJS auto-generates SDL from TypeScript classes.

WebSockets

Express.js:

const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
  ws.on('message', (data) => {
    wss.clients.forEach(client => client.send(data));
  });
});

NestJS:

@WebSocketGateway()
export class ChatGateway {
  @WebSocketServer()
  server: Server;

  @SubscribeMessage('message')
  handleMessage(client: Socket, payload: string) {
    this.server.emit('message', payload);
  }
}

Advantage: NestJS integrates WS with HTTP lifecycle and DI.

Serverless Deployment

Express.js on Lambda:

// Uses serverless-express
module.exports.handler = awsServerlessExpress.proxy(server);

NestJS on Lambda:

// Requires @nestjs/platform-express
export const handler = async (event) => {
  const app = await NestFactory.create(AppModule);
  await app.init();
  return serverlessExpress.proxy(app, event);
};

Cold Start Comparison:

Express: 300-500ms
NestJS: 700-1200ms (can be optimized to ~600ms)

4. Enterprise Readiness Comparison

Testing

Express.js:

// Manual mocking required
const request = require('supertest');
describe('GET /users', () => {
  it('returns 200', () => request(app).get('/users').expect(200));
});

NestJS:

// Built-in testing utilities
beforeEach(async () => {
  const module = await Test.createTestingModule({
    controllers: [UserController],
    providers: [UserService],
  }).compile();

  controller = module.get<UserController>(UserController);
});

Microservices

Express.js:

// Manual setup with RabbitMQ
amqp.connect('amqp://localhost', (err, conn) => {
  conn.createChannel((err, ch) => {
    ch.assertQueue('tasks');
    ch.consume('tasks', (msg) => processTask(msg));
  });
});

NestJS:

// Native microservice support
const app = await NestFactory.createMicroservice(AppModule, {
  transport: Transport.RMQ,
  options: { urls: ['amqp://localhost'], queue: 'tasks' }
});

5. Decision Framework

Choose Express.js When:

Building APIs with few routes
Need sub-500ms cold starts (serverless)
Team prefers JavaScript over TypeScript

Choose NestJS When:

Building enterprise applications
Using GraphQL or WebSockets
Team size >3 developers

Framework Selection Algorithm:

Complete Benchmark Setup Guide

1. Initialize Test Environment

# For Express.js
mkdir express-test && cd express-test
npm init -y
npm install express pg jsonwebtoken

# For NestJS
npm i -g @nestjs/cli
nest new nest-test
cd nest-test
npm install @nestjs/passport @nestjs/jwt typeorm pg

2. Run Benchmarks

# Install autocannon
npm install -g autocannon

# Test simple endpoint
autocannon -c 100 -d 20 http://localhost:3000

# Test DB endpoint
autocannon -c 50 -d 30 http://localhost:3000/users

3. Analyze Results

Compare:

Requests/second
Latency distribution
Memory usage patterns

The Verdict

While Express.js wins in raw performance for simple cases, NestJS provides:

40% faster development time for complex apps
60% reduction in production bugs (TypeScript advantage)
3x easier onboarding for new developers

Final Recommendation:

Use Express for microservices and serverless, NestJS for monoliths and enterprise apps.

Which framework are you using? Share your experiences below! 🚀

Solving Real Deployment Problems with Docker: Shared Networks and Beyond

bilel salem — Fri, 18 Apr 2025 08:32:22 +0000

Docker makes development and deployment easier—but it’s not always plug and play. As your stack grows, simple containers stop being enough. One of the first real-world challenges you’ll run into is inter-container communication, especially when building microservices or replicating production environments locally.

Let’s walk through a common problem and how Docker’s shared networks feature solves it.

The Problem: "It works on my machine"—until containers can't talk to each other

Imagine this: you're working on a simple microservices architecture with a Node.js API, a Redis cache, and a PostgreSQL database. You’ve containerized everything. Locally, you run each container, expose the ports, and it all seems fine—until your API container tries to connect to the database using localhost:5432. It fails.

Why? Because in Docker, each container has its own network namespace. From the API container’s perspective, localhost means itself—not the host or the Postgres container.

Manually exposing ports and referencing host.docker.internal might work in some setups, but it's fragile, doesn’t scale, and often breaks on different operating systems or cloud environments.

The Solution: Shared Docker Networks

The clean, scalable fix is using a user-defined Docker network.

When you create a custom bridge network, Docker adds internal DNS resolution. Containers on the same network can reference each other by name—no need to hardcode IPs or guess what localhost actually points to.

Example

docker network create app-network

Now you launch your services on the same network:

docker run -d --name db --network app-network postgres
docker run -d --name redis --network app-network redis
docker run -d --name api --network app-network my-node-api

Inside the API container, you can connect to the database using db:5432 or to Redis using redis:6379. Docker resolves the names automatically. No extra config needed.

Why this matters

You get environment parity between local dev and production.
Containers can communicate securely without exposing ports to the host.
Adding new services is plug-and-play—no need to rewire everything.

A Real-World Scenario: Local Dev Environments That Mirror Production

Let’s say you're building a staging environment that mimics your Kubernetes cluster. You spin up 5-6 services in Docker Compose—some internal, some public-facing. Without a shared network, you’ll end up exposing too many ports, managing hostnames manually, and debugging broken links between services.

But with a shared network in Docker Compose:

services:
  api:
    build: ./api
    networks:
      - backend

  db:
    image: postgres
    networks:
      - backend

networks:
  backend:

It all “just works.” Services talk to each other by name, nothing leaks to the host, and your staging setup behaves like production—without the pain.

Takeaway

Inter-container communication is a common stumbling block for anyone moving beyond single-container setups. Docker's shared networks give you a clean, scalable way to solve this problem.

Don’t hardcode IPs. Don’t expose every port to your host. Just use networks right, and your services will find each other—reliably, predictably, and securely.

Understanding the Adapter Design Pattern: Bridging Incompatible Interfaces

bilel salem — Mon, 24 Mar 2025 08:19:30 +0000

In software development, systems often evolve, requiring integration between components with incompatible interfaces. This challenge is where the Adapter design pattern shines. Acting as a structural design pattern, the Adapter allows objects with incompatible interfaces to collaborate seamlessly by converting one interface into another.

This article is based on information from Refactoring.Guru, and it includes examples and concepts presented on that site.

What Is the Adapter Pattern?

Also known as the Wrapper pattern, the Adapter pattern creates a bridge between two incompatible interfaces. It enables existing code to work with new components without modification, preserving the existing functionality while integrating new capabilities.

Problem Scenario

Consider a stock market monitoring app that fetches stock data in XML format and displays it in charts and diagrams. Now, suppose you want to integrate a powerful third-party analytics library that only works with JSON. Modifying the analytics library to support XML is impractical, especially if you lack access to its source code.

Without a solution, you face a compatibility deadlock. Enter the Adapter pattern.

How the Adapter Pattern Works

The Adapter pattern introduces a special object, the adapter, to handle the conversion between incompatible interfaces. Here's how it operates:

Client Interface: The existing system expects data in a specific format (e.g., JSON).
Service Interface: The third-party or legacy system provides data in an incompatible format (e.g., XML).
Adapter: The adapter implements the client interface while wrapping the service object, converting incoming data to the required format.
Interaction: The client interacts with the adapter, unaware of the conversion complexity.

This separation ensures that changes in the service interface don't ripple through the client code.

Real-World Analogy

Imagine traveling from the U.S. to Europe and trying to charge your laptop. The power outlets in Europe differ from those in the U.S. A power plug adapter bridges this gap by converting the U.S. plug to fit European sockets. Similarly, in software, the Adapter pattern converts one interface to work seamlessly with another.

Types of Adapters

Object Adapter: Utilizes object composition by wrapping the service object within the adapter class. This is more flexible since it can work with multiple service objects.
Class Adapter: Uses inheritance to combine the interfaces of both the client and service classes. This approach is limited to languages that support multiple inheritance, such as C++.

Pseudocode Example

To illustrate, consider adapting square pegs to fit round holes:

class RoundHole {
    private double radius;

    public RoundHole(double radius) { this.radius = radius; }

    public double getRadius() { return radius; }

    public boolean fits(RoundPeg peg) {
        return this.radius >= peg.getRadius();
    }
}

class SquarePeg {
    private double width;

    public SquarePeg(double width) { this.width = width; }

    public double getWidth() { return width; }
}

class SquarePegAdapter extends RoundPeg {
    private SquarePeg peg;

    public SquarePegAdapter(SquarePeg peg) { this.peg = peg; }

    @Override
    public double getRadius() {
        return (peg.getWidth() * Math.sqrt(2)) / 2;
    }
}

In this example, the adapter makes the square peg behave like a round peg by calculating a compatible radius.

When to Use the Adapter Pattern

When you need to integrate a legacy system or third-party library with incompatible interfaces.
When extending every subclass to add missing functionality is inefficient.
When maintaining flexibility and scalability is crucial.

Pros and Cons

✅ Pros:
✔ Adheres to the Single Responsibility Principle by separating conversion logic.
✔ Promotes the Open/Closed Principle, allowing new adapters without breaking existing code.
✔ Enables code reuse and scalability.

❌ Cons:
✘ Increases overall system complexity.
✘ May introduce performance overhead due to extra layers of abstraction.

Adapter vs. Other Patterns

Facade: Defines a new interface, while the Adapter makes an existing interface usable.
Decorator: Extends functionality while keeping the interface unchanged.
Proxy: Provides a surrogate for another object without altering the interface.

Conclusion

The Adapter design pattern is essential for integrating incompatible systems without extensive modifications. By introducing a translation layer, it preserves existing functionality while enabling seamless collaboration with new or legacy components. Whether dealing with legacy systems, third-party libraries, or simply different data formats, the Adapter pattern offers a clean and scalable solution.

Understanding the Prototype Pattern

bilel salem — Thu, 27 Jun 2024 08:25:35 +0000

ASSALAMUALAIKUM WARAHMATULLAHI WABARAKATUH, السلام عليكم و رحمة اللّه و بركاته

Introduction

Design patterns are essential in software engineering as they provide time-tested solutions to common problems. One such pattern is the Prototype Pattern, which can simplify the process of creating new objects. In this article, we will explore the Prototype Pattern, understand its usages, and see how to implement it in TypeScript with some real-world examples.

What is the Prototype Pattern?

The Prototype Pattern is a creational design pattern that allows you to clone existing objects instead of creating new instances from scratch. This is particularly useful when object creation is costly or complex.

Key Concepts

Prototype: The original object that you want to clone.
Cloning: Creating a new object that is a copy of the prototype.

Why Use the Prototype Pattern?

Performance: Cloning an object can be faster than creating a new instance.
Complexity: Simplifies the creation of objects with complex configurations.
Flexibility: Allows you to create new objects without knowing the exact class of the object that will be created.

Implementing the Prototype Pattern in TypeScript

Let's look at how to implement the Prototype Pattern in TypeScript. We'll start with a simple example and then move to more complex examples.

Simple Example

First, let's define an interface for cloning.

interface Prototype {
    clone(): Prototype;
}

Now, we'll create a concrete class that implements this interface.

class User implements Prototype {
    constructor(public name: string, public age: number) {}

    clone(): User {
        return new User(this.name, this.age);
    }

    display(): void {
        console.log(`Name: ${this.name}, Age: ${this.age}`);
    }
}

Here, the User class implements the Prototype interface and provides a clone method to create a copy of the user.

const originalUser = new User("Bilel", 23);
const clonedUser = originalUser.clone();

originalUser.display(); // Name: Bilel, Age: 23
clonedUser.display();   // Name: Bilel, Age: 23

Now, let's deep dive into a more complex example. We'll create a scenario involving a content management system (CMS) where different types of content objects (e.g., articles, videos, podcasts) need to be created and customized frequently. This example will showcase the Prototype Pattern in a richer context.

Complex Example: Content Management System (CMS)

In this CMS example, we'll have different types of content, each with various properties. We'll use the Prototype Pattern to clone these content objects easily.

Step 1: Define the Prototype Interface

interface ContentPrototype {
    clone(): ContentPrototype;
}

Step 2: Create Concrete Content Classes

We will create three concrete classes: Article, Video, and Podcast, each implementing the ContentPrototype interface.

class Article implements ContentPrototype {
    constructor(
        public title: string,
        public body: string,
        public author: string,
        public tags: string[],
        public publishDate: Date
    ) {}

    clone(): Article {
        return new Article(this.title, this.body, this.author, [...this.tags], new Date(this.publishDate.getTime()));
    }

    display(): void {
        console.log(`Article Title: ${this.title}`);
        console.log(`Body: ${this.body}`);
        console.log(`Author: ${this.author}`);
        console.log(`Tags: ${this.tags.join(", ")}`);
        console.log(`Publish Date: ${this.publishDate}`);
    }
}

class Video implements ContentPrototype {
    constructor(
        public title: string,
        public url: string,
        public duration: number,
        public uploader: string,
        public publishDate: Date
    ) {}

    clone(): Video {
        return new Video(this.title, this.url, this.duration, this.uploader, new Date(this.publishDate.getTime()));
    }

    display(): void {
        console.log(`Video Title: ${this.title}`);
        console.log(`URL: ${this.url}`);
        console.log(`Duration: ${this.duration} minutes`);
        console.log(`Uploader: ${this.uploader}`);
        console.log(`Publish Date: ${this.publishDate}`);
    }
}

class Podcast implements ContentPrototype {
    constructor(
        public title: string,
        public host: string,
        public episodes: number,
        public tags: string[],
        public publishDate: Date
    ) {}

    clone(): Podcast {
        return new Podcast(this.title, this.host, this.episodes, [...this.tags], new Date(this.publishDate.getTime()));
    }

    display(): void {
        console.log(`Podcast Title: ${this.title}`);
        console.log(`Host: ${this.host}`);
        console.log(`Episodes: ${this.episodes}`);
        console.log(`Tags: ${this.tags.join(", ")}`);
        console.log(`Publish Date: ${this.publishDate}`);
    }
}

Step 3: Use the Prototype Pattern

Let's use these content types and demonstrate cloning in the CMS.

// Creating an original article
const originalArticle = new Article(
    "Prototype Pattern in TypeScript",
    "This article explains the Prototype Pattern in TypeScript with examples.",
    "Bilel Salem",
    ["design patterns", "typescript"],
    new Date()
);
const clonedArticle = originalArticle.clone();

originalArticle.display();
clonedArticle.display();

// Modifying cloned article
clonedArticle.title = "Cloned Article: Prototype Pattern in TypeScript";
clonedArticle.display();

// Creating an original video
const originalVideo = new Video(
    "Prototype Pattern Tutorial",
    "https://example.com/video",
    23,
    "Bilel Salem",
    new Date()
);
const clonedVideo = originalVideo.clone();

originalVideo.display();
clonedVideo.display();

// Modifying cloned video
clonedVideo.title = "Cloned Video: Prototype Pattern Tutorial";
clonedVideo.display();

// Creating an original podcast
const originalPodcast = new Podcast(
    "Design Patterns Podcast",
    "Foulen ben Foulen",
    23,
    ["design patterns", "software engineering"],
    new Date()
);
const clonedPodcast = originalPodcast.clone();

originalPodcast.display();
clonedPodcast.display();

// Modifying cloned podcast
clonedPodcast.title = "Cloned Podcast: Design Patterns";
clonedPodcast.display();

Explanation

Defining the Prototype Interface: The ContentPrototype interface ensures that all content types can be cloned.
Creating Concrete Content Classes: The Article, Video, and Podcast classes implement the ContentPrototype interface. Each class provides its own clone method to create a deep copy of the object.
Using the Prototype Pattern: We create original instances of Article, Video, and Podcast, then clone them. Modifications to the cloned instances do not affect the original instances, demonstrating the effectiveness of the Prototype Pattern.

Conclusion

The Prototype Pattern is particularly useful in scenarios where object creation is complex or resource-intensive.

The Builder Pattern in TypeScript

bilel salem — Tue, 25 Jun 2024 05:54:17 +0000

ASSALAMUALAIKUM WARAHMATULLAHI WABARAKATUH, السلام عليكم و رحمة اللّه و بركاته

Introduction

The Builder Pattern is a creational design pattern that allows for the step-by-step construction of complex objects. Unlike other patterns, it provides a clear separation between the construction and representation of an object. This makes it particularly useful when an object requires multiple initialization parameters or complex configurations.

Key Components of the Builder Pattern

Builder Interface: Defines the methods required for building the different parts of the product.
Concrete Builder: Implements the Builder interface and provides specific implementations for each part of the product.
Product: The complex object being built.
Director: (Optional) Orchestrates the construction process by using the builder interface.

Advantages of Using the Builder Pattern

Improved Readability: Construction logic is encapsulated within the builder, making the code easier to understand.
Flexibility: Different configurations of an object can be created without altering the core structure.
Immutability: Final products are often immutable, reducing the risk of errors.

Implementing the Builder Pattern in TypeScript

Let's dive deep into a practical example to understand how the Builder Pattern can be implemented in TypeScript.

Example Scenario: Building a User Profile

Consider a scenario where we need to create a UserProfile object with several optional and mandatory fields. The Builder Pattern is an excellent choice for handling this complexity.

Step-by-Step Implementation

Step 1: Define the UserProfile

class UserProfile {
  public firstName: string;
  public lastName: string;
  public age?: number;
  public email?: string;
  public address?: string;

  constructor(builder: UserProfileBuilder) {
    this.firstName = builder.firstName;
    this.lastName = builder.lastName;
    this.age = builder.age;
    this.email = builder.email;
    this.address = builder.address;
  }
}

Step 2: Create the Builder Class

class UserProfileBuilder {
  public firstName: string;
  public lastName: string;
  public age?: number;
  public email?: string;
  public address?: string;

  constructor(firstName: string, lastName: string) {
    this.firstName = firstName;
    this.lastName = lastName;
  }

  setAge(age: number): UserProfileBuilder {
    this.age = age;
    return this;
  }

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

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

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

Step 3: Use the Builder to Create Objects

const userProfile = new UserProfileBuilder('Bilel', 'Salem')
  .setAge(23)
  .setEmail('bilelsalemdev@gmail.com')
  .setAddress('Tunisia')
  .build();

console.log(userProfile);

Explanation

Product Class (UserProfile): Represents the object being built.
Builder Class (UserProfileBuilder): Contains the fields and methods for setting optional parameters.
Method Chaining: Each method in the builder returns this, allowing for chaining.

More Complex Example: Building a Configurable Computer System

We'll create a Computer object that can be configured with various components such as CPU, GPU, RAM, storage, cooling system, power supply, and additional peripherals. Each of these components may have optional configurations, making the construction process intricate.

Step 1: Define the Product

We'll define the Computer class, representing the complex object to be built.

class Computer {
  public cpu: string;
  public gpu?: string;
  public ram: number;
  public storage: { type: string; capacity: number }[];
  public coolingSystem?: string;
  public powerSupply: string;
  public peripherals?: string[];

  constructor(builder: ComputerBuilder) {
    this.cpu = builder.cpu;
    this.gpu = builder.gpu;
    this.ram = builder.ram;
    this.storage = builder.storage;
    this.coolingSystem = builder.coolingSystem;
    this.powerSupply = builder.powerSupply;
    this.peripherals = builder.peripherals;
  }
}

Step 2: Create the Builder Class with Validation and Default Configurations

Next, we'll create the ComputerBuilder class, which will handle the construction of the Computer object, including validation and default configurations.

class ComputerBuilder {
  public cpu: string;
  public gpu?: string;
  public ram: number;
  public storage: { type: string; capacity: number }[];
  public coolingSystem?: string;
  public powerSupply: string;
  public peripherals?: string[];

  constructor(cpu: string, ram: number, powerSupply: string) {
    this.cpu = cpu;
    this.ram = ram;
    this.powerSupply = powerSupply;
    this.storage = [];
  }

  addGPU(gpu: string): ComputerBuilder {
    this.gpu = gpu;
    return this;
  }

  addStorage(type: string, capacity: number): ComputerBuilder {
    this.storage.push({ type, capacity });
    return this;
  }

  addCoolingSystem(coolingSystem: string): ComputerBuilder {
    this.coolingSystem = coolingSystem;
    return this;
  }

  addPeripherals(peripherals: string[]): ComputerBuilder {
    this.peripherals = peripherals;
    return this;
  }

  validate(): void {
    if (!this.cpu) {
      throw new Error('CPU is required.');
    }
    if (this.ram <= 0) {
      throw new Error('RAM must be greater than 0.');
    }
    if (!this.powerSupply) {
      throw new Error('Power supply is required.');
    }
  }

  build(): Computer {
    this.validate();
    return new Computer(this);
  }

  static defaultGamingPC(): ComputerBuilder {
    return new ComputerBuilder('AMD Ryzen 9', 32, '850W Power Supply')
      .addGPU('NVIDIA RTX 4090')
      .addStorage('SSD', 2048)
      .addCoolingSystem('Advanced Liquid Cooling')
      .addPeripherals(['Gaming Keyboard', 'Gaming Mouse', 'VR Headset']);
  }

  static defaultOfficePC(): ComputerBuilder {
    return new ComputerBuilder('Intel Core i7', 16, '600W Power Supply')
      .addStorage('SSD', 512)
      .addPeripherals(['Ergonomic Keyboard', 'Wireless Mouse']);
  }
}

Step 3: Use the Builder to Create Objects

Now, let's use the ComputerBuilder to create various configurations of a Computer object, including custom configurations and default configurations.

// Custom Gaming PC Configuration
const gamingPC = new ComputerBuilder('Intel Core i9', 32, '750W Power Supply')
  .addGPU('NVIDIA RTX 3080')
  .addStorage('SSD', 1024)
  .addStorage('HDD', 2048)
  .addCoolingSystem('Liquid Cooling')
  .addPeripherals(['Mechanical Keyboard', 'Gaming Mouse', 'RGB Lighting'])
  .build();

// Custom Office PC Configuration
const officePC = new ComputerBuilder('Intel Core i5', 16, '500W Power Supply')
  .addStorage('SSD', 512)
  .addPeripherals(['Standard Keyboard', 'Optical Mouse'])
  .build();

// Default Gaming PC Configuration
const defaultGamingPC = ComputerBuilder.defaultGamingPC().build();

// Default Office PC Configuration
const defaultOfficePC = ComputerBuilder.defaultOfficePC().build();

console.log('Custom Gaming PC:', gamingPC);
console.log('Custom Office PC:', officePC);
console.log('Default Gaming PC:', defaultGamingPC);
console.log('Default Office PC:', defaultOfficePC);

Some Explations

Computer Class: Represents the configurable computer system with various components.
ComputerBuilder Class: Manages the construction process, including validation and default configurations.
Method Chaining: Ensures that the builder methods can be called in a readable and fluid manner.
Validation: Ensures that essential components are present and valid before building the object.
Default Configurations: Provides easy access to pre-defined configurations for common use cases.

Conclusion

The Builder Pattern is a tool for constructing complex objects with multiple optional and mandatory fields. It separates the construction process from the representation.

Understanding the Factory Method Design Pattern

bilel salem — Thu, 20 Jun 2024 22:42:39 +0000

Hello everyone, السلام عليكم و رحمة الله و بركاته

The Factory Method is a creational design pattern that provides an interface for creating objects in a superclass but allows subclasses to alter the type of objects that will be created. It helps in dealing with the problem of creating objects without having to specify the exact class of the object that will be created. This is particularly useful in scenarios where the creation process is complex or involves multiple steps.

What Problem Does the Factory Method Solve?

Class Instantiation Issues: Directly instantiating objects using new can lead to code that is tightly coupled with specific classes. This makes the code difficult to maintain and extend.
Complex Object Creation: When object creation involves several steps or configurations, using a constructor can be cumbersome and hard to read.
Subclasses Control: It provides a way for subclasses to decide which class to instantiate, allowing for more flexible and reusable code.

Key Concepts of the Factory Method

Product: The interface or abstract class defining the objects that the factory method will create.
Concrete Product: The implementation of the product interface.
Creator: The abstract class or interface that declares the factory method.
Concrete Creator: The class that implements the factory method to create an object of the Concrete Product class.

Real-World Example: Document Creation

Consider a scenario where we have an application that can create different types of documents such as Word Documents, PDF Documents, and Excel Sheets. The application should be able to generate these documents without knowing their specific implementation details.

Step-by-Step Implementation in TypeScript

Define the Product Interface

interface IDocument {
    open(): void;
    save(): void;
    close(): void;
}

Concrete Products

class WordDocument implements IDocument {
    open(): void {
        console.log("Opening Word Document");
    }
    save(): void {
        console.log("Saving Word Document");
    }
    close(): void {
        console.log("Closing Word Document");
    }
}

class PDFDocument implements IDocument {
    open(): void {
        console.log("Opening PDF Document");
    }
    save(): void {
        console.log("Saving PDF Document");
    }
    close(): void {
        console.log("Closing PDF Document");
    }
}

class ExcelDocument implements IDocument {
    open(): void {
        console.log("Opening Excel Document");
    }
    save(): void {
        console.log("Saving Excel Document");
    }
    close(): void {
        console.log("Closing Excel Document");
    }
}

Creator Abstract Class

abstract class DocumentCreator {
    public abstract createDocument(): IDocument;

    public newDocument(): void {
        const doc = this.createDocument();
        doc.open();
        doc.save();
        doc.close();
    }
}

Concrete Creators

class WordDocumentCreator extends DocumentCreator {
    public createDocument(): IDocument {
        return new WordDocument();
    }
}

class PDFDocumentCreator extends DocumentCreator {
    public createDocument(): IDocument {
        return new PDFDocument();
    }
}

class ExcelDocumentCreator extends DocumentCreator {
    public createDocument(): IDocument {
        return new ExcelDocument();
    }
}

Client Code

class Application {
    public static main(): void {
        let creator: DocumentCreator;

        creator = new WordDocumentCreator();
        creator.newDocument();

        creator = new PDFDocumentCreator();
        creator.newDocument();

        creator = new ExcelDocumentCreator();
        creator.newDocument();
    }
}

Application.main();

Explanation

IDocument Interface: This interface defines the methods open(), save(), and close() that all document types must implement.
Concrete Products: WordDocument, PDFDocument, and ExcelDocument are classes that implement the IDocument interface. Each class provides its own implementation for the methods defined in the interface.
DocumentCreator Abstract Class: This abstract class declares the factory method createDocument(). It also provides a newDocument() method that calls the factory method to create a document and then performs a series of operations on it.
Concrete Creators: WordDocumentCreator, PDFDocumentCreator, and ExcelDocumentCreator are subclasses of DocumentCreator. Each subclass implements the createDocument() method to instantiate a specific type of document.
Client Code: The Application class demonstrates how to use the factory method pattern. It creates instances of different document creators and calls the newDocument() method to generate and operate on documents.

Benefits of Using the Factory Method Pattern in TypeScript

Decoupling: The client code (Application) does not need to know the exact class of the document it works with. It only interacts with the IDocument interface and the DocumentCreator abstract class.
Single Responsibility: Each creator class is responsible for instantiating a specific type of document. The document classes handle their own specific behaviors.
Flexibility and Extensibility: Adding a new type of document is straightforward. You can create a new class that implements the IDocument interface and a new creator class that extends DocumentCreator.
Maintainability: Changes in the creation process of specific documents do not affect the client code or other document types.

By using the Factory Method pattern, you can create complex applications with different features without complicating the code, adhering to principles of clean code and design patterns.

DEV Community: bilel salem

From Prompt to Pull Request: Using Claude Design, Claude Code, and GitHub Together

Why this matters

What Claude Design actually is

Step 1 — Set up your design system

Step 2 — Build the prototype

Refining: the part where Claude Design earns its keep

Step 3 — Link your codebase

Step 4 — Hand off to Claude Code

Tip: write your own handoff README

Step 5 — Wire it to GitHub

A) Linking your repo into Claude Design (read access)

B) Claude Code GitHub Actions (write access)

The full loop, end to end

Where it breaks (be honest with yourself)

Tips that actually move the needle

The bigger picture

Cracking the MERN Interview: React 19, Next.js 15, Supabase, PostgreSQL & Design Patterns Cheat Sheet

I. Backend Optimization

1. Caching

2. Sharding

3. DB Replicas

4. Microservices

II. Code-Level Best Practices

III. Frontend Optimization

1. Data Fetching

2. Virtualization

3. SSR / ISR

IV. TanStack Query

1. Benefits vs useEffect

2. Stale vs Fresh Data

3. Invalidate Queries

V. Supabase

1. Core Features

2. Row-Level Security (RLS)

VI. PostgreSQL Essentials

1. Indexes

VII. Next.js 15 Advanced

1. Server Actions

2. Built-in Caching

3. State Management

VIII. React 19 Features

1. use() Hook

2. Suspense

3. React Compiler

IX. NestJS Concepts

1. Guards

2. Middleware

3. Interceptors

X. Design Patterns (Refactoring Guru style)

1. Singleton

2. Observer

3. Strategy

4. Decorator

5. Factory

6. Adapter

7. Proxy

8. Builder

XI. Practical Mixed Questions

✅ Solving Image Download with a Server-Side Proxy in Next.js

🧩 The Problem: CORS Restrictions When Downloading Images

❌ Typical Client-Side Approach Fails:

💡 The Solution: Server-Side Proxy

🛠️ Step-by-Step Implementation

1. Create a Proxy API Route: /api/download-image/route.ts

✅ Logic:

📄 Example: app/api/download-image/route.ts

2. Update the Frontend Download Function

✅ Function Example:

🔍 What This Does:

🧪 Example Usage

✅ Benefits Recap

📌 Conclusion

A Unified, Type-Safe Database Adapter System for Multi-DB Applications

Database Adapters System

Table of Contents

Overview

Architecture

Core Components

Supported Databases

1. Benefits vs `useEffect`

1. `use()` Hook

1. Create a Proxy API Route: `/api/download-image/route.ts`

📄 Example: `app/api/download-image/route.ts`