Why eridu-tech?
Designed from the ground up for real-world backend challenges — vendor-agnostic, composable and extendable, built on a unified foundation, and compatible with your framework of choice.
Switch infrastructure without rewriting business logic
The adapter pattern keeps your code decoupled from vendors. Use Redis today, Postgres tomorrow — no refactoring required.
Composable and extendable
Agnostic AOP-style middlewares and adapter plugins let you extend your own code or existing adapters with additional behavior that isn't included by default, keeping every component composable and extendable. Predefined plugins and middlewares are included out of the box.
Unified foundation
Every component is built on a single shared foundation, reusing common abstractions like Serde, Execution Context, and the AOP middleware system, so they work together seamlessly.
Bring your own framework
No DI container required. Plug directly into Express, NestJS, AdonisJS, Next.js, Nuxt, or TanStack Start — it just works.
Small runtime footprint
Every component is built from scratch in a modular way, keeping the runtime minimal with no framework or component baggage. Only the client libraries and drivers (Redis, Postgres, MongoDB, and more) are optional peer dependencies, installed when you need them.
Battery included
eridu-tech aims to be battery included, shipping a broad set of ready-to-use components and integrations out of the box so you can start building without wiring different libraries everything yourself.
Unified foundation
Serialize anything. Restore everything.
The Serde component provides a unified serialization and deserialization engine with fully type-safe schemas. It supports custom serializers for any type and includes a built-in SuperJSON adapter that handles Date, Map, Set, and BigInt out of the box. Serde is used internally across LockFactory, Cache, EventBus, and other components.
- Shared serialization engine used throughout Eridu-tech
- Powers LockFactory, Cache, EventBus, and more
- Built-in SuperJSON adapter — Date, Map, Set & BigInt out of the box
- Register custom serializers for your own types
npm install eridu-techThis example shows how a single Serde instance is shared across LockFactory and Cache. Acquire a lock, store it in the cache, and retrieve it — serialization and deserialization happen automatically.
- main.ts
- lock-factory.ts
- cache.ts
- serde.ts
import { lockFactory } from "./lock-factory.js";
import { cache } from "./cache.js";
// The LockFactory class uses Serde instance
// internally to register custom serialization logic
const lock = lockFactory.create("payment:order-42");
// The underlying RedisCacheAdapter uses by Cache class
// uses the Serde class to serialize and deserialize
// Will automatically serialize correctly
await cache.put(lock.key, lock);
// Will automatically deserialize correctly
const deserializedLock = await cache.get(lock.key);
import { LockFactory } from "eridu-tech/lock";
import { RedisLockAdapter } from "eridu-tech/lock/redis-lock-adapter";
import { serde } from "./serde.js";
export const lockFactory = new LockFactory({
adapter: new RedisLockAdapter(redis),
serde,
});
import { Cache } from "eridu-tech/cache";
import { RedisCacheAdapter } from "eridu-tech/cache/redis-cache-adapter";
import { serde } from "./serde.js";
export const cache = new Cache({
adapter: new RedisCacheAdapter({
database: redis,
serde,
}),
});
import { Serde } from "eridu-tech/serde";
import { SuperJsonSerdeAdapter } from "eridu-tech/serde/super-json-serde-adapter";
export const serde = new Serde(new SuperJsonSerdeAdapter());
Who is this for?
eridu-tech is built for backend and fullstack TypeScript developers who value flexibility and testability.
Perfect for
- Backend applications: Build REST APIs, background workers, CLIs, and backend other services using reusable, composable components.
- Framework-agnostic projects: Works with Express, Fastify, Hono, Next.js, Nuxt, SvelteKit, Cloudflare Workers, Bun, Deno, Node.js, and any runtime supporting the standard winter tc Fetch api.
- Adapter-first architectures: Switch between Redis, PostgreSQL, SQLite, MongoDB, S3, local storage, in-memory implementations, or your own adapters without changing business logic.
- Distributed systems: Use distributed locks, semaphores, shared locks, circuit breakers, rate limiters, caches, and event buses that work across multiple processes and machines.
- Modular monoliths: Share the same abstractions, middleware, and adapters across a single deployable application. Some components can be used in microservices, but the library is primarily designed for modular monolith architectures.
- Library and framework authors: Build reusable backend libraries on stable interfaces instead of coupling to specific vendors or infrastructure.
- Testing and local development: Use in-memory adapters for fast, deterministic tests, then swap to production infrastructure with configuration only.
- Portable backend code: Write infrastructure-independent code that can move between cloud providers, databases, storage providers, and runtimes with minimal changes.
- Adopting individual components: Use specific components without being forced to adopt the entire library or a DI container — each component works standalone.
- Incremental adoption: Start with a single component and gradually adopt more as your project grows.
Not ideal for
- Microservices: The library is designed for modular monoliths where components share the same process and runtime. While some components (like distributed locks, circuit breakers, and event buses) work across processes, the broader adapter model and shared abstractions are not optimized for microservice architectures.
- Frontend-only applications: eridu-tech is designed for backend and server-side development, not browser applications.
- Projects tightly coupled to one vendor: If your application intentionally depends on provider-specific features instead of abstractions, the adapter model may provide little benefit.
- Very small scripts: If you only need a single Redis call, file upload, or cache operation, the abstraction layer may be unnecessary overhead.
- Applications requiring provider-specific capabilities: Features unique to a particular database, cache, or cloud service may require using that provider's native SDK directly instead of a generic abstraction.
- Pure JavaScript projects prioritizing simplicity: While usable from JavaScript, the library is designed around TypeScript's type system, generics, and inference for the best developer experience.
Officially Maintained Components
A growing collection of officially maintained components. Every component ships with multiple built-in adapters — swap infrastructure without changing a single line of business logic.
🔮 Upcoming Components
Components currently in design or development — not yet available in any release.
Coordinate database transactions across components with the after-commit pattern. Foundation for reliable messaging — powers the Outbox, Inbox, Scheduler, and Notifications.
A unified API for defining and executing CLI commands with a transport adapter architecture. Run commands locally via child processes, remotely over SSH or HTTP, inside Docker containers, or through custom transports — all from the same command definition.
Run async tasks in structured scopes where child tasks are tied to their parent's lifetime — with automatic cancellation, error propagation, and resource cleanup.
A configurable promise queue to control the number of concurrently executing promises and prevent resource exhaustion.
Support for observability — logging, metrics, and tracing — with a pluggable adapter system. Pre-built adapters for OpenTelemetry and a local adapter that saves logs, traces, and metrics to disk.
Inspect the actual runtime state of any component through pre-built CLI commands — view registered handlers, active jobs, queue depth, lock holders, and more without digging into logs or metrics.
Schedule work with full flexibility — immediate dispatch, delayed execution, and recurring jobs. Uses Transaction Context for reliable execution.
How eridu-tech compares
A full framework with built-in DI vs a library that fits your needs.
- Opinionated framework with its own DI, decorators, and modules.
- Conventions wholesale: DI central, most primitives only work inside NestJS.
- NodeJS runtime only.
- Can't embed in a full-stack framework or host as one server.
- Not adapted for edge runtimes.
- Request-scoped only — no custom scopes.
- Wraps existing libs — BullMQ, cache-manager, class-validator, class-transformer, etc.
- Geared toward microservices and monoliths.
- No execution context flowing through all components.
- No shared serialization engine across components.
- No built-in transaction context.
- A library, not a framework — DI optional, no decorators, plain classes.
- Same cache/lock/event bus in any framework — no lock-in.
- Runs anywhere Winter TC runs — Node, Bun, Deno, edge.
- Edge-adaptable via the adapter pattern.
- Embeds in any full-stack framework — host as one server.
- Scope-agnostic — request, custom, or no scope.
- Own primitives with pluggable adapters — in-memory adapters for testing.
- Built for modular monoliths — swap infrastructure without rewriting logic.
- Execution context flowing through all components.
- Shared serialization engine (Serde) across components.
- Will have a transaction context.
Ready to build something great?
Get up and running in minutes with a single install.
npm install eridu-tech