@dojocho/effect-ts 0.0.1

package/katas/037-cache-and-memoization/SENSEI.md

@@ -0,0 +1,73 @@
+# SENSEI — 037 Cache and Memoization
+
+## Briefing
+
+### Goal
+
+Learn to use Effect's `Cache` module to memoize effectful computations with capacity limits and time-to-live expiration.
+
+### Tasks
+
+1. Implement `makeUserCache` -- create a `Cache` with capacity 100 and 1-minute TTL using `Cache.make`
+2. Implement `cachedLookup` -- retrieve a value from the cache by key
+3. Implement `demonstrateCaching` -- combine a `Ref` counter with a cache to prove the lookup runs only once for repeated gets
+
+### Hints
+
+```ts
+import { Cache, Duration, Effect, Ref } from "effect";
+
+// Cache.make takes capacity, TTL, and a lookup function
+const cache = Cache.make({
+  capacity: 100,
+  timeToLive: Duration.minutes(1),
+  lookup: (key: string) => Effect.succeed(`value:${key}`),
+});
+
+// cache.get triggers the lookup on first call, returns cached on subsequent calls
+const value = cache.pipe(Effect.flatMap((c) => c.get("myKey")));
+
+// Ref for counting
+const counter = Ref.make(0);
+// Ref.update increments, Ref.get reads the current value
+```
+
+## Prerequisites
+
+- **005 Pipe Composition** -- `pipe`, `Effect.flatMap`
+- **019 Ref and State** -- `Ref.make`, `Ref.update`, `Ref.get`
+- **003 Generator Pipelines** -- `Effect.gen`, `yield*`
+
+## Test Map
+> **Note**: `Effect.runPromise` appears only in tests. Never attribute it to the user's learning.
+
+| Test | Concept | Verifies |
+|------|---------|----------|
+| `makeUserCache creates a cache` | `Cache.make` | Cache construction with capacity and TTL |
+| `cachedLookup returns the computed value` | `cache.get` | First lookup triggers computation |
+| `cachedLookup returns same value on repeated calls` | Cache memoization | Second lookup returns cached value, lookup count stays at 1 |
+| `demonstrateCaching returns same value and only computes once` | `Ref` + `Cache` composition | End-to-end proof that caching prevents redundant computation |
+
+## Teaching Approach
+
+### Socratic prompts
+
+- "`Cache.make` takes a `lookup` function that returns an `Effect`. Why must the lookup be effectful rather than a plain function?"
+- "If you call `cache.get(\"alice\")` twice, the second call returns instantly. But what if the first call is still in-flight when the second arrives -- what should happen?"
+- "The `demonstrateCaching` function needs to count how many times the lookup runs. You cannot use a mutable `let` variable inside an Effect pipeline. What Effect primitive lets you track mutable state safely?"
+
+### Common pitfalls
+
+1. **Forgetting that `Cache.make` returns an Effect** -- `Cache.make(...)` does not give you a cache directly; it gives you an `Effect<Cache<...>>`. You need to `yield*` or `flatMap` to get the actual cache. Ask: "What type does `Cache.make` return?"
+2. **Using `cache.get` without understanding the lookup signature** -- the lookup function in `Cache.make` receives the key and must return an `Effect`. Students sometimes try to pass a synchronous function. Nudge: "Wrap your computation in `Effect.sync` or `Effect.succeed`."
+3. **Counting calls with a plain variable** -- inside `Effect.gen`, a `let count = 0` will not work across multiple effect runs. Use `Ref.make(0)` and `Ref.update` to track state within the Effect world.
+
+## On Completion
+
+### Insight
+
+`Cache` is a concurrency-safe, effectful memoization primitive. Unlike a simple `Map`, it handles concurrent requests for the same key by sharing the in-flight computation rather than duplicating work. The TTL and capacity parameters give you automatic eviction without manual cleanup. This is the Effect way of caching: declarative configuration, automatic lifecycle, and safe concurrency -- all managed by the runtime rather than hand-rolled logic.
+
+### Bridge
+
+You have learned to cache expensive computations. Kata 038 introduces `Metric` -- counters, histograms, and gauges that let you observe what your application is doing at runtime. Metrics and caching often work together: you might track cache hit rates with a counter.

package/katas/037-cache-and-memoization/solution.test.ts

@@ -0,0 +1,47 @@
+import { Effect } from "effect";
+import { describe, expect, it } from "vitest";
+import {
+  makeUserCache,
+  cachedLookup,
+  demonstrateCaching,
+} from "@/katas/037-cache-and-memoization/solution.js";
+
+describe("037 — Cache and Memoization", () => {
+  it("makeUserCache creates a cache", async () => {
+    const cache = await Effect.runPromise(
+      makeUserCache((key) => Effect.succeed(`user:${key}`)),
+    );
+    expect(cache).toBeDefined();
+  });
+
+  it("cachedLookup returns the computed value", async () => {
+    const cache = await Effect.runPromise(
+      makeUserCache((key) => Effect.succeed(`user:${key}`)),
+    );
+    const result = await Effect.runPromise(cachedLookup(cache, "alice"));
+    expect(result).toBe("user:alice");
+  });
+
+  it("cachedLookup returns same value on repeated calls", async () => {
+    let callCount = 0;
+    const cache = await Effect.runPromise(
+      makeUserCache((key) =>
+        Effect.sync(() => {
+          callCount++;
+          return `user:${key}`;
+        }),
+      ),
+    );
+    const r1 = await Effect.runPromise(cachedLookup(cache, "bob"));
+    const r2 = await Effect.runPromise(cachedLookup(cache, "bob"));
+    expect(r1).toBe("user:bob");
+    expect(r2).toBe("user:bob");
+    expect(callCount).toBe(1);
+  });
+
+  it("demonstrateCaching returns same value and only computes once", async () => {
+    const [r1, r2, count] = await Effect.runPromise(demonstrateCaching());
+    expect(r1).toBe(r2);
+    expect(count).toBe(1);
+  });
+});

package/katas/037-cache-and-memoization/solution.ts

@@ -0,0 +1,24 @@
+import { Cache, Duration, Effect } from "effect";
+
+/** Create a cache with the given lookup function, capacity 100, TTL 5 minutes */
+export const makeUserCache = (
+  lookup: (key: string) => Effect.Effect<string>,
+): Effect.Effect<Cache.Cache<string, never, string>> => {
+  throw new Error("Not implemented");
+};
+
+/** Look up a key in the cache */
+export const cachedLookup = (
+  cache: Cache.Cache<string, never, string>,
+  key: string,
+): Effect.Effect<string> => {
+  throw new Error("Not implemented");
+};
+
+/** Demonstrate that two lookups for the same key only call the function once
+ * Return [result1, result2, callCount] */
+export const demonstrateCaching = (): Effect.Effect<
+  [string, string, number]
+> => {
+  throw new Error("Not implemented");
+};

package/katas/038-metrics/SENSEI.md

@@ -0,0 +1,91 @@
+# SENSEI — 038 Metrics
+
+## Briefing
+
+### Goal
+
+Learn to define and use Effect's built-in metric primitives: counters, histograms, and gauges.
+
+### Tasks
+
+1. Define `requestCount` as a counter metric named `"request_count"`
+2. Define `responseTime` as a histogram metric named `"response_time"` with boundaries `[10, 50, 100, 500]`
+3. Define `activeConnections` as a gauge metric named `"active_connections"`
+4. Implement `countRequest` -- increment the counter and return `"counted"`
+5. Implement `recordTime` -- record a value in the histogram and return `"recorded"`
+6. Implement `setConnections` -- set the gauge to a value and return `"set"`
+
+### Hints
+
+```ts
+import { Effect, Metric, MetricBoundaries } from "effect";
+
+// Counter: tracks cumulative totals
+const myCounter = Metric.counter("my_counter");
+
+// Histogram: tracks distribution of values
+const myHistogram = Metric.histogram(
+  "my_histogram",
+  MetricBoundaries.fromIterable([10, 50, 100]),
+);
+
+// Gauge: tracks current value
+const myGauge = Metric.gauge("my_gauge");
+
+// Increment a counter
+const inc = Metric.increment(myCounter); // Effect<void>
+
+// Record a value in a histogram
+const record = Metric.update(myHistogram, 42); // Effect<void>
+
+// Set a gauge
+const set = Metric.set(myGauge, 5); // Effect<void>
+
+// Chain with a return value
+const withResult = Effect.as(Metric.increment(myCounter), "done");
+```
+
+## Prerequisites
+
+- **001 Hello Effect** -- `Effect.succeed`, `Effect.map`
+- **028 Logging and Spans** -- observability concepts
+
+## Skills
+
+Invoke `effect-patterns-observability` before teaching this kata.
+
+## Test Map
+> **Note**: `Effect.runPromise` appears only in tests. Never attribute it to the user's learning.
+
+| Test | Concept | Verifies |
+|------|---------|----------|
+| `requestCount is a counter` | `Metric.counter` | Counter metric is defined |
+| `responseTime is a histogram` | `Metric.histogram` | Histogram metric is defined with boundaries |
+| `activeConnections is a gauge` | `Metric.gauge` | Gauge metric is defined |
+| `countRequest increments counter and returns 'counted'` | `Metric.increment` + `Effect.as` | Counter increment produces a value |
+| `recordTime records a value and returns 'recorded'` | `Metric.update` | Histogram records a measurement |
+| `setConnections sets gauge and returns 'set'` | `Metric.set` | Gauge is set to an absolute value |
+
+## Teaching Approach
+
+### Socratic prompts
+
+- "A counter only goes up (or tracks a running total). A gauge can go up or down. When would you use one versus the other?"
+- "`Metric.histogram` requires boundaries like `[10, 50, 100, 500]`. What do these boundaries represent, and why do you choose them upfront?"
+- "`Metric.increment` returns `Effect<void>`. How do you chain it with another effect so the overall result is `'counted'` instead of `void`?"
+
+### Common pitfalls
+
+1. **Histogram needs `MetricBoundaries`, not a raw array** -- `Metric.histogram` expects a `MetricBoundaries` value, not `number[]`. Use `MetricBoundaries.fromIterable([10, 50, 100, 500])` to convert. Ask: "What type does the second argument of `Metric.histogram` expect?"
+2. **Returning a value after a void effect** -- `Metric.increment` returns `Effect<void>`. To return `"counted"`, use `Effect.as(effect, "counted")` or `Effect.map(effect, () => "counted")`. Students often forget to chain the return value.
+3. **Confusing `Metric.update` and `Metric.set`** -- `update` records an observation (for histograms and counters). `set` sets the current value (for gauges). Using the wrong one will not type-check or will produce unexpected behavior.
+
+## On Completion
+
+### Insight
+
+Effect metrics are not just numbers you log -- they are first-class values in the effect system. A `Metric.counter` is a reusable definition that you reference by name, and every time you call `Metric.increment`, the runtime records the observation. The boundaries in a histogram determine the buckets that aggregate your data, which is why you choose them based on your expected value distribution. Because metrics are effects, they compose naturally with your application logic -- no separate instrumentation library, no global state, just pipe and go.
+
+### Bridge
+
+You have learned to observe your application with metrics. Kata 039 introduces `ManagedRuntime` -- a way to create a pre-configured runtime with your services baked in, useful for integrating Effect into existing applications or running effects outside the normal Effect entry point.

package/katas/038-metrics/solution.test.ts

@@ -0,0 +1,39 @@
+import { Effect } from "effect";
+import { describe, expect, it } from "vitest";
+import {
+  requestCount,
+  responseTime,
+  activeConnections,
+  countRequest,
+  recordTime,
+  setConnections,
+} from "@/katas/038-metrics/solution.js";
+
+describe("038 — Metrics", () => {
+  it("requestCount is a counter", () => {
+    expect(requestCount).toBeDefined();
+  });
+
+  it("responseTime is a histogram", () => {
+    expect(responseTime).toBeDefined();
+  });
+
+  it("activeConnections is a gauge", () => {
+    expect(activeConnections).toBeDefined();
+  });
+
+  it("countRequest increments counter and returns 'counted'", async () => {
+    const result = await Effect.runPromise(countRequest);
+    expect(result).toBe("counted");
+  });
+
+  it("recordTime records a value and returns 'recorded'", async () => {
+    const result = await Effect.runPromise(recordTime(42));
+    expect(result).toBe("recorded");
+  });
+
+  it("setConnections sets gauge and returns 'set'", async () => {
+    const result = await Effect.runPromise(setConnections(5));
+    expect(result).toBe("set");
+  });
+});

package/katas/038-metrics/solution.ts

@@ -0,0 +1,23 @@
+import { Effect, Metric, MetricBoundaries } from "effect";
+
+/** Create a counter metric named "request_count" */
+export const requestCount: Metric.Metric.Counter<number> = undefined as any;
+
+/** Create a histogram metric named "response_time" with boundaries [10, 50, 100, 500, 1000] */
+export const responseTime: Metric.Metric.Histogram<number> = undefined as any;
+
+/** Create a gauge metric named "active_connections" */
+export const activeConnections: Metric.Metric.Gauge<number> = undefined as any;
+
+/** Increment the counter and return "counted" */
+export const countRequest: Effect.Effect<string> = Effect.fail("Not implemented") as any;
+
+/** Record a value in the histogram and return "recorded" */
+export const recordTime = (ms: number): Effect.Effect<string> => {
+  throw new Error("Not implemented");
+};
+
+/** Set the gauge value and return "set" */
+export const setConnections = (n: number): Effect.Effect<string> => {
+  throw new Error("Not implemented");
+};

package/katas/039-managed-runtime/SENSEI.md

@@ -0,0 +1,75 @@
+# SENSEI — 039 Managed Runtime
+
+## Briefing
+
+### Goal
+
+Learn to create and manage a pre-configured Effect runtime with services baked in, using `ManagedRuntime`.
+
+### Tasks
+
+1. Implement `makeRuntime` -- create a `ManagedRuntime` from the `GreeterLive` layer using `ManagedRuntime.make`
+2. Implement `greetWith` -- use `runtime.runSync` to execute an effect that accesses the `Greeter` service
+3. Implement `fullLifecycle` -- create a runtime, run an effect with `runtime.runPromise`, then `dispose` the runtime
+
+### Hints
+
+```ts
+import { Context, Effect, Layer, ManagedRuntime } from "effect";
+
+// ManagedRuntime.make takes a Layer and returns a ManagedRuntime
+const runtime = ManagedRuntime.make(MyServiceLive);
+
+// runtime.runSync executes an effect synchronously
+const result = runtime.runSync(
+  Effect.gen(function* () {
+    const svc = yield* MyService;
+    return svc.doSomething();
+  }),
+);
+
+// runtime.runPromise executes an effect as a Promise
+const promise = runtime.runPromise(myEffect);
+
+// runtime.dispose() cleans up resources (returns Promise<void>)
+await runtime.dispose();
+```
+
+## Prerequisites
+
+- **011 Services and Context** -- `Context.Tag`, service definitions
+- **012 Layers** -- `Layer.succeed`, providing services
+
+## Test Map
+> **Note**: `runtime.runSync`, `runtime.runPromise`, and `runtime.dispose` are the APIs under test. They are part of the `ManagedRuntime` interface, not test-only helpers.
+
+| Test | Concept | Verifies |
+|------|---------|----------|
+| `makeRuntime creates a runtime` | `ManagedRuntime.make` | Runtime construction from a layer |
+| `greetWith runs an effect using the runtime` | `runtime.runSync` | Synchronous execution with service access |
+| `greetWith works with different names` | `runtime.runSync` | Runtime is reusable across multiple calls |
+| `fullLifecycle creates, uses, and disposes runtime` | `runtime.runPromise` + `dispose` | Complete lifecycle: create, use, clean up |
+
+## Teaching Approach
+
+### Socratic prompts
+
+- "In previous katas you used `Effect.runSync` and `Effect.provide` to supply services. `ManagedRuntime` bakes the layer in at construction time. When would pre-configuring a runtime be more convenient than providing layers each time?"
+- "`runtime.runSync` executes an effect but does not require you to call `Effect.provide`. Where did the service come from?"
+- "`runtime.dispose()` returns a `Promise<void>`. Why does disposing a runtime need to be asynchronous? What kind of cleanup might it perform?"
+
+### Common pitfalls
+
+1. **Forgetting to dispose the runtime** -- `ManagedRuntime` allocates resources when created. If you never call `dispose()`, those resources leak. In tests, always dispose in a finally block or after assertions. Ask: "What happens to the layer's resources if you never call dispose?"
+2. **Trying to use `Effect.runSync` instead of `runtime.runSync`** -- the global `Effect.runSync` does not have access to the services in the managed runtime. You must call `runtime.runSync(effect)` to execute with the pre-configured context. Nudge: "Who owns the service layer -- the global runtime or your managed runtime?"
+3. **Async confusion in fullLifecycle** -- `runtime.runPromise` returns a `Promise`, and `runtime.dispose()` also returns a `Promise`. You need to await both in sequence. Students may forget to chain the dispose after getting the result.
+
+## On Completion
+
+### Insight
+
+`ManagedRuntime` bridges Effect with the outside world. In a typical Effect application, you compose everything as effects and run once at the top level. But in real-world scenarios -- React components, Express handlers, CLI tools -- you often need to run effects from non-Effect code. `ManagedRuntime` gives you a pre-configured entry point: create it once with your service layers, call `runSync` or `runPromise` wherever you need, and `dispose` when you are done. It is the escape hatch that makes Effect practical in mixed codebases.
+
+### Bridge
+
+You now know how to create and manage runtimes. Kata 040 introduces request batching -- a powerful optimization where multiple concurrent data requests are automatically grouped into a single batch call, reducing round trips and improving throughput.

package/katas/039-managed-runtime/solution.test.ts

@@ -0,0 +1,29 @@
+import { describe, expect, it } from "vitest";
+import { makeRuntime, greetWith, fullLifecycle } from "@/katas/039-managed-runtime/solution.js";
+
+describe("039 — Managed Runtime", () => {
+  it("makeRuntime creates a runtime", async () => {
+    const runtime = makeRuntime();
+    expect(runtime).toBeDefined();
+    await runtime.dispose();
+  });
+
+  it("greetWith runs an effect using the runtime", async () => {
+    const runtime = makeRuntime();
+    const result = greetWith(runtime, "Alice");
+    expect(result).toBe("Hello, Alice!");
+    await runtime.dispose();
+  });
+
+  it("greetWith works with different names", async () => {
+    const runtime = makeRuntime();
+    expect(greetWith(runtime, "Bob")).toBe("Hello, Bob!");
+    expect(greetWith(runtime, "Charlie")).toBe("Hello, Charlie!");
+    await runtime.dispose();
+  });
+
+  it("fullLifecycle creates, uses, and disposes runtime", async () => {
+    const result = await fullLifecycle("World");
+    expect(result).toBe("Hello, World!");
+  });
+});

package/katas/039-managed-runtime/solution.ts

@@ -0,0 +1,19 @@
+import { Effect, Layer, ManagedRuntime } from "effect";
+
+/** Create a managed runtime with an empty layer */
+export const makeRuntime = (): ManagedRuntime.ManagedRuntime<never, never> => {
+  throw new Error("Not implemented");
+};
+
+/** Run an effect synchronously using the managed runtime to greet the given name */
+export const greetWith = (
+  runtime: ManagedRuntime.ManagedRuntime<never, never>,
+  name: string,
+): string => {
+  throw new Error("Not implemented");
+};
+
+/** Create a runtime, use it to greet, dispose it, return the greeting */
+export const fullLifecycle = async (name: string): Promise<string> => {
+  throw new Error("Not implemented");
+};

package/katas/040-request-batching/SENSEI.md

@@ -0,0 +1,87 @@
+# SENSEI — 040 Request Batching
+
+## Briefing
+
+### Goal
+
+Learn to define requests, build batched resolvers, and use Effect's automatic request batching to collapse multiple concurrent data fetches into a single batch call.
+
+### Tasks
+
+1. Observe the `GetUser` request type and its `Request.tagged` constructor -- these are defined for you
+2. Implement `makeUserResolver` -- use `RequestResolver.makeBatched` to create a resolver that batch-fetches users
+3. Implement `getUser` -- use `Effect.request` to create an effect that fetches one user
+4. Implement `getUsers` -- use `Effect.forEach` with `{ batching: true }` to fetch multiple users, triggering automatic batching
+
+### Hints
+
+```ts
+import { Effect, Request, RequestResolver } from "effect";
+
+// RequestResolver.makeBatched receives all requests in a single batch
+const resolver = RequestResolver.makeBatched(
+  (requests: NonEmptyArray<MyRequest>) =>
+    Effect.gen(function* () {
+      const ids = requests.map((r) => r.id);
+      const results = yield* fetchBatch(ids);
+      // Complete each request individually
+      for (const req of requests) {
+        const value = results.get(req.id);
+        if (value !== undefined) {
+          yield* Request.succeed(req, value);
+        } else {
+          yield* Request.fail(req, "not found");
+        }
+      }
+    }),
+);
+
+// Effect.request creates an effect from a request + resolver
+const fetchOne = Effect.request(GetUser({ id: 1 }), resolver);
+
+// Effect.forEach with batching groups requests into batches
+const fetchMany = Effect.forEach(ids, (id) =>
+  Effect.request(GetUser({ id }), resolver),
+  { batching: true },
+);
+```
+
+## Prerequisites
+
+- **017 Parallel Effects** -- `Effect.all`, parallel execution
+- **011 Services and Context** -- service patterns, dependency injection
+- **003 Generator Pipelines** -- `Effect.gen`, `yield*`
+
+## Test Map
+> **Note**: `Effect.runPromise` and `Effect.either` appear only in tests. Never attribute them to the user's learning.
+
+| Test | Concept | Verifies |
+|------|---------|----------|
+| `getUser fetches a single user` | `Effect.request` | Single request goes through resolver |
+| `getUser fails for unknown id` | `Request.fail` | Resolver correctly fails missing requests |
+| `getUsers fetches multiple users` | `Effect.forEach` + batching | Multiple requests return correct results |
+| `getUsers batches requests into a single resolver call` | Batching proof | All 3 requests arrive in one batch (batchCount === 1) |
+
+## Teaching Approach
+
+### Socratic prompts
+
+- "`RequestResolver.makeBatched` receives a `NonEmptyArray<GetUser>` -- all the requests that were collected in a single batch. Why does Effect collect them instead of sending each one individually?"
+- "Inside the resolver, you must call `Request.succeed` or `Request.fail` for each request. What happens if you forget to complete a request?"
+- "`Effect.forEach` with `{ batching: true }` collects all the requests before executing them. How is this different from running the requests with `{ concurrency: 'unbounded' }` alone?"
+
+### Common pitfalls
+
+1. **Forgetting to complete every request** -- the batched resolver must call `Request.succeed` or `Request.fail` for every request in the batch. If a request is not completed, the fiber waiting for it will hang forever. Ask: "What does an uncompleted request look like to the caller?"
+2. **Not using `{ batching: true }` in `getUsers`** -- without the `batching` option, `Effect.forEach` may execute requests one at a time, defeating the purpose of batching. The test that checks `batchCount === 1` will fail. Nudge: "How does Effect know to collect requests into a batch rather than sending them immediately?"
+3. **Confusing `Request.tagged` constructor usage** -- `GetUser({ id: 1 })` creates a request value, not an effect. You pass this value to `Effect.request(requestValue, resolver)` to get an effect. Students may try to call `GetUser` as if it returns an effect directly.
+
+## On Completion
+
+### Insight
+
+Request batching is one of Effect's most impressive optimization patterns. You write your code as if each request is independent -- `getUser(1)`, `getUser(2)`, `getUser(3)` -- but the runtime automatically groups them into a single batch call. The resolver sees all three requests at once and can make one database query or API call instead of three. This is the N+1 query problem solved at the framework level: no manual batching logic, no DataLoader boilerplate, just declare your requests and let Effect optimize the execution. The `batching: true` option tells Effect to collect requests within the same execution scope before dispatching them to the resolver.
+
+### Bridge
+
+Request batching completes the advanced Effect toolkit. You have now covered domain modeling with schemas, caching for performance, metrics for observability, managed runtimes for integration, and request batching for optimization. These patterns form the backbone of production Effect applications.

package/katas/040-request-batching/solution.test.ts

@@ -0,0 +1,56 @@
+import { Effect } from "effect";
+import { describe, expect, it } from "vitest";
+import {
+  GetUser,
+  makeUserResolver,
+  getUser,
+  getUsers,
+} from "@/katas/040-request-batching/solution.js";
+
+const testData = new Map([
+  [1, "Alice"],
+  [2, "Bob"],
+  [3, "Charlie"],
+]);
+
+const testLookup = (ids: number[]) =>
+  Effect.succeed(
+    new Map(
+      ids
+        .filter((id) => testData.has(id))
+        .map((id) => [id, testData.get(id)!]),
+    ),
+  );
+
+describe("040 — Request Batching", () => {
+  it("getUser fetches a single user", async () => {
+    const resolver = makeUserResolver(testLookup);
+    const result = await Effect.runPromise(getUser(1, resolver));
+    expect(result).toBe("Alice");
+  });
+
+  it("getUser fails for unknown id", async () => {
+    const resolver = makeUserResolver(testLookup);
+    const result = await Effect.runPromise(
+      Effect.either(getUser(99, resolver)),
+    );
+    expect(result._tag).toBe("Left");
+  });
+
+  it("getUsers fetches multiple users", async () => {
+    const resolver = makeUserResolver(testLookup);
+    const result = await Effect.runPromise(getUsers([1, 2, 3], resolver));
+    expect(result).toEqual(["Alice", "Bob", "Charlie"]);
+  });
+
+  it("getUsers batches requests into a single resolver call", async () => {
+    let batchCount = 0;
+    const countingLookup = (ids: number[]) => {
+      batchCount++;
+      return testLookup(ids);
+    };
+    const resolver = makeUserResolver(countingLookup);
+    await Effect.runPromise(getUsers([1, 2, 3], resolver));
+    expect(batchCount).toBe(1);
+  });
+});

package/katas/040-request-batching/solution.ts

@@ -0,0 +1,32 @@
+import { Effect, Request, RequestResolver } from "effect";
+
+export interface GetUser extends Request.Request<string, string> {
+  readonly _tag: "GetUser";
+  readonly id: number;
+}
+
+export const GetUser = Request.tagged<GetUser>("GetUser");
+
+/** Create a batched resolver that receives all requests at once,
+ * calls the lookup function with all IDs, and resolves each request */
+export const makeUserResolver = (
+  lookup: (ids: number[]) => Effect.Effect<Map<number, string>>,
+): RequestResolver.RequestResolver<GetUser> => {
+  throw new Error("Not implemented") as any;
+};
+
+/** Make a single user request using Effect.request */
+export const getUser = (
+  id: number,
+  resolver: RequestResolver.RequestResolver<GetUser>,
+): Effect.Effect<string, string> => {
+  throw new Error("Not implemented");
+};
+
+/** Make multiple user requests with batching enabled */
+export const getUsers = (
+  ids: number[],
+  resolver: RequestResolver.RequestResolver<GetUser>,
+): Effect.Effect<string[], string> => {
+  throw new Error("Not implemented");
+};

package/package.json

@@ -0,0 +1,22 @@
+{
+  "name": "@dojocho/effect-ts",
+  "version": "0.0.1",
+  "type": "module",
+  "publishConfig": { "access": "public" },
+  "files": ["katas", "skills", "commands", "DOJO.md", "dojo.json", "tsconfig.json", "vitest.config.ts"],
+  "scripts": {
+    "test": "vitest run",
+    "test:watch": "vitest"
+  },
+  "dependencies": {
+    "effect": "^3.14.0"
+  },
+  "peerDependencies": {
+    "@dojocho/config": "workspace:*"
+  },
+  "devDependencies": {
+    "@types/node": "^22.0.0",
+    "typescript": "^5.7.0",
+    "vitest": "^3.0.0"
+  }
+}