eridu-tech — the backend infrastructure behind your TanStack Start 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 TanStack Start — keep using its server functions and API routes. eridu-tech provides the backend infrastructure behind them: caches, locks, rate limiters, event buses, typed config, and resilience primitives. While TanStack Start's API routes don't ship built-in request/response validation, you can optionally use eridu-tech's HttpRouter instead — typed endpoints, schema validation, and a ready-made middleware chain, all framework-agnostic. Keep TanStack Start for the app layer; add eridu-tech when the backend behind those routes grows complex.

Links: GitHub · Docs · API reference · NPM

---

What problem does it solve?

TanStack Start is great at routing, rendering, and deployment (with Vinxi under the hood) — but as the backend of an app grows beyond simple CRUD, you keep reaching for the same infrastructure over and over: caches, distributed locks, rate limiting, circuit breakers, event buses, typed config and env access, retries and timeouts.

Those pieces usually come from hand-rolled code or disconnected single-purpose libraries, each with its own conventions. Or you reach for a monolithic backend framework that doesn't fit well inside a full-stack app. Some teams even split the backend into a separate service — hosted and deployed on its own, sometimes in another repository — which usually means setting up a monorepo. That can become a real headache when you just want to develop fast.

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 as 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 full-stack framework you already chose.

---

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:

     TanStack Start (Vinxi — routing, rendering)
                        │
                        ▼
        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

TanStack Start handles the app layer; eridu-tech handles the backend — routing via HttpRouter, plus caching, locking, events, and more:

Frontend / Client
       │
       ▼
TanStack Start
       │
       ▼
   eridu-tech
       │
HttpRouter • 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 TanStack Start, Next.js, Nuxt, Hono, 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

TanStack Start's server functions are your RPC layer — eridu-tech provides the backend infrastructure behind them, with the same API in tests (memory) and production (Redis):

import { createServerFn, standardSchemaValidator } from "@tanstack/react-start";
import { z } from "zod";
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 serde = new Serde(new SuperJsonSerdeAdapter());

// eridu-tech infrastructure behind the RPC
const cache = new CacheResolver({
    adapters: {
        memory: new MemoryCacheAdapter(), // tests
        redis: new RedisCacheAdapter({ database: redis, serde }), // production
    },
    defaultAdapter: "memory",
});

const getUser = createServerFn({ method: "GET" })
    .validator(standardSchemaValidator(z.object({ id: z.string() })))
    .handler(async ({ data }) => {
        const cached = await cache.use().get(`user:${data.id}`);
        if (cached) return cached;

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

TanStack Start defines what the API looks like; eridu-tech provides how the backend behaves — caching, rate limiting, locking, events — behind a consistent, swappable interface.

The architecture: TanStack Start owns the app; eridu-tech owns the backend — caching, locking, events, and more behind your server functions, all swappable independently. Prefer typed, framework-agnostic HTTP routing? The optional HttpRouter component plugs right in.

---

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
Web	HTTP Router (Winter TC compatible, built on the Hono router engine)

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

TanStack Start already solved "build the whole app in one codebase." 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 can grow a heavy backend directly inside TanStack Start without switching to a separate backend framework.

I'd love feedback — especially from people building growing backends with TanStack Start. 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.