The Problem Effet Services Solve

Programs have requirements.

Let’s say you have an application with a function named sendPasswordResetEmail. When a user clicks “Forgot Password”, this function sends them an email with a reset link.

You decide to use Amazon SES (Simple Email Service) to send the email. Here’s what the code might look like:

1
import { SESClient, SendEmailCommand } from "@aws-sdk/client-ses";
2

3
class SendPasswordResetEmailError extends Error {
4
  constructor(cause: unknown) {
5
    super("Failed to send the password reset email");
6
    this.name = "SendPasswordResetEmailError";
7
    this.cause = cause;
8
  }
9
}
10

11
const sesClient = new SESClient({
12
  region: "us-east-1",
13
  credentials: {
14
    accessKeyId: "your-access-key-id",
15
    secretAccessKey: "your-secret-access-key",
16
  },
17
});
18

19
async function sendPasswordResetEmail(to: string, resetLink: string) {
20
  try {
21
    const command = new SendEmailCommand({
22
      Destination: { ToAddresses: [to] },
23
      Message: {
24
        Body: {
25
          Html: {
26
            Charset: "UTF-8",
27
            Data: `
28
              <h1>Password Reset</h1>
29
              <p>Click the link below to reset your password:</p>
30
              <a href="${resetLink}">Reset Password</a>
31
            `,
32
          },
33
        },
34
        Subject: {
35
          Charset: "UTF-8",
36
          Data: "Reset Your Password",
37
        },
38
      },
39
      Source: "noreply@yourapp.com",
40
    });
41

42
    await sesClient.send(command);
43
    return { success: true };
44
  } catch (error) {
45
    return new SendPasswordResetEmailError(error);
46
  }
47
}

The code works. You call sendPasswordResetEmail("user@example.com", "https://yourapp.com/reset?token=abc123") and the user gets their email.

Now, I have a question for you. Can you tell me what the requirements of the sendPasswordResetEmail function are?

Just by looking at the arguments sendPasswordResetEmail accepts, you might say the function requires a recipient address and a reset link to do its job. But that would be a lie. The function also depends on an email client (sesClient in our case) to do its job. That dependency is invisible from the function’s signature. A developer reading sendPasswordResetEmail(to: string, resetLink: string) has no way to know, just from the arguments, that the function depends on sesClient.

Besides hiding its true requirements, the function has another issue. It is tightly coupled to a specific email client. If your application had other email-sending functions such as sendWelcomeEmail, sendApprovalEmail, sendInvoiceEmail, and you decided to swap AWS SES for Resend, you would need to change the code in every single one of these functions.

Now if you think about it for a moment, why does sendPasswordResetEmail need to know about a specific email client? It only needs an email client to send the email. It does not have to concern itself with whether the email client is SES, Resend, SendGrid, or something else.

Dependency Injection

In the previous section, we discussed how the sendPasswordResetEmail function lies about its dependencies. So how can we solve this problem?

The fix is straightforward. Instead of the function reaching for an email client on its own, we can provide that email client from the outside as an argument. Here is how the code would look:

1
import { SESClient, SendEmailCommand } from "@aws-sdk/client-ses";
2

3
async function sendPasswordResetEmail(
4
  emailClient: SESClient,
5
  to: string,
6
  resetLink: string,
7
) {
8
  try {
9
    const command = new SendEmailCommand({
10
      Destination: { ToAddresses: [to] },
11
      Message: {
12
        Body: {
13
          Html: {
14
            Charset: "UTF-8",
15
            Data: `
16
              <h1>Password Reset</h1>
17
              <p>Click the link below to reset your password:</p>
18
              <a href="${resetLink}">Reset Password</a>
19
            `,
20
          },
21
        },
22
        Subject: {
23
          Charset: "UTF-8",
24
          Data: "Reset Your Password",
25
        },
26
      },
27
      Source: "noreply@yourapp.com",
28
    });
29

30
    await emailClient.send(command);
31
    return { success: true };
32
  } catch (error) {
33
    return new SendPasswordResetEmailError(error);
34
  }
35
}

Now, just by looking at the function signature, anyone can tell that sendPasswordResetEmail depends on an email client, a recipient address, and a reset link. The function no longer lies about its requirements. This idea of providing dependencies from the outside rather than letting functions create their own is called dependency injection.

Dependency injection made the dependencies of sendPasswordResetEmail visible. But it introduced another problem. What happens when the function needs more dependencies, say a logger and a configuration object?

1
async function sendPasswordResetEmail(
2
  emailClient: SESClient,
3
  logger: Logger,
4
  config: AppConfig,
5
  to: string,
6
  resetLink: string,
7
): Promise<void> {
8
  // ...
9
}

And the function that calls sendPasswordResetEmail also needs its own dependencies:

1
async function handleForgotPassword(
2
  emailClient: SESClient,
3
  logger: Logger,
4
  config: AppConfig,
5
  email: string,
6
) {
7
  const resetLink = `${config.baseUrl}/reset?token=agr38b`;
8
  return sendPasswordResetEmail(emailClient, email, resetLink);
9
}

Every function has to accept its own dependencies plus all the dependencies of every function it calls. The parameter lists grow. The calling code becomes noisy. You end up threading dependencies through five layers of function calls just so some deeply nested function can access a logger.

This is the fundamental tension: coupling is bad, but manually passing dependencies everywhere is also bad.

We need a system that automatically makes dependencies available to any function that needs them, no matter how deep in the call chain, and tracks all of this at the type level so the compiler tells us if we forgot to provide something. This is exactly what Effect Services do.