@xemahq/blob-storage

Backend-agnostic blob storage for NestJS services

Overview

A single BlobStorage abstraction over S3-compatible stores and Azure Blob Storage. Consumers depend only on the interface — put, get, delete, and prefix-delete objects — while the concrete adapter is selected by configuration and injected at boot. Switching backends never touches consumer code.

When to use it

• Use it when a NestJS service needs object storage but should not be coupled to a specific S3 or Azure SDK.

Installation

pnpm add @xemahq/blob-storage

Usage

import { BlobStorageModule, BlobStorage } from '@xemahq/blob-storage';

@Module({ imports: [BlobStorageModule.forRoot(options)] })
export class AppModule {}

// Then inject BlobStorage and read/write objects:
await storage.put(container, key, body);
const obj = await storage.getBuffer(container, key);

A service usually declares only its own logical containers and reads the rest of the configuration from the environment, so it never restates which variables each backend needs:

import {
  BlobStorageModule,
  blobStorageOptionsFromEnv,
} from '@xemahq/blob-storage';

BlobStorageModule.forRootAsync({
  imports: [ConfigModule],
  inject: [ConfigService],
  useFactory: (config: ConfigService) =>
    blobStorageOptionsFromEnv((name) => config.get<string>(name), {
      declaredContainers: ['uploads'],
    }),
});

The reader is a plain function, so plain Node ((name) => process.env[name]) and tests work the same way. BLOB_STORAGE_ENV_VARS names every variable it reads.

Peer requirements

• @nestjs/common >= 10
• @nestjs/core >= 10
• reflect-metadata >= 0.1.13
• rxjs >= 7

License

Apache-2.0 © Xema — xema.dev