packages/shared — Shared Utilities & Config

This package contains shared utilities, configuration, and helper functions used across microservices and the frontend.

Purpose

• Centralize reusable code to avoid duplication
• Provide common configs (Swagger, DB indexes) and utilities (logging, error handling)
• Re-export service-level helpers where appropriate

Quick Usage

Import what you need from the package. Below are recommended patterns for both monorepo development and when the package is published to npm.

Common utilities

// Node / TypeScript (logger, config, helpers)
import { logInfo, logError } from '@vivek2tamrakar/multitenents/logger';
import { createSwaggerSpec } from '@vivek2tamrakar/multitenents/config/swagger';

Tenant connection — two ways to use

1. Use the wrapper directly (recommended for most code)

// Import the wrapper which provides async helpers that forward to the implementation
import {
  getTenantPrisma,
  releaseTenantPrisma,
  getConnectionConfig
} from '@vivek2tamrakar/multitenents/tenantConnection';

// Example usage (async)
await (async () => {
  const tenantPrisma = await getTenantPrisma('tenant-id');
  // use tenantPrisma
  await releaseTenantPrisma('tenant-id');
})();

Notes: the wrapper will attempt to auto-load a packaged canonical implementation when present. If the package was installed from npm and the implementation is not bundled, you must register an implementation explicitly as shown next.

2. Import the canonical implementation and register it (explicit bootstrap — required for services deployed individually)

// service startup (run this once before tenant middleware runs)
import { setTenantConnectionImplementation } from '@vivek2tamrakar/multitenents/tenantConnection';
import impl from '@vivek2tamrakar/multitenants/tenant-impl'; // subpath export included in this package

setTenantConnectionImplementation(impl);

Why register explicitly?

• When services are published and deployed individually, the package may not contain repository-specific service files. Calling setTenantConnectionImplementation ensures the wrapper has the correct implementation registered at runtime.

Notes:

• Many helpers re-export code from services/shared (keeps single source of truth)
• Prefer the exported package paths above rather than importing service internals directly
• If you need help wiring this in a specific service (e.g., auth-service), I can add the tiny bootstrap file and import it in src/index.js for you.

Production connection recommendations 🔧

Add the following environment variables to each service's deployment (recommended defaults shown):

# Tenant connection / pooling (production-safe defaults)
MAX_CACHED_CLIENTS=1
SERVICE_MAX_CONNECTIONS=2
IDLE_TIMEOUT=300000         # 5 minutes
AGGRESSIVE_CLEANUP=false
REQUEST_CLEANUP_DELAY=5000

Notes:

• These conservative settings assume either a small number of service replicas, or a connection pooler (PgBouncer) / Prisma Data Proxy in front of your DB. If you run many replicas, lower SERVICE_MAX_CONNECTIONS or add a pooler.
• Ensure DATABASE_URL contains a connection limit for tenant clients (e.g., ?schema=<schema>&connection_limit=2) — the tenant manager sets this automatically.
• Monitor DB connections (pg_stat_activity) and adjust SERVICE_MAX_CONNECTIONS and the number of replicas accordingly.

Prisma Data Proxy (optional, recommended for multi-process scale) 💠

Prisma Data Proxy removes the need to manage database connections across many Node processes by routing queries through Prisma's managed proxy. To enable Data Proxy:

1. Create a project on Prisma Data Platform and add a Data Proxy for the project.
2. Copy the Data Proxy connection string (it looks like a proxy URL provided by Prisma).
3. In your deployment, set the DATABASE_URL to the Data Proxy URL and set the client engine type if required:

DATABASE_URL=<PRISMA_DATA_PROXY_URL>
# Optional (some Prisma versions):
PRISMA_CLIENT_ENGINE_TYPE=dataproxy

4. Redeploy services — the tenant manager will append schema and connection_limit query params to the Data Proxy URL automatically.

Notes and caveats:

• Data Proxy handles connection pooling centrally so you can safely run many replicas without exhausting DB connections. Monitor Data Proxy metrics and adjust as needed.
• If you prefer a self-hosted option, deploy PgBouncer and point your services' DATABASE_URL to PgBouncer's address instead.

If you'd like, I can help set up Data Proxy for your project or add a sample PgBouncer docker-compose to your infra.

Files of Interest

• config/ — Swagger, other shared configs
• utils/ — Error handling, health checks, cache helpers
• database/ — DB index helpers

Contributing

• Add new utilities under packages/shared/*
• Write unit tests and documentation in packages/shared/README.md
• Keep exports stable and avoid breaking changes

Short and focused README for quick reference. See root DOCUMENTATION.md for full operational docs.