Effective Modules

(Note: this article assumes familiarity with TypeScript, Effect, and SOLID).
To jump straight to the tool I built, click here.

Since late 2025, I’ve been moving all my personal projects over to Effect, along with several work projects at Flexport (before getting laid off a couple months ago). I’ve come to largely agree with the premise that Effect is

the missing TypeScript standard library

• algebraic data types
• return types encoding error information
• exhaustive pattern matching
• first-class dependency injection
• type-safe schema decoding

In 2026, serious developers who understand the value of a strongly-typed language consider all these table stakes for a robust, type-safe programming platform. All these are missing from vanilla TypeScript. A comprehensive standard library should include all these features, and Effect has done it for the TypeScript ecosystem, arguably outdoing the ecosystem alternatives on every front. Effect has brought DI into the type system. That is, there is a compile-time failure when required dependencies aren’t provided. In general, few DI systems across all major programming languages offer this highest level of correctness.

So, Effect seems like the right choice for writing TypeScript at scale. However, as I adopt Effect conventions and constructs such as Service, Context, and Layer across my projects, I keep running into the same awkward developer experiences.

Headaches

1. Decoupling Impl from Interface

In Effect v3, we are encouraged to use the Effect.Service utility to improve code succinctness. Provide a default implementation of a Service and its interface gets inferred.

import { import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect } from "effect";
import { import FileSystemFileSystem } from "@effect/platform";
import { import NodeFileSystemNodeFileSystem } from "@effect/platform-node"

class class CacheCache extends import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.
const Service: <Cache>() => {
    <Key, Make>(key: Key, make: Make): Effect.Service.Class<Cache, Key, Make>;
    <Key, Make>(key: Key, make: Make): Effect.Service.Class<Cache, Key, Make>;
    <Key, Make>(key: Key, make: Make): Effect.Service.Class<Cache, Key, Make>;
    <Key, Make>(key: Key, make: Make): Effect.Service.Class<Cache, Key, Make>;
    <Key, Make>(key: Key, make: Make): Effect.Service.Class<...>;
}
Simplifies the creation and management of services in Effect by defining both
a Tag and a Layer.
Details
This function allows you to streamline the creation of services by combining
the definition of a Context.Tag and a Layer in a single step. It supports
various ways of providing the service implementation:

Using an effect to define the service dynamically.
Using sync or succeed to define the service statically.
Using scoped to create services with lifecycle management.

It also allows you to specify dependencies for the service, which will be
provided automatically when the service is used. Accessors can be optionally
generated for the service, making it more convenient to use.
Example
import { Effect } from 'effect';

class Prefix extends Effect.Service<Prefix>()("Prefix", {
 sync: () => ({ prefix: "PRE" })
}) {}

class Logger extends Effect.Service<Logger>()("Logger", {
 accessors: true,
 effect: Effect.gen(function* () {
   const { prefix } = yield* Prefix
   return {
     info: (message: string) =>
       Effect.sync(() => {
         console.log(`[${prefix}][${message}]`)
       })
   }
 }),
 dependencies: [Prefix.Default]
}) {}
@since3.9.0@categoryContext@experimentalmight be up for breaking changesService<class CacheCache>()("app/Cache", {
  // Define how to create the service
  
effect: Effect.Effect<{
    readonly lookup: (key: string) => Effect.Effect<string, PlatformError, never>;
}, never, FileSystem.FileSystem>effect: import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.
const gen: <YieldWrap<Tag<FileSystem.FileSystem, FileSystem.FileSystem>>, {
    readonly lookup: (key: string) => Effect.Effect<string, PlatformError, never>;
}>(f: (resume: Effect.Adapter) => Generator<YieldWrap<Tag<FileSystem.FileSystem, FileSystem.FileSystem>>, {
    readonly lookup: (key: string) => Effect.Effect<string, PlatformError, never>;
}, never>) => Effect.Effect<{
    readonly lookup: (key: string) => Effect.Effect<string, PlatformError, never>;
}, never, FileSystem.FileSystem> (+1 overload)
Provides a way to write effectful code using generator functions, simplifying
control flow and error handling.
When to Use
Effect.gen allows you to write code that looks and behaves like synchronous
code, but it can handle asynchronous tasks, errors, and complex control flow
(like loops and conditions). It helps make asynchronous code more readable
and easier to manage.
The generator functions work similarly to async/await but with more
explicit control over the execution of effects. You can yield* values from
effects and return the final result at the end.
Example
import { Effect } from "effect"

const addServiceCharge = (amount: number) => amount + 1

const applyDiscount = (
  total: number,
  discountRate: number
): Effect.Effect<number, Error> =>
  discountRate === 0
    ? Effect.fail(new Error("Discount rate cannot be zero"))
    : Effect.succeed(total - (total * discountRate) / 100)

const fetchTransactionAmount = Effect.promise(() => Promise.resolve(100))

const fetchDiscountRate = Effect.promise(() => Promise.resolve(5))

export const program = Effect.gen(function* () {
  const transactionAmount = yield* fetchTransactionAmount
  const discountRate = yield* fetchDiscountRate
  const discountedAmount = yield* applyDiscount(
    transactionAmount,
    discountRate
  )
  const finalAmount = addServiceCharge(discountedAmount)
  return `Final amount to charge: ${finalAmount}`
})
@since2.0.0@categoryCreating Effectsgen(function* () {
    const const fs: FileSystem.FileSystemfs = yield* import FileSystemFileSystem.const FileSystem: Tag<FileSystem.FileSystem, FileSystem.FileSystem>
@since1.0.0@categorymodel@since1.0.0@categorytagFileSystem;
    const const lookup: (key: string) => Effect.Effect<string, PlatformError, never>lookup = (key: stringkey: string) => const fs: FileSystem.FileSystemfs.FileSystem.readFileString: (path: string, encoding?: string) => Effect.Effect<string, PlatformError>
Read the contents of a file.readFileString(`cache/${key: stringkey}`);
    return { lookup: (key: string) => Effect.Effect<string, PlatformError, never>lookup } as 
type const = {
    readonly lookup: (key: string) => Effect.Effect<string, PlatformError, never>;
}const;
  }),
  // Specify dependencies
  dependencies: readonly [Layer<FileSystem.FileSystem, never, never>]dependencies: [import NodeFileSystemNodeFileSystem.const layer: Layer<FileSystem.FileSystem, never, never>
@since1.0.0@categorylayerlayer]
}) {}


import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.const gen: <YieldWrap<Tag<Cache, Cache>> | YieldWrap<Effect.Effect<string, PlatformError, never>>, void>(f: (resume: Effect.Adapter) => Generator<YieldWrap<Tag<Cache, Cache>> | YieldWrap<Effect.Effect<string, PlatformError, never>>, void, never>) => Effect.Effect<void, PlatformError, Cache> (+1 overload)
Provides a way to write effectful code using generator functions, simplifying
control flow and error handling.
When to Use
Effect.gen allows you to write code that looks and behaves like synchronous
code, but it can handle asynchronous tasks, errors, and complex control flow
(like loops and conditions). It helps make asynchronous code more readable
and easier to manage.
The generator functions work similarly to async/await but with more
explicit control over the execution of effects. You can yield* values from
effects and return the final result at the end.
Example
import { Effect } from "effect"

const addServiceCharge = (amount: number) => amount + 1

const applyDiscount = (
  total: number,
  discountRate: number
): Effect.Effect<number, Error> =>
  discountRate === 0
    ? Effect.fail(new Error("Discount rate cannot be zero"))
    : Effect.succeed(total - (total * discountRate) / 100)

const fetchTransactionAmount = Effect.promise(() => Promise.resolve(100))

const fetchDiscountRate = Effect.promise(() => Promise.resolve(5))

export const program = Effect.gen(function* () {
  const transactionAmount = yield* fetchTransactionAmount
  const discountRate = yield* fetchDiscountRate
  const discountedAmount = yield* applyDiscount(
    transactionAmount,
    discountRate
  )
  const finalAmount = addServiceCharge(discountedAmount)
  return `Final amount to charge: ${finalAmount}`
})
@since2.0.0@categoryCreating Effectsgen(function*() {
    const const cache: Cachecache = yield* class CacheCache;
    yield* const cache: Cachecache.
lookup: (key: string) => Effect.Effect<string, PlatformError, never>lookup("some key");
});

While this does improve readability (compared to declaring the Tag and Layer separately), the trade-off is violation of a sacred SOLID pillar, the Dependency Inversion principle, which mandates that maintainable code ought to depend on abstractions, not concretions. If a bug is introduced into the implementation, a compiler error should ideally appear in the implementation block and the interface should not change. But with Effect.Service an error may instead appear in client code because changing the implementation might inadvertently also change the interface.

class class CacheCache extends import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.
const Service: <Cache>() => {
    <Key, Make>(key: Key, make: Make): Effect.Service.Class<Cache, Key, Make>;
    <Key, Make>(key: Key, make: Make): Effect.Service.Class<Cache, Key, Make>;
    <Key, Make>(key: Key, make: Make): Effect.Service.Class<Cache, Key, Make>;
    <Key, Make>(key: Key, make: Make): Effect.Service.Class<Cache, Key, Make>;
    <Key, Make>(key: Key, make: Make): Effect.Service.Class<...>;
}
Simplifies the creation and management of services in Effect by defining both
a Tag and a Layer.
Details
This function allows you to streamline the creation of services by combining
the definition of a Context.Tag and a Layer in a single step. It supports
various ways of providing the service implementation:

Using an effect to define the service dynamically.
Using sync or succeed to define the service statically.
Using scoped to create services with lifecycle management.

It also allows you to specify dependencies for the service, which will be
provided automatically when the service is used. Accessors can be optionally
generated for the service, making it more convenient to use.
Example
import { Effect } from 'effect';

class Prefix extends Effect.Service<Prefix>()("Prefix", {
 sync: () => ({ prefix: "PRE" })
}) {}

class Logger extends Effect.Service<Logger>()("Logger", {
 accessors: true,
 effect: Effect.gen(function* () {
   const { prefix } = yield* Prefix
   return {
     info: (message: string) =>
       Effect.sync(() => {
         console.log(`[${prefix}][${message}]`)
       })
   }
 }),
 dependencies: [Prefix.Default]
}) {}
@since3.9.0@categoryContext@experimentalmight be up for breaking changesService<class CacheCache>()("app/Cache", {
  
effect: Effect.Effect<{
    readonly lockup: (key: string) => Effect.Effect<string, PlatformError, never>;
}, never, FileSystem.FileSystem>effect: import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.
const gen: <YieldWrap<Tag<FileSystem.FileSystem, FileSystem.FileSystem>>, {
    readonly lockup: (key: string) => Effect.Effect<string, PlatformError, never>;
}>(f: (resume: Effect.Adapter) => Generator<YieldWrap<Tag<FileSystem.FileSystem, FileSystem.FileSystem>>, {
    readonly lockup: (key: string) => Effect.Effect<string, PlatformError, never>;
}, never>) => Effect.Effect<{
    readonly lockup: (key: string) => Effect.Effect<string, PlatformError, never>;
}, never, FileSystem.FileSystem> (+1 overload)
Provides a way to write effectful code using generator functions, simplifying
control flow and error handling.
When to Use
Effect.gen allows you to write code that looks and behaves like synchronous
code, but it can handle asynchronous tasks, errors, and complex control flow
(like loops and conditions). It helps make asynchronous code more readable
and easier to manage.
The generator functions work similarly to async/await but with more
explicit control over the execution of effects. You can yield* values from
effects and return the final result at the end.
Example
import { Effect } from "effect"

const addServiceCharge = (amount: number) => amount + 1

const applyDiscount = (
  total: number,
  discountRate: number
): Effect.Effect<number, Error> =>
  discountRate === 0
    ? Effect.fail(new Error("Discount rate cannot be zero"))
    : Effect.succeed(total - (total * discountRate) / 100)

const fetchTransactionAmount = Effect.promise(() => Promise.resolve(100))

const fetchDiscountRate = Effect.promise(() => Promise.resolve(5))

export const program = Effect.gen(function* () {
  const transactionAmount = yield* fetchTransactionAmount
  const discountRate = yield* fetchDiscountRate
  const discountedAmount = yield* applyDiscount(
    transactionAmount,
    discountRate
  )
  const finalAmount = addServiceCharge(discountedAmount)
  return `Final amount to charge: ${finalAmount}`
})
@since2.0.0@categoryCreating Effectsgen(function* () {
    const const fs: FileSystem.FileSystemfs = yield* import FileSystemFileSystem.const FileSystem: Tag<FileSystem.FileSystem, FileSystem.FileSystem>
@since1.0.0@categorymodel@since1.0.0@categorytagFileSystem;
    // Accidentally changed the spelling of "lookup" to "lockup"
    const const lockup: (key: string) => Effect.Effect<string, PlatformError, never>lockup = (key: stringkey: string) => const fs: FileSystem.FileSystemfs.FileSystem.readFileString: (path: string, encoding?: string) => Effect.Effect<string, PlatformError>
Read the contents of a file.readFileString(`cache/${key: stringkey}`);
    return { lockup: (key: string) => Effect.Effect<string, PlatformError, never>lockup } as 
type const = {
    readonly lockup: (key: string) => Effect.Effect<string, PlatformError, never>;
}const;
  }),
  dependencies: readonly [Layer<FileSystem.FileSystem, never, never>]dependencies: [import NodeFileSystemNodeFileSystem.const layer: Layer<FileSystem.FileSystem, never, never>
@since1.0.0@categorylayerlayer]
}) {}

import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.const gen: <any, void>(f: (resume: Effect.Adapter) => Generator<any, void, never>) => Effect.Effect<void, unknown, unknown> (+1 overload)
Provides a way to write effectful code using generator functions, simplifying
control flow and error handling.
When to Use
Effect.gen allows you to write code that looks and behaves like synchronous
code, but it can handle asynchronous tasks, errors, and complex control flow
(like loops and conditions). It helps make asynchronous code more readable
and easier to manage.
The generator functions work similarly to async/await but with more
explicit control over the execution of effects. You can yield* values from
effects and return the final result at the end.
Example
import { Effect } from "effect"

const addServiceCharge = (amount: number) => amount + 1

const applyDiscount = (
  total: number,
  discountRate: number
): Effect.Effect<number, Error> =>
  discountRate === 0
    ? Effect.fail(new Error("Discount rate cannot be zero"))
    : Effect.succeed(total - (total * discountRate) / 100)

const fetchTransactionAmount = Effect.promise(() => Promise.resolve(100))

const fetchDiscountRate = Effect.promise(() => Promise.resolve(5))

export const program = Effect.gen(function* () {
  const transactionAmount = yield* fetchTransactionAmount
  const discountRate = yield* fetchDiscountRate
  const discountedAmount = yield* applyDiscount(
    transactionAmount,
    discountRate
  )
  const finalAmount = addServiceCharge(discountedAmount)
  return `Final amount to charge: ${finalAmount}`
})
@since2.0.0@categoryCreating Effectsgen(function*() {
    const const cache: Cachecache = yield* class CacheCache;
    yield* const cache: Cachecache.lookup("some key");
Property 'lookup' does not exist on type 'Cache'. Did you mean 'lockup'?
});

I deem Effect v3’s Effect.Service an anti-pattern, but if it’s so problematic why was it introduced at all?

2. Awkward Interface Syntax

Effect.Service was introduced because the right way to do things sucks. In Effect, declaring an interface (Tag) looks like this

type 
type ICache = {
    lookup(key: string): Effect.Effect<string, PlatformError, never>;
}ICache = {
  function lookup(key: string): Effect.Effect<string, PlatformError, never>lookup(key: stringkey: string): import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.interface Effect<out A, out E = never, out R = never>
The Effect interface defines a value that describes a workflow or job,
which can succeed or fail.
Details
The Effect interface represents a computation that can model a workflow
involving various types of operations, such as synchronous, asynchronous,
concurrent, and parallel interactions. It operates within a context of type
R, and the result can either be a success with a value of type A or a
failure with an error of type E. The Effect is designed to handle complex
interactions with external resources, offering advanced features such as
fiber-based concurrency, scheduling, interruption handling, and scalability.
This makes it suitable for tasks that require fine-grained control over
concurrency and error management.
To execute an Effect value, you need a Runtime, which provides the
environment necessary to run and manage the computation.
@since2.0.0@categoryModels@since2.0.0Effect<string, type PlatformError = BadArgument | SystemError
@since1.0.0@categoryModels@since1.0.0@categoryModelsPlatformError, never>
}

class class CacheCache extends Context.Tag<Cache, ICache>("app/Cache") {}
Expected 1 type arguments, but got 2.
Type '<Self, Shape>() => TagClass<Self, Cache, Shape>' is not a constructor function type.

Oh wait no it’s

class class CacheCache extends import Context
@since2.0.0@categorymodels@since2.0.0@categoryModelsContext.const Tag: <Cache>(id: Cache) => <Self, Shape>() => Context.TagClass<Self, Cache, Shape>
@example
import * as assert from "node:assert"
import { Context, Layer } from "effect"

class MyTag extends Context.Tag("MyTag")<
 MyTag,
 { readonly myNum: number }
>() {
 static Live = Layer.succeed(this, { myNum: 108 })
}
@since2.0.0@categoryconstructorsTag<Cache, ICache>()("app/Cache") {}
Expected 0 arguments, but got 1.
Expected 1 type arguments, but got 2.

Still not it. Maybe

class class CacheCache extends import Context
@since2.0.0@categorymodels@since2.0.0@categoryModelsContext.const Tag: <"app/Cache">(id: "app/Cache") => <Self, Shape>() => Context.TagClass<Self, "app/Cache", Shape>
@example
import * as assert from "node:assert"
import { Context, Layer } from "effect"

class MyTag extends Context.Tag("MyTag")<
 MyTag,
 { readonly myNum: number }
>() {
 static Live = Layer.succeed(this, { myNum: 108 })
}
@since2.0.0@categoryconstructorsTag("app/Cache")<class CacheCache, 
type ICache = {
    lookup(key: string): Effect.Effect<string, PlatformError, never>;
}ICache>() {}

there we go.

… this syntax is hieroglyphic. When defining a new Tag I typically fight with the compiler for a minute or so because the syntax just doesn’t commit to memory. It’s repetitive and cluttered.

• Why am I creating a class?
• Why am I passing the class in as a parameter?
• Why am I repeating the name of my interface 5 times?
• What are all these function calls for?

There are, as one might expect, reasonably good answers to these questions.

• Effect needs a way to uniquely identify a Tag at compile time such that two Tags with overlapping shapes can’t be mistakenly substituted for one another due to structural typing. Effect solves this with the key field being preserved in the type structure. In this case app/Cache is the unique string.
• Classes are both compile time and runtime entities so by declaring Cache as the Tag then passing it in as a generic for the Self type, it can be used as both a compile time reference to the Tag in Effect requirements channels (e.g. Effect<void, never, Cache>) and in runtime code when acquiring the dependency (e.g. yield* Cache).

For such a high cost in syntax complexity, Tag still leaves much to be desired. For instance, using string literals is not a foolproof way to guarantee Tag uniqueness. Ideally Effect would use nominal types for that. By adding a private field to every class declared using the Tag() method, we could accomplish this:

class class CacheCache extends import Context
@since2.0.0@categorymodels@since2.0.0@categoryModelsContext.const Tag: <"app/Cache">(id: "app/Cache") => <Self, Shape>() => Context.TagClass<Self, "app/Cache", Shape>
@example
import * as assert from "node:assert"
import { Context, Layer } from "effect"

class MyTag extends Context.Tag("MyTag")<
 MyTag,
 { readonly myNum: number }
>() {
 static Live = Layer.succeed(this, { myNum: 108 })
}
@since2.0.0@categoryconstructorsTag("app/Cache")
  <class CacheCache, ICache>() {}
// Imagine we accidentally create another tag with the same name
class class Cache2Cache2 extends import Context
@since2.0.0@categorymodels@since2.0.0@categoryModelsContext.const Tag: <"app/Cache">(id: "app/Cache") => <Self, Shape>() => Context.TagClass<Self, "app/Cache", Shape>
@example
import * as assert from "node:assert"
import { Context, Layer } from "effect"

class MyTag extends Context.Tag("MyTag")<
 MyTag,
 { readonly myNum: number }
>() {
 static Live = Layer.succeed(this, { myNum: 108 })
}
@since2.0.0@categoryconstructorsTag("app/Cache")
  <class Cache2Cache2, ICache>() {}

const const program: Effect.Effect<void, never, Cache>program: import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.interface Effect<out A, out E = never, out R = never>
The Effect interface defines a value that describes a workflow or job,
which can succeed or fail.
Details
The Effect interface represents a computation that can model a workflow
involving various types of operations, such as synchronous, asynchronous,
concurrent, and parallel interactions. It operates within a context of type
R, and the result can either be a success with a value of type A or a
failure with an error of type E. The Effect is designed to handle complex
interactions with external resources, offering advanced features such as
fiber-based concurrency, scheduling, interruption handling, and scalability.
This makes it suitable for tasks that require fine-grained control over
concurrency and error management.
To execute an Effect value, you need a Runtime, which provides the
environment necessary to run and manage the computation.
@since2.0.0@categoryModels@since2.0.0Effect<void, never, class CacheCache> = import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.const gen: <YieldWrap<Context.Tag<Cache2, ICache>>, void>(f: (resume: Effect.Adapter) => Generator<YieldWrap<Context.Tag<Cache2, ICache>>, void, never>) => Effect.Effect<void, never, Cache2> (+1 overload)
Provides a way to write effectful code using generator functions, simplifying
control flow and error handling.
When to Use
Effect.gen allows you to write code that looks and behaves like synchronous
code, but it can handle asynchronous tasks, errors, and complex control flow
(like loops and conditions). It helps make asynchronous code more readable
and easier to manage.
The generator functions work similarly to async/await but with more
explicit control over the execution of effects. You can yield* values from
effects and return the final result at the end.
Example
import { Effect } from "effect"

const addServiceCharge = (amount: number) => amount + 1

const applyDiscount = (
  total: number,
  discountRate: number
): Effect.Effect<number, Error> =>
  discountRate === 0
    ? Effect.fail(new Error("Discount rate cannot be zero"))
    : Effect.succeed(total - (total * discountRate) / 100)

const fetchTransactionAmount = Effect.promise(() => Promise.resolve(100))

const fetchDiscountRate = Effect.promise(() => Promise.resolve(5))

export const program = Effect.gen(function* () {
  const transactionAmount = yield* fetchTransactionAmount
  const discountRate = yield* fetchDiscountRate
  const discountedAmount = yield* applyDiscount(
    transactionAmount,
    discountRate
  )
  const finalAmount = addServiceCharge(discountedAmount)
  return `Final amount to charge: ${finalAmount}`
})
@since2.0.0@categoryCreating Effectsgen(function*() {
  // No compiler error?! This shouldn't be allowed!
  yield* class Cache2Cache2;
});

class class CacheCache extends import Context
@since2.0.0@categorymodels@since2.0.0@categoryModelsContext.const Tag: <"app/Cache">(id: "app/Cache") => <Self, Shape>() => Context.TagClass<Self, "app/Cache", Shape>
@example
import * as assert from "node:assert"
import { Context, Layer } from "effect"

class MyTag extends Context.Tag("MyTag")<
 MyTag,
 { readonly myNum: number }
>() {
 static Live = Layer.succeed(this, { myNum: 108 })
}
@since2.0.0@categoryconstructorsTag("app/Cache")
  <class CacheCache, ICache>() {private Cache.nominal: booleannominal = true;}
class class Cache2Cache2 extends import Context
@since2.0.0@categorymodels@since2.0.0@categoryModelsContext.const Tag: <"app/Cache">(id: "app/Cache") => <Self, Shape>() => Context.TagClass<Self, "app/Cache", Shape>
@example
import * as assert from "node:assert"
import { Context, Layer } from "effect"

class MyTag extends Context.Tag("MyTag")<
 MyTag,
 { readonly myNum: number }
>() {
 static Live = Layer.succeed(this, { myNum: 108 })
}
@since2.0.0@categoryconstructorsTag("app/Cache")
  <class Cache2Cache2, ICache>() {private Cache2.nominal: booleannominal = true;}

const program: import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.interface Effect<out A, out E = never, out R = never>
The Effect interface defines a value that describes a workflow or job,
which can succeed or fail.
Details
The Effect interface represents a computation that can model a workflow
involving various types of operations, such as synchronous, asynchronous,
concurrent, and parallel interactions. It operates within a context of type
R, and the result can either be a success with a value of type A or a
failure with an error of type E. The Effect is designed to handle complex
interactions with external resources, offering advanced features such as
fiber-based concurrency, scheduling, interruption handling, and scalability.
This makes it suitable for tasks that require fine-grained control over
concurrency and error management.
To execute an Effect value, you need a Runtime, which provides the
environment necessary to run and manage the computation.
@since2.0.0@categoryModels@since2.0.0Effect<void, never, class CacheCache> = import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.const gen: <YieldWrap<Context.Tag<Cache2, ICache>>, void>(f: (resume: Effect.Adapter) => Generator<YieldWrap<Context.Tag<Cache2, ICache>>, void, never>) => Effect.Effect<void, never, Cache2> (+1 overload)
Provides a way to write effectful code using generator functions, simplifying
control flow and error handling.
When to Use
Effect.gen allows you to write code that looks and behaves like synchronous
code, but it can handle asynchronous tasks, errors, and complex control flow
(like loops and conditions). It helps make asynchronous code more readable
and easier to manage.
The generator functions work similarly to async/await but with more
explicit control over the execution of effects. You can yield* values from
effects and return the final result at the end.
Example
import { Effect } from "effect"

const addServiceCharge = (amount: number) => amount + 1

const applyDiscount = (
  total: number,
  discountRate: number
): Effect.Effect<number, Error> =>
  discountRate === 0
    ? Effect.fail(new Error("Discount rate cannot be zero"))
    : Effect.succeed(total - (total * discountRate) / 100)

const fetchTransactionAmount = Effect.promise(() => Promise.resolve(100))

const fetchDiscountRate = Effect.promise(() => Promise.resolve(5))

export const program = Effect.gen(function* () {
  const transactionAmount = yield* fetchTransactionAmount
  const discountRate = yield* fetchDiscountRate
  const discountedAmount = yield* applyDiscount(
    transactionAmount,
    discountRate
  )
  const finalAmount = addServiceCharge(discountedAmount)
  return `Final amount to charge: ${finalAmount}`
})
@since2.0.0@categoryCreating Effectsgen(function*() {
Type 'Effect<void, never, Cache2>' is not assignable to type 'Effect<void, never, Cache>'.
  Type 'Cache2' is not assignable to type 'Cache'.
    Types have separate declarations of a private property 'nominal'.
  // Now we get an error. That's better
  yield* class Cache2Cache2;
});

but this would make the syntax even nastier.

All this to say, Effect’s v3 Tag and v4 Service utilities had me missing the simplicity of pure interfaces and wondering if it might be possible to get the properties Effect is aiming for without the unreadable and repetitive syntax.

3. Error Noise

This biggest headache I experience, by far, when working with Effect is my IDE becoming unusable whenever I introduce a bug into an effect implementation that changes its error or requirements channel. This happens a lot during refactors, especially when work on one service leads me to refactor the contract (interface) of another.

In this example from one of my own projects, this is what happens when I change the type signature of the github service’s resolveAccessToken method so that it has an additional requirement such that it no longer matches ensureLoggedIn’s requirements channel:

Seeing the whole Layer implementation light up as incorrect is not conducive to productively finding and fixing the bug. Ideally only the resolveAccessToken line would be highlighted as wrong, prompting me to provide a Context with the required Service to that Effect.

When one runs into this kind of issue frequently, it becomes tempting to start taking the path of least resistance. That often looks like handling all possible errors after the entire Effect’s body rather than handling each error at the line which produces it; over time these kinds of shortcuts lead to brittle and confusing code.

4. Verbose Dependency Passing

Building on that resolveAccessToken example, when you want to yield an Effect which depends on 1+ services you need to either define that Effect within the Layer’s closure so the services yielded at layer construction time are in scope, or you need to create a custom Context and provide it to the Effect before yielding.

Here’s an example of that first option

class class ServiceOneServiceOne extends import Context
@since2.0.0@categorymodels@since2.0.0@categoryModelsContext.const Tag: <"ServiceOne">(id: "ServiceOne") => <Self, Shape>() => Context.TagClass<Self, "ServiceOne", Shape>
@example
import * as assert from "node:assert"
import { Context, Layer } from "effect"

class MyTag extends Context.Tag("MyTag")<
 MyTag,
 { readonly myNum: number }
>() {
 static Live = Layer.succeed(this, { myNum: 108 })
}
@since2.0.0@categoryconstructorsTag("ServiceOne")<class ServiceOneServiceOne, {
  function serviceOneMethod(someInput: number): Effect.Effect<string, never, never>serviceOneMethod(someInput: numbersomeInput: number): import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.interface Effect<out A, out E = never, out R = never>
The Effect interface defines a value that describes a workflow or job,
which can succeed or fail.
Details
The Effect interface represents a computation that can model a workflow
involving various types of operations, such as synchronous, asynchronous,
concurrent, and parallel interactions. It operates within a context of type
R, and the result can either be a success with a value of type A or a
failure with an error of type E. The Effect is designed to handle complex
interactions with external resources, offering advanced features such as
fiber-based concurrency, scheduling, interruption handling, and scalability.
This makes it suitable for tasks that require fine-grained control over
concurrency and error management.
To execute an Effect value, you need a Runtime, which provides the
environment necessary to run and manage the computation.
@since2.0.0@categoryModels@since2.0.0Effect<string, never, never>;
}>() {};

class class ServiceTwoServiceTwo extends import Context
@since2.0.0@categorymodels@since2.0.0@categoryModelsContext.const Tag: <"ServiceTwo">(id: "ServiceTwo") => <Self, Shape>() => Context.TagClass<Self, "ServiceTwo", Shape>
@example
import * as assert from "node:assert"
import { Context, Layer } from "effect"

class MyTag extends Context.Tag("MyTag")<
 MyTag,
 { readonly myNum: number }
>() {
 static Live = Layer.succeed(this, { myNum: 108 })
}
@since2.0.0@categoryconstructorsTag("ServiceTwo")<class ServiceTwoServiceTwo, {
  function serviceTwoMethod(someInput: number): Effect.Effect<string, never, never>serviceTwoMethod(someInput: numbersomeInput: number): import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.interface Effect<out A, out E = never, out R = never>
The Effect interface defines a value that describes a workflow or job,
which can succeed or fail.
Details
The Effect interface represents a computation that can model a workflow
involving various types of operations, such as synchronous, asynchronous,
concurrent, and parallel interactions. It operates within a context of type
R, and the result can either be a success with a value of type A or a
failure with an error of type E. The Effect is designed to handle complex
interactions with external resources, offering advanced features such as
fiber-based concurrency, scheduling, interruption handling, and scalability.
This makes it suitable for tasks that require fine-grained control over
concurrency and error management.
To execute an Effect value, you need a Runtime, which provides the
environment necessary to run and manage the computation.
@since2.0.0@categoryModels@since2.0.0Effect<string, never, never>; 
}>() {};

const const ServiceTwoImpl: Layer.Layer<ServiceTwo, never, ServiceOne>ServiceTwoImpl = import LayerLayer.
const effect: <ServiceTwo, {
    serviceTwoMethod(someInput: number): Effect.Effect<string, never, never>;
}, never, ServiceOne>(tag: Context.Tag<ServiceTwo, {
    serviceTwoMethod(someInput: number): Effect.Effect<string, never, never>;
}>, effect: Effect.Effect<{
    serviceTwoMethod(someInput: number): Effect.Effect<string, never, never>;
}, never, ServiceOne>) => Layer.Layer<ServiceTwo, never, ServiceOne> (+1 overload)
Constructs a layer from the specified effect.
@since2.0.0@categoryconstructorseffect(class ServiceTwoServiceTwo, import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.
const gen: <YieldWrap<Context.Tag<ServiceOne, {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}>>, {
    serviceTwoMethod: (someInput: number) => Effect.Effect<string, never, never>;
}>(f: (resume: Effect.Adapter) => Generator<YieldWrap<Context.Tag<ServiceOne, {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}>>, {
    serviceTwoMethod: (someInput: number) => Effect.Effect<string, never, never>;
}, never>) => Effect.Effect<...> (+1 overload)
Provides a way to write effectful code using generator functions, simplifying
control flow and error handling.
When to Use
Effect.gen allows you to write code that looks and behaves like synchronous
code, but it can handle asynchronous tasks, errors, and complex control flow
(like loops and conditions). It helps make asynchronous code more readable
and easier to manage.
The generator functions work similarly to async/await but with more
explicit control over the execution of effects. You can yield* values from
effects and return the final result at the end.
Example
import { Effect } from "effect"

const addServiceCharge = (amount: number) => amount + 1

const applyDiscount = (
  total: number,
  discountRate: number
): Effect.Effect<number, Error> =>
  discountRate === 0
    ? Effect.fail(new Error("Discount rate cannot be zero"))
    : Effect.succeed(total - (total * discountRate) / 100)

const fetchTransactionAmount = Effect.promise(() => Promise.resolve(100))

const fetchDiscountRate = Effect.promise(() => Promise.resolve(5))

export const program = Effect.gen(function* () {
  const transactionAmount = yield* fetchTransactionAmount
  const discountRate = yield* fetchDiscountRate
  const discountedAmount = yield* applyDiscount(
    transactionAmount,
    discountRate
  )
  const finalAmount = addServiceCharge(discountedAmount)
  return `Final amount to charge: ${finalAmount}`
})
@since2.0.0@categoryCreating Effectsgen(function*() {
  const 
const serviceOne: {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}serviceOne = yield* class ServiceOneServiceOne;
  const 
const helperFn: (someInput: number) => Effect.Effect<string, never, never>helperFn = import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.const fn: <YieldWrap<Effect.Effect<string, never, never>>, string, [someInput: number]>(body: (someInput: number) => Generator<YieldWrap<Effect.Effect<string, never, never>>, string, never>) => (someInput: number) => Effect.Effect<string, never, never> (+20 overloads)fn(function*(someInput: numbersomeInput: number) {
    // By placing helperFn inside the layer, it can access serviceOne directly
    const const serviceOneResult: stringserviceOneResult = yield* 
const serviceOne: {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}serviceOne.function serviceOneMethod(someInput: number): Effect.Effect<string, never, never>serviceOneMethod(someInput: numbersomeInput);
    // Do something complex with result before returning it.
    const const complexResult: stringcomplexResult = const serviceOneResult: stringserviceOneResult;
    return const complexResult: stringcomplexResult;
  });
  return {
    serviceTwoMethod: (someInput: number) => Effect.Effect<string, never, never>serviceTwoMethod: import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.const fn: <YieldWrap<Effect.Effect<string, never, never>>, string, [someInput: number]>(body: (someInput: number) => Generator<YieldWrap<Effect.Effect<string, never, never>>, string, never>) => (someInput: number) => Effect.Effect<string, never, never> (+20 overloads)fn(function*(someInput: numbersomeInput) {
      return yield* const helperFn: (someInput: number) => Effect.Effect<string, never, never>helperFn(someInput: numbersomeInput);
    })
  }
}));

And here’s option two

const 
const helperFn: (someInput: number) => Effect.Effect<string, never, ServiceOne>helperFn = import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.
const fn: <YieldWrap<Context.Tag<ServiceOne, {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}>> | YieldWrap<Effect.Effect<string, never, never>>, string, [someInput: number]>(body: (someInput: number) => Generator<YieldWrap<Context.Tag<ServiceOne, {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}>> | YieldWrap<Effect.Effect<string, never, never>>, string, never>) => (someInput: number) => Effect.Effect<...> (+20 overloads)fn(function*(someInput: numbersomeInput: number) {
  const 
const serviceOne: {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}serviceOne = yield* class ServiceOneServiceOne;
  const const serviceOneResult: stringserviceOneResult = yield* 
const serviceOne: {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}serviceOne.function serviceOneMethod(someInput: number): Effect.Effect<string, never, never>serviceOneMethod(someInput: numbersomeInput);
  // Do something complex with result before returning it.
  const const complexResult: stringcomplexResult = const serviceOneResult: stringserviceOneResult;
  return const complexResult: stringcomplexResult;
});

const const ServiceTwoImpl: Layer.Layer<ServiceTwo, never, ServiceOne>ServiceTwoImpl = import LayerLayer.
const effect: <ServiceTwo, {
    serviceTwoMethod(someInput: number): Effect.Effect<string, never, never>;
}, never, ServiceOne>(tag: Context.Tag<ServiceTwo, {
    serviceTwoMethod(someInput: number): Effect.Effect<string, never, never>;
}>, effect: Effect.Effect<{
    serviceTwoMethod(someInput: number): Effect.Effect<string, never, never>;
}, never, ServiceOne>) => Layer.Layer<ServiceTwo, never, ServiceOne> (+1 overload)
Constructs a layer from the specified effect.
@since2.0.0@categoryconstructorseffect(class ServiceTwoServiceTwo, import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.
const gen: <YieldWrap<Context.Tag<ServiceOne, {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}>>, {
    serviceTwoMethod: (someInput: number) => Effect.Effect<string, never, never>;
}>(f: (resume: Effect.Adapter) => Generator<YieldWrap<Context.Tag<ServiceOne, {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}>>, {
    serviceTwoMethod: (someInput: number) => Effect.Effect<string, never, never>;
}, never>) => Effect.Effect<...> (+1 overload)
Provides a way to write effectful code using generator functions, simplifying
control flow and error handling.
When to Use
Effect.gen allows you to write code that looks and behaves like synchronous
code, but it can handle asynchronous tasks, errors, and complex control flow
(like loops and conditions). It helps make asynchronous code more readable
and easier to manage.
The generator functions work similarly to async/await but with more
explicit control over the execution of effects. You can yield* values from
effects and return the final result at the end.
Example
import { Effect } from "effect"

const addServiceCharge = (amount: number) => amount + 1

const applyDiscount = (
  total: number,
  discountRate: number
): Effect.Effect<number, Error> =>
  discountRate === 0
    ? Effect.fail(new Error("Discount rate cannot be zero"))
    : Effect.succeed(total - (total * discountRate) / 100)

const fetchTransactionAmount = Effect.promise(() => Promise.resolve(100))

const fetchDiscountRate = Effect.promise(() => Promise.resolve(5))

export const program = Effect.gen(function* () {
  const transactionAmount = yield* fetchTransactionAmount
  const discountRate = yield* fetchDiscountRate
  const discountedAmount = yield* applyDiscount(
    transactionAmount,
    discountRate
  )
  const finalAmount = addServiceCharge(discountedAmount)
  return `Final amount to charge: ${finalAmount}`
})
@since2.0.0@categoryCreating Effectsgen(function*() {
  const 
const serviceOne: {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}serviceOne = yield* class ServiceOneServiceOne;
  // We have to manually create this Context then provide it to the helper function
  const const context: Context.Context<ServiceOne>context = pipe<Context.Context<never>, Context.Context<ServiceOne>>(a: Context.Context<never>, ab: (a: Context.Context<never>) => Context.Context<ServiceOne>): Context.Context<ServiceOne> (+19 overloads)
Pipes the value of an expression into a pipeline of functions.
Details
The pipe function is a utility that allows us to compose functions in a
readable and sequential manner. It takes the output of one function and
passes it as the input to the next function in the pipeline. This enables us
to build complex transformations by chaining multiple functions together.
import { pipe } from "effect"

const result = pipe(input, func1, func2, ..., funcN)

In this syntax, input is the initial value, and func1, func2, ...,
funcN are the functions to be applied in sequence. The result of each
function becomes the input for the next function, and the final result is
returned.
Here's an illustration of how pipe works:
┌───────┐    ┌───────┐    ┌───────┐    ┌───────┐    ┌───────┐    ┌────────┐
│ input │───►│ func1 │───►│ func2 │───►│  ...  │───►│ funcN │───►│ result │
└───────┘    └───────┘    └───────┘    └───────┘    └───────┘    └────────┘

It's important to note that functions passed to pipe must have a single
argument because they are only called with a single argument.
When to Use
This is useful in combination with data-last functions as a simulation of
methods:
as.map(f).filter(g)

becomes:
import { pipe, Array } from "effect"

pipe(as, Array.map(f), Array.filter(g))

Example (Chaining Arithmetic Operations)
import { pipe } from "effect"

// Define simple arithmetic operations
const increment = (x: number) => x + 1
const double = (x: number) => x * 2
const subtractTen = (x: number) => x - 10

// Sequentially apply these operations using `pipe`
const result = pipe(5, increment, double, subtractTen)

console.log(result)
// Output: 2
@since2.0.0pipe(
    import Context
@since2.0.0@categorymodels@since2.0.0@categoryModelsContext.const empty: () => Context.Context<never>
Returns an empty Context.
@example
import * as assert from "node:assert"
import { Context } from "effect"

assert.strictEqual(Context.isContext(Context.empty()), true)
@since2.0.0@categoryconstructorsempty(),
    import Context
@since2.0.0@categorymodels@since2.0.0@categoryModelsContext.
const add: <ServiceOne, {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}>(tag: Context.Tag<ServiceOne, {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}>, service: {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}) => <Services>(self: Context.Context<Services>) => Context.Context<ServiceOne | Services> (+1 overload)
Adds a service to a given Context.
@example
import * as assert from "node:assert"
import { Context, pipe } from "effect"

const Port = Context.GenericTag<{ PORT: number }>("Port")
const Timeout = Context.GenericTag<{ TIMEOUT: number }>("Timeout")

const someContext = Context.make(Port, { PORT: 8080 })

const Services = pipe(
  someContext,
  Context.add(Timeout, { TIMEOUT: 5000 })
)

assert.deepStrictEqual(Context.get(Services, Port), { PORT: 8080 })
assert.deepStrictEqual(Context.get(Services, Timeout), { TIMEOUT: 5000 })
@since2.0.0add(class ServiceOneServiceOne, 
const serviceOne: {
    serviceOneMethod(someInput: number): Effect.Effect<string, never, never>;
}serviceOne)
  );
  return {
    serviceTwoMethod: (someInput: number) => Effect.Effect<string, never, never>serviceTwoMethod: import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.const fn: <YieldWrap<Effect.Effect<string, never, never>>, string, [someInput: number]>(body: (someInput: number) => Generator<YieldWrap<Effect.Effect<string, never, never>>, string, never>) => (someInput: number) => Effect.Effect<string, never, never> (+20 overloads)fn(function*(someInput: numbersomeInput) {
      // Because helperFn lives outside the impl, we have to pass a context or
      // eject from DI entirely and pass all services as function params
      return yield* const helperFn: (someInput: number) => Effect.Effect<string, never, ServiceOne>helperFn(someInput: numbersomeInput).Pipeable.pipe<Effect.Effect<string, never, ServiceOne>, Effect.Effect<string, never, never>>(this: Effect.Effect<string, never, ServiceOne>, ab: (_: Effect.Effect<string, never, ServiceOne>) => Effect.Effect<string, never, never>): Effect.Effect<string, never, never> (+21 overloads)pipe(import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.const provide: <ServiceOne>(context: Context.Context<ServiceOne>) => <A, E, R>(self: Effect.Effect<A, E, R>) => Effect.Effect<A, E, Exclude<R, ServiceOne>> (+9 overloads)
Provides necessary dependencies to an effect, removing its environmental
requirements.
Details
This function allows you to supply the required environment for an effect.
The environment can be provided in the form of one or more Layers, a
Context, a Runtime, or a ManagedRuntime. Once the environment is
provided, the effect can run without requiring external dependencies.
You can compose layers to create a modular and reusable way of setting up the
environment for effects. For example, layers can be used to configure
databases, logging services, or any other required dependencies.
Example
import { Context, Effect, Layer } from "effect"

class Database extends Context.Tag("Database")<
  Database,
  { readonly query: (sql: string) => Effect.Effect<Array<unknown>> }
>() {}

const DatabaseLive = Layer.succeed(
  Database,
  {
    // Simulate a database query
    query: (sql: string) => Effect.log(`Executing query: ${sql}`).pipe(Effect.as([]))
  }
)

//      ┌─── Effect<unknown[], never, Database>
//      ▼
const program = Effect.gen(function*() {
  const database = yield* Database
  const result = yield* database.query("SELECT * FROM users")
  return result
})

//      ┌─── Effect<unknown[], never, never>
//      ▼
const runnable = Effect.provide(program, DatabaseLive)

Effect.runPromise(runnable).then(console.log)
// Output:
// timestamp=... level=INFO fiber=#0 message="Executing query: SELECT * FROM users"
// []
@see{@link provideService} for providing a service to an effect.@since2.0.0@categoryContextprovide(const context: Context.Context<ServiceOne>context));
    })
  }
}));

As we get into 5+ services territory the code for specifying dependencies and adding them all to a reusable context starts to smell like unnecessary boilerplate.

const serviceOne = yield* ServiceOne;
const serviceTwo = yield* ServiceTwo;
const serviceThree = yield* ServiceThree;
const serviceFour = yield* ServiceFour;
const serviceFive = yield* ServiceFive;
const context = e.pipe(
  e.Context.empty(),
  e.Context.add(ServiceOne, serviceOne),
  e.Context.add(ServiceTwo, serviceTwo),
  e.Context.add(ServiceThree, serviceThree),
  e.Context.add(ServiceFour, serviceFour),
  e.Context.add(ServiceFive, serviceFive)
)

This is what we’re calling state-of-the-art TypeScript in 2026?

5. Confusing Naming Conventions

Lastly, I’ve always been bothered by Effect’s use of the term “service”. To me, “service” alludes to some outside entity which my code can invoke via some network call, but in Effect a service is basically a singleton instance which encapsulates some common internal logic. “Tag” is also confusing compared to a well-known term like “interface”. I’m aware that Effect is following conventions established by other DI frameworks like ZIO or Angular, but from my POV defaults should be sensible and names shouldn’t be surprising.

Effective Modules

All these headaches had me searching for ways to make Effect feel more self-explanatory and intuitive. Effect seems to be creating the right set of foundational primitives for building production-grade TypeScript, so it seems worthwhile to invest in making these primitives feel good to work with.

Enough experimentation eventually led to something packageable as its own library. I’m calling it Effective Modules. Perhaps some of these ideas / patterns might make their way into Effect core and / or the canonical docs / examples at some point? Let me know what you think.

Effective?

I’m coining the word “Effective” here to mean idiomatic, elegant Effect code. “Effective” is to Effect as “Pythonic” is to Python. Not to be confused with “Effectful”.

Modules?

Modules is my word of choice over “tag” or “service”. Module typically refers to some group of encapsulated code which is internal to a project. Module also implies a grouping of related functionality, and when Uncle Bob first described the Dependency Inversion Principle he used “class” and “module” interchangeably when referring to code building blocks that depend on each other. The wiki article on DIP does this too.

I confess to substituting one overloaded term for another with “modules”

• folders or files can be called modules (e.g. ES Modules or Rust modules)
• libraries can be modules (e.g. Go Modules)
• modules can simply mean a group of code (e.g. NestJS modules)

Despite the phrase’s frequent use, the commonality here is that “module” in all these cases refers to code that’s internal, encapsulated, and logically grouped under a namespace. To me, that’s a more sensible fit than “service”. I’d love to see a rebuttal.

Module Declaration

With Effective Modules, we return to the plain interface.

class class UsersUsers extends import Context
@since2.0.0@categorymodels@since2.0.0@categoryModelsContext.const Tag: <"Users">(id: "Users") => <Self, Shape>() => Context.TagClass<Self, "Users", Shape>
@example
import * as assert from "node:assert"
import { Context, Layer } from "effect"

class MyTag extends Context.Tag("MyTag")<
 MyTag,
 { readonly myNum: number }
>() {
 static Live = Layer.succeed(this, { myNum: 108 })
}
@since2.0.0@categoryconstructorsTag("Users")<
  class UsersUsers,
  {
    
function createUser(username: string, signature: string): Effect.Effect<{
    token: string;
}, BadSignature>createUser(
      username: stringusername: string,
      signature: stringsignature: string
    ): import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.interface Effect<out A, out E = never, out R = never>
The Effect interface defines a value that describes a workflow or job,
which can succeed or fail.
Details
The Effect interface represents a computation that can model a workflow
involving various types of operations, such as synchronous, asynchronous,
concurrent, and parallel interactions. It operates within a context of type
R, and the result can either be a success with a value of type A or a
failure with an error of type E. The Effect is designed to handle complex
interactions with external resources, offering advanced features such as
fiber-based concurrency, scheduling, interruption handling, and scalability.
This makes it suitable for tasks that require fine-grained control over
concurrency and error management.
To execute an Effect value, you need a Runtime, which provides the
environment necessary to run and manage the computation.
@since2.0.0@categoryModels@since2.0.0Effect<{token: stringtoken: string}, class BadSignatureBadSignature>;
    
    
function authenticate(username: string, signature: string): Effect.Effect<{
    token: string;
}, BadSignature>authenticate(
      username: stringusername: string,
      signature: stringsignature: string
    ): import Effect
@since2.0.0@categorymodels@since2.0.0@categorymodels@since2.0.0@categorymodelsEffect.interface Effect<out A, out E = never, out R = never>
The Effect interface defines a value that describes a workflow or job,
which can succeed or fail.
Details
The Effect interface represents a computation that can model a workflow
involving various types of operations, such as synchronous, asynchronous,
concurrent, and parallel interactions. It operates within a context of type
R, and the result can either be a success with a value of type A or a
failure with an error of type E. The Effect is designed to handle complex
interactions with external resources, offering advanced features such as
fiber-based concurrency, scheduling, interruption handling, and scalability.
This makes it suitable for tasks that require fine-grained control over
concurrency and error management.
To execute an Effect value, you need a Runtime, which provides the
environment necessary to run and manage the computation.
@since2.0.0@categoryModels@since2.0.0Effect<{token: stringtoken: string}, class BadSignatureBadSignature>;
  }
>() {}