eridu-tech — the backend infrastructure behind your SolidStart 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 SolidStart — keep using its API routes and server functions. eridu-tech provides the backend infrastructure behind them: caches, locks, rate limiters, event buses, typed config, and resilience primitives. While SolidStart'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 SolidStart 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?

SolidStart is great at routing, rendering, and deployment — 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:

       SolidStart (routing, rendering, deployment)
                        │
                        ▼
        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

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

Frontend / Client
       │
       ▼
  SolidStart
       │
       ▼
   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 SolidStart, 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

eridu-tech's HttpRouter implements the Winter TC fetch standard, so it plugs straight into SolidStart API routes (which support fetch handlers natively). Full-stack frameworks often ship bare-bones routing for backend work — HttpRouter adds the missing layer with typed endpoints, schema-based request validation, and middleware chains, all framework-agnostic. Your routes + infrastructure are framework-independent; only the glue differs:

// src/routes/api/[...route].ts
import {
    HttpRouter,
    defaultHttpRouterAdapter,
} from "eridu-tech/http-router";
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";
import type { APIEvent } from "@solidjs/start/server";

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

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

const router = new HttpRouter({ router: defaultHttpRouterAdapter });

router.endpoint({
    url: "/api/users/:id",
    method: "GET",
    handler: async ({ req, json }) => {
        const { id } = req.rawParams();
        const cached = await cache.use().get(`user:${id}`);
        if (cached) return json(cached);

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

// SolidStart glue — native fetch handlers
export const GET = ({ request }: APIEvent) => router.fetch(request);
export const HEAD = ({ request }: APIEvent) => router.fetch(request);
export const POST = ({ request }: APIEvent) => router.fetch(request);
export const PUT = ({ request }: APIEvent) => router.fetch(request);
export const PATCH = ({ request }: APIEvent) => router.fetch(request);
export const DELETE = ({ request }: APIEvent) => router.fetch(request);
export const OPTIONS = ({ request }: APIEvent) => router.fetch(request);

The architecture: SolidStart owns the app; eridu-tech owns the backend — HttpRouter for typed, framework-agnostic routing, plus caching, locking, and events — all swappable independently.

---

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

SolidStart 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 SolidStart without switching to a separate backend framework.

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