eridu-tech — the backend infrastructure behind your Hono app

[yousif-khalil-abdulkarim]

eridu-tech is a collection of 17 composable backend infrastructure components for TypeScript — caching, locking, event buses, rate limiting, circuit breaking, file storage, and more — built around one idea:

Write business logic once. Replace infrastructure anytime.

It's not a replacement for Hono and not another HTTP framework. It's the layer that sits behind your Hono routes: the caches, locks, rate limiters, event buses, typed config, and resilience primitives your endpoints call into. Use Hono for lightweight routing and middleware — add eridu-tech for the reusable infrastructure those handlers need as your backend grows.

Links: GitHub · Docs · API reference · NPM

---

What problem does it solve?

Hono is excellent at routing, middleware, and running anywhere. But as an app's backend grows beyond simple CRUD, you keep reaching for the same things over and over: caches, distributed locks, rate limiting, circuit breakers, event buses, typed config and env access, retries and timeouts.

Those usually come from hand-rolled code or disconnected single-purpose libraries (each with its own API and conventions) — or you reach for a monolithic backend framework that wants to own your whole application and pulls you away from Hono.

eridu-tech sits in the middle:

• Batteries-included primitives that are individually useful and more powerful when composed.
• No lock-in — every component talks to interfaces, not to Redis, S3, or your HTTP framework directly.
• Incremental — start with one component (say, Cache) and add more only when you need them.

---

Why I built it

The origin is a concrete frustration: I wanted a NestJS-style backend architecture inside a full-stack framework like Next.js, and it didn't work — NestJS modules are tightly coupled to the NestJS runtime and DI container, so they're hard to reuse anywhere else.

That led to a simple design decision:

Backend architecture should not be locked to the framework that provides your HTTP layer.

So instead of building another framework, I built composable, framework-independent modules that plug into whatever HTTP layer you already chose — including Hono.

---

Design principles

1. Adapter-first — the application owns the architecture

Every module depends on a stable contract; infrastructure differences live behind adapters. A cache is a Cache whether it's Redis, an in-memory store, or MongoDB. Your business logic never imports a vendor SDK directly:

      Hono.js (routing, middleware, runtime)
                    │
                    ▼
        eridu-tech Module (Cache, Lock, EventBus, …)
                    │
              Interface / API
                    │
        ┌───────────┼───────────┐
        │           │           │
   Redis         Memory      MongoDB
  Adapter      Adapter      Adapter

2. Composable modules — useful alone, powerful together

Every eridu-tech module should be useful independently, but become more powerful when composed together.

The shared Serde engine shows this best: on its own it's a complete serialization library, but because Cache, LockFactory, and EventBus all accept the same Serde instance, they share one serialization engine — so a Lock object can be stored in the Cache and read back perfectly, with no glue code between components.

3. Frameworks are integration points, not boundaries

Hono handles HTTP; eridu-tech handles the infrastructure behind the endpoints. One choice shouldn't prevent another:

Frontend / Client
       │
       ▼
       Hono.js
       │
       ▼
   eridu-tech
       │
Cache • Locks • Rate limiting • Events • Config • Resilience

4. Unified architecture

Components are independent but share a consistent architecture — no glue code:

• A single serialization engine (Serde) across Cache, LockFactory, EventBus, and more.
• A single execution context — async context propagation (request IDs, user info, transactions) flows through context-aware components.
• Composable middleware — AOP-style retry, timeout, fallback that work across every component.
• Typed domain configuration — ConfigAccessor provides a standardized, type-safe way to read domain configuration variables, with optional schema validation.
• Typed environment access — EnvAccessor provides type-safe environment variable access from any source (process.env, secrets managers, and more), with optional schema validation.

---

Key features

• Switch infrastructure without rewriting business logic — use Redis today, MongoDB tomorrow, no refactoring.
• Test everything without Docker — in-memory adapters + built-in Vitest helpers on every component.
• Bring your own framework — no DI container required; drops into Hono, Next.js, Express, and more.
• Type-safe from day one — precise generics, rich intellisense, errors caught at compile time.
• Standard Schema validation built in — use Zod, Valibot, or ArkType for compile-time and runtime safety.
• ESM native — works on Node.js, Bun, Deno, and Cloudflare Workers.

---

A quick taste

A Hono app where the route handler uses an eridu-tech cache — same API in tests (memory) and production (Redis):

import { Hono } from "hono";
import { CacheResolver } from "eridu-tech/cache";
import { MemoryCacheAdapter } from "eridu-tech/cache/memory-cache-adapter";
import { RedisCacheAdapter } from "eridu-tech/cache/redis-cache-adapter";
import { Serde } from "eridu-tech/serde";
import { SuperJsonSerdeAdapter } from "eridu-tech/serde/super-json-serde-adapter";

const app = new Hono();
const serde = new Serde(new SuperJsonSerdeAdapter());

const cache = new CacheResolver({
    adapters: {
        memory: new MemoryCacheAdapter(), // tests
        redis: new RedisCacheAdapter({ database: redis, serde }), // production
    },
    defaultAdapter: "memory",
});

app.get("/users/:id", async (c) => {
    const id = c.req.param("id");
    const cached = await cache.use().get(`user:${id}`);
    if (cached) return c.json(cached);

    const user = await loadUser(id);
    await cache.use().add(`user:${id}`, user);
    return c.json(user);
});

---

Components available today (17)

Category	Components
Foundation	Middleware & AOP · Collection · Serde · Codec · Execution Context · Typed Config Access · Typed Env Access
Storage	Cache · File Storage
Resilience	Circuit Breaker · Rate Limiter · Resilience (timeout/fallback/retry)
Concurrency	Lock · Shared Lock · Semaphore
Messaging	Event Bus

Every component ships with multiple built-in adapters (in-memory, Redis, S3, local disk, and more) and its own in-memory testing adapter.

View all component docs →

---

Getting started

npm install eridu-tech

---

Closing thoughts

Hono already solved "lightweight HTTP." The question I keep asking is: what do you reach for when the backend behind those routes grows complex? My answer was a set of composable building blocks with adapters — so you never have to leave Hono to get caching, locking, rate limiting, and the rest.

I'd love feedback — especially from people running growing backends on Hono. What infrastructure do you reach for first? What's missing? I'm happy to discuss trade-offs (abstraction layers aren't free). ⭐ Starring the repo also helps others discover it.