How Effect-TS and Prisma Make TypeScript Applications Truly Type-Safe

js

How Effect-TS and Prisma Make TypeScript Applications Truly Type-Safe

Discover how combining Effect-TS with Prisma improves error handling, boosts reliability, and makes TypeScript apps easier to maintain.

Dec 28, 2025

How Effect-TS and Prisma Make TypeScript Applications Truly Type-Safe

I’ve been thinking about building more reliable software lately. You know that feeling when your code works perfectly in development, but then fails in production for reasons you can’t understand? I’ve been there too many times. That’s why I’ve been exploring ways to make my TypeScript applications more predictable and easier to maintain. Today, I want to share what I’ve learned about combining Effect-TS with Prisma to create truly type-safe applications.

Have you ever wondered why some errors only show up when your application is live? Let’s change that.

First, let’s look at a common problem. Traditional error handling in TypeScript often leaves us guessing. We write code that looks safe, but errors can slip through. Consider this typical pattern:

async function getUserData(userId: string) {
  const user = await prisma.user.findUnique({ where: { id: userId } });
  if (!user) {
    // What happens here? The error type isn't clear
    throw new Error("User not found");
  }
  return user;
}

The issue is obvious when you think about it. What type of error is this? Who will handle it? How will they know what went wrong? These questions become critical in larger applications.

Effect-TS offers a different approach. It treats errors as data, not as exceptions. This means every possible error is documented in the type system. You can’t forget to handle them because TypeScript will remind you.

Let me show you what I mean. Instead of throwing errors, we define them explicitly:

import { Data } from "effect";

export class UserNotFoundError extends Data.TaggedError("UserNotFoundError")<{
  userId: string;
}> {}

export class DatabaseConnectionError extends Data.TaggedError("DatabaseConnectionError")<{
  cause: unknown;
}> {}

Now, when we write our functions, the types tell the whole story:

import { Effect } from "effect";

function getUserData(userId: string): Effect.Effect<User, UserNotFoundError | DatabaseConnectionError> {
  return Effect.tryPromise({
    try: () => prisma.user.findUnique({ where: { id: userId } }),
    catch: (error) => new DatabaseConnectionError({ cause: error })
  }).pipe(
    Effect.flatMap(user => 
      user 
        ? Effect.succeed(user)
        : Effect.fail(new UserNotFoundError({ userId }))
    )
  );
}

See the difference? The return type clearly states what can go wrong. Anyone using this function knows exactly what errors to handle.

But what about database operations? That’s where Prisma comes in. Prisma gives us type-safe database access, while Effect-TS gives us type-safe error handling. Together, they create a powerful combination.

Let’s build a simple user service to demonstrate. First, we set up our database service:

import { Effect, Context, Layer } from "effect";
import { PrismaClient } from "@prisma/client";

export class DatabaseService extends Context.Tag("DatabaseService")<
  DatabaseService,
  {
    readonly client: PrismaClient;
  }
>() {}

export const DatabaseServiceLive = Layer.effect(
  DatabaseService,
  Effect.sync(() => ({
    client: new PrismaClient()
  }))
);

Now, let’s create a user service that uses this database connection:

export class UserService extends Context.Tag("UserService")<
  UserService,
  {
    readonly createUser: (data: { email: string; name: string }) => 
      Effect.Effect<User, UserNotFoundError | DatabaseConnectionError>;
  }
>() {}

export const UserServiceLive = Layer.effect(
  UserService,
  Effect.gen(function* (_) {
    const db = yield* _(DatabaseService);
    
    return {
      createUser: (data) => 
        Effect.tryPromise({
          try: () => db.client.user.create({ data }),
          catch: (error) => new DatabaseConnectionError({ cause: error })
        })
    };
  })
);

What happens when we need to test this code? That’s where Effect-TS really shines. Because dependencies are explicit, we can easily swap them out for testing.

Here’s how we might test our user service:

import { Effect, Layer } from "effect";

const testUserService = Layer.effect(
  UserService,
  Effect.sync(() => ({
    createUser: (data) => 
      Effect.succeed({
        id: "test-id",
        email: data.email,
        name: data.name,
        createdAt: new Date()
      })
  }))
);

We’ve replaced the real database with a test implementation. The rest of our code doesn’t need to change. This makes testing much simpler.

But what about more complex operations? Let’s say we need to create a user and send a welcome email. With traditional code, this could get messy quickly. With Effect-TS, we can compose operations cleanly:

function registerUser(data: { email: string; name: string }): Effect.Effect<void, UserNotFoundError | EmailError | DatabaseConnectionError> {
  return Effect.gen(function* (_) {
    const user = yield* _(createUser(data));
    yield* _(sendWelcomeEmail(user.email));
    yield* _(logRegistration(user.id));
  });
}

Each step can fail, and each possible failure is documented. The code reads like a story: create user, send email, log registration. If any step fails, the whole operation stops, and we know exactly what went wrong.

Have you noticed how much clearer the error handling becomes? Instead of nested try-catch blocks, we have a clean pipeline of operations. Each step’s possible errors are visible in the type signature.

Let’s look at a more complete example. Suppose we’re building an e-commerce system. We need to process orders, check inventory, and handle payments. Here’s how we might structure that:

function processOrder(orderId: string): Effect.Effect<OrderResult, ProcessOrderError> {
  return Effect.gen(function* (_) {
    const order = yield* _(getOrder(orderId));
    yield* _(validateInventory(order.items));
    yield* _(processPayment(order.total));
    yield* _(updateOrderStatus(orderId, "COMPLETED"));
    return { success: true, orderId };
  }).pipe(
    Effect.catchAll(error => 
      Effect.gen(function* (_) {
        yield* _(updateOrderStatus(orderId, "FAILED"));
        yield* _(logOrderFailure(orderId, error));
        return { success: false, orderId, error };
      })
    )
  );
}

Even the error recovery is type-safe and explicit. We know exactly what errors can occur, and we handle them in a structured way.

What about performance? You might think all this type safety comes at a cost. In my experience, the benefits far outweigh any minimal overhead. The clarity and reliability you gain make development faster in the long run.

Let me share a personal story. I recently migrated a production API to use Effect-TS and Prisma. Before the migration, we had several production incidents related to unhandled errors. After the migration? Zero. The type system caught potential issues before they reached production.

The migration wasn’t without challenges. The team had to learn new patterns. But once we adjusted, our code became more predictable. New team members could understand the error handling just by reading the types. Code reviews became easier because the types documented the behavior.

Here’s a practical tip: start small. You don’t need to rewrite your entire application at once. Begin with a single service or module. Get comfortable with the patterns. Then gradually expand.

Consider this: what if your entire codebase documented its error handling in the types? How much time would that save in debugging? How many production issues would it prevent?

I want to leave you with a challenge. Look at your current project. Find one function that throws errors. Try rewriting it with Effect-TS. See how much clearer the error handling becomes. Notice how the types tell you exactly what can go wrong.

The journey to more reliable software starts with small steps. Effect-TS and Prisma are tools that can help. They won’t solve all your problems, but they’ll make many common issues impossible to ignore.

What has your experience been with type safety in TypeScript? Have you tried functional programming patterns before? I’d love to hear your thoughts and experiences. Share your stories in the comments below. If you found this helpful, please share it with others who might benefit. Let’s build more reliable software together.

As a best-selling author, I invite you to explore my books on Amazon. Don’t forget to follow me on Medium and show your support. Thank you! Your support means the world!

101 Books

101 Books is an AI-driven publishing company co-founded by author Aarav Joshi. By leveraging advanced AI technology, we keep our publishing costs incredibly low—some books are priced as low as $4—making quality knowledge accessible to everyone.

Check out our book Golang Clean Code available on Amazon.

Stay tuned for updates and exciting news. When shopping for books, search for Aarav Joshi to find more of our titles. Use the provided link to enjoy special discounts!

📘 Checkout my latest ebook for free on my channel!
Be sure to like, share, comment, and subscribe to the channel!

Our Creations

Be sure to check out our creations:

We are on Medium

Share: Facebook Twitter Reddit LinkedIn WhatsApp Telegram Pinterest Email Instagram

js