DEV Community: explita

Stop manually stripping Prisma inputs. Generate Zod schemas & guard your DB automatically.

explita — Fri, 22 May 2026 08:08:21 +0000

If you use Prisma, you already know it's a fantastic ORM with excellent developer experience. But there's a common friction point almost all of us hit when building real-world APIs: input validation and sanitization.

Prisma is strict. If a user passes an unknown field in a .create() or .update() payload (like an injected isAdmin: true), Prisma throws an error. So what do you do? You end up writing tedious mapping functions, picking fields manually, or writing massive Zod schemas by hand to validate and strip out the junk before it reaches Prisma.

What if your Prisma schema could just... do it all for you?

Enter Prisma Guard 🛡️.

What is Prisma Guard?

Prisma Guard is the ultimate Prisma companion designed to bridge the gap between database models and API validation. It does two main things:

Runtime Protection (The Guard): A Prisma Client extension that silently strips unknown fields from your queries at runtime.
Schema Generation (The Magic): Automatically transforms your .prisma models into robust, decorated Zod schemas with complete type-safety.

It's completely zero-config out of the box (it even manages your .gitignore and Prettier formatting for generated files), but offers immense power for those who need custom validation logic.

✌️ Two Ways to Use It

Depending on your needs, you can use Prisma Guard in two modes.

Mode 1: Runtime Protection Only (The Quick Fix)

If you just want to stop Prisma from throwing errors when random fields are passed from the frontend, just add the extension to your client:

import { PrismaClient } from "@prisma/client";
import { prismaGuard } from "@explita/prisma-guard";

const prisma = new PrismaClient().$extends(prismaGuard());

// Any extra fields passed to 'data' will be silently stripped
await prisma.user.create({
  data: {
    email: "user@example.com",
    poisonField: "will be removed", // Poof! Gone.
  },
});

Mode 2: Full Validation & Schema Generation (Recommended)

This is where the real magic happens. By running npx prisma-guard, it reads your Prisma schema and generates perfect Zod schemas.

Your Prisma Schema:

model User {
  id        String   @id @default(cuid())
  email     String   @unique
  password  String
  createdAt DateTime @default(now())
}

What you get:

export const UserCreateSchema = z.object({
  email: z.string().trim().min(1, { message: "This field is required" }),
  password: z.string().trim().min(1),
  // id and createdAt are managed by Prisma defaults or omitted entirely depending on your config!
});

💎 Advanced Type Ergonomics & Dual Schemas

One of the biggest headaches with schema generation is that a "public" API schema shouldn't include sensitive internal database fields (like secretApiKey or tenantId).

Prisma Guard handles this beautifully by generating Dual Schemas for every model:

Public Schemas (UserCreateSchema): Respects your omission rules. Perfect for API request validation.
Scalar Schemas (UserCreateScalarSchema): Includes every database field. Perfect for internal services and database operations.

It also exports a suite of ergonomic TypeScript types (UserCreate, UserUpdate, UserCreateRequired) so your service layers are always perfectly typed.

🎨 The Power of Decorators (and the `v` proxy)

Sometimes z.string() isn't enough. You need .email(), .min(8), or custom refinement logic. Prisma Guard lets you define this cleanly using triple-slash comments (///).

Instead of polluting your Prisma schema with massive strings of Zod code, Prisma Guard introduces the v proxy in a prisma-guard.config.js file:

// prisma-guard.config.js
import { defineConfig, v } from "@explita/prisma-guard";

export default defineConfig({
  decorators: {
    // Chain validations onto the inferred Prisma type
    email: v.chain.email().trim().toLowerCase(),

    // Completely override a type
    strongPassword: v.string().min(12).regex(/[A-Z]/),
  },
});

Then, you just use them in your Prisma schema!

model User {
  id       String @id

  /// @zod.use(email)
  email    String

  /// @zod.use(strongPassword)
  password String
}

IDE Superpowers 🪄

No one likes typing out decorators from memory. Prisma Guard includes an incredible npx prisma-guard metadata --vscode command that automatically installs VS Code snippets for every Zod method. You literally get autocompletion inside your .prisma files!

⚡ Blazing Fast Performance

You might be thinking: "Doesn't a runtime guard slow down my queries?"

The answer is no. The runtime guard is designed for ultra-low latency. It uses strict $O(n)$ complexity (looping only over predefined schema fields instead of arbitrary user input), memoized whitelists, and hot-path early exits.

In benchmarks of 100,000 recursive sanitization iterations on a complex payload:

Total duration: 221.26ms
Average per query: 2.21 microseconds (0.0022ms)

If your database query takes 10-50ms, adding 0.0022ms introduces virtually 0% overhead.

🚀 Get Started in 2 Minutes

Stop wasting time manually maintaining Zod schemas that drift out of sync with your database.

Install the package:

npm install @explita/prisma-guard

Initialize your config:

npx prisma-guard init

Generate the magic:

npx prisma-guard

Check out the full documentation, advanced relation handling, and custom schema generation features on our GitHub Repository.

If Prisma Guard saves you time, I'd deeply appreciate a ⭐ on GitHub! Let me know what you think in the comments below. Happy coding! 🚀

Stop Writing Manual Database Triggers: Automatic Audit Logging in Prisma

explita — Thu, 21 May 2026 12:25:08 +0000

Picture this: A critical database record is modified or deleted in production. Customer support is flooded, and your manager asks, "Who did this, what was changed, and what did it look like before?"

If you don't have audit logging set up, you're stuck digging through database transaction logs, parsing raw server outputs, or doing forensic database recovery. It's stressful, slow, and completely avoidable.

But building audit logging is notoriously tedious:

Database Triggers are hard to maintain, slow, and don't know anything about your application context (like the HTTP Request IP or the active User Session).
Manual Service Logging requires you to write boilerplate code around every database update, mutation, and delete in your entire codebase. One missing line, and your audit log is incomplete.

To solve this once and for all, I built Prisma Audit Log.

It’s a native Prisma Client extension that automatically intercepts your queries (create, update, delete, upsert, and batch operations) to log changes. Because it runs directly inside your application code, it captures full request context and user details seamlessly.

Here is how to set it up and what it gives you.

1. The Audit Log Schema

First, add an AuditLog model to your schema.prisma file. This is where your audit records will be stored:

model AuditLog {
  id            String   @id @default(cuid())
  userId        String?  @map("user_id")
  recordId      String   @map("record_id")
  action        String   // "create" | "update" | "delete"
  model         String   // E.g. "User", "Post"
  oldData       Json?    @map("old_data")
  newData       Json?    @map("new_data")
  changedFields String[] @map("changed_fields")
  ipAddress     String?  @map("ip_address")
  userAgent     String?  @map("user_agent")
  metadata      Json?
  createdAt     DateTime @default(now()) @map("created_at")

  @@map("audit_logs")
}

2. Basic Extension Setup

You can register the audit log extension on your existing PrismaClient in seconds:

import { PrismaClient } from "@prisma/client";
import { auditLogExtension } from "@explita/prisma-audit-log";
import { getAuthContext } from "@/lib/auth"; // Your auth/request storage

const prisma = new PrismaClient().$extends(
  auditLogExtension({
    // 1. Context-Aware Logging: Automatically capture user/network context
    getContext: () => {
      const session = getAuthContext();
      return {
        userId: session?.userId || "anonymous",
        ipAddress: session?.ip,
        userAgent: session?.userAgent,
        metadata: {
          tenantId: session?.tenantId,
        },
      };
    },

    // 2. Data Sanitization: Mask passwords or security tokens globally
    maskFields: ["password", "token", "creditCard"],
    maskValue: "[REDACTED]",

    // 3. Fine-grained filtering per model
    fieldFilters: {
      User: {
        exclude: ["refreshToken", "passwordSalt"],
      },
      Payment: {
        include: ["id", "amount", "status", "createdAt"], // Whitelist only
      },
    },

    // 4. Skip unnecessary logging (e.g. high-frequency sessions)
    skip: ({ model, operation }) => {
      if (model === "Session" && operation === "create") return true;
      return false;
    },
  })
);

3. What Happens Under the Hood?

Once registered, you write your normal database queries, and Prisma Audit Log handles the rest behind the scenes.

For example, when you perform a normal Prisma update:

await prisma.user.update({
  where: { id: "user_abc" },
  data: {
    email: "newemail@example.com",
    role: "ADMIN",
  },
});

The extension intercepts this, calculates the diff between the database state before and after, and creates a record that looks like this:

{
  "id": "log_12345",
  "userId": "admin_user_id",
  "recordId": "user_abc",
  "action": "update",
  "model": "User",
  "oldData": {
    "id": "user_abc",
    "email": "oldemail@example.com",
    "role": "USER"
  },
  "newData": {
    "id": "user_abc",
    "email": "newemail@example.com",
    "role": "ADMIN"
  },
  "changedFields": ["email", "role"],
  "ipAddress": "192.168.1.1",
  "userAgent": "Mozilla/5.0...",
  "metadata": { "tenantId": "tenant_1" },
  "createdAt": "2026-05-21T13:15:34Z"
}

4. Key Developer-First Features

Here are some details I built in to keep database logs clean, performant, and safe:

🔇 Noise-Free Update Logs

Have you ever seen audit logs filled with thousands of rows where nothing actually changed? Prisma updates often touch a model's updatedAt field or re-save unmodified fields. Prisma Audit Log automatically detects if only the timestamp fields changed, and quietly skips creating an audit entry. Your logs stay clean and noise-free.

⚡ Efficient Batch Processing

When you run bulk operations like createMany, updateMany, or deleteMany, inserting audit logs one-by-one is a performance killer. The extension groups and batches these operations, falling back gracefully to single inserts only when necessary.

🔌 Send Logs Anywhere

By default, the extension saves audit logs directly to your AuditLog table using the Prisma schema above. But if you want to stream logs to an external service (like Datadog, Axiom, or a Kafka queue), you can override the target using a custom logger callback:

auditLogExtension({
  logger: async (logs) => {
    // Send logs to Elasticsearch, Datadog, or cloud storage
    await datadogClient.send(logs);
  }
})

Give it a try! 🚀

Prisma Audit Log is open-source (MIT licensed) and ready for use. If you're building systems that require database compliance, transparency, or debugging reassurance, give it a spin:

NPM: npm i @explita/prisma-audit-log
GitHub: github.com/explita/prisma-audit-log

If this helps you sleep a bit better at night knowing your database history is safe, I'd love a GitHub ⭐! Let me know in the comments if you have any questions or feature suggestions.

Why I Built My Own TypeScript RPC Framework (And Why You Might Actually Want It)

explita — Thu, 21 May 2026 12:11:49 +0000

I have a problem.

Every time I start building a Next.js application, I find myself fighting the exact same set of friction points:

Fragile Type Safety: Type safety that works beautifully on the server but quietly disintegrates or requires manual alignment across the network boundary.
Dev-Loop Bloat: Codegen tools and compilation steps that add 15 to 30 seconds of waiting time to my dev loop.
Imprecise Error Handling: Catching errors that is either overly verbose (try-catch blocks wrapping every handler) or non-existent.
Manual Plumbing: Wiring up Redis caching, rate limiting, and circuit breakers manually, procedure by procedure, project by project.

So, I did the classic, slightly unhealthy developer thing: I built my own solution.

It’s called Actyx RPC. And before you roll your eyes at the mention of another "typesafe RPC framework" (trust me, I know there are like seventeen of these now) — hear me out. Actyx isn't just about sharing types; it's about solving the practical, everyday headaches of production backend development in TypeScript.

Here is how it works and why it’s become my go-to stack.

1. The Foundation: A Composable Base Procedure

Instead of setting up boilerplate for every route, Actyx uses a builder pattern. You define a base procedure instance that handles authentication, error mapping, telemetry, and input enrichment globally. Every procedure you create from this base builder automatically inherits these behaviors.

import { createProcedure, RedisCache } from "@explita/actyx-rpc";
import { redirect } from "next/navigation";

// Optional: Spin up Redis for cross-serverless caching and rate limiting
// const redisClient = new Redis("redis://localhost:6379");

export const procedure = createProcedure({
  // cache: new RedisCache({ redis: redisClient, defaultTTL: "5m" }),

  // 1. Establish the request context (Auth, session, user roles)
  async createContext() {
    const session = await getSession();

    if (!session) {
      return { ok: false, reason: "INVALID_SESSION" };
    }

    return {
      ok: true,
      ctx: {
        userId: session.user.id,
        role: session.user.role,
      },
    };
  },

  // 2. Automatically handle context failures (like redirects or custom errors)
  // This is only called when the createContext returns an object with ok:false
  onContextError: async ({ reason }) => {
    const loginPath = "/login";
    if (reason === "INVALID_SESSION") {
      return {
        _redirect: () => redirect(loginPath),
      };
    }
    return {
      success: false,
      reason: "UNAUTHORIZED",
      message: "Unauthorized access",
    };
  },

  // 3. Centralized error mapping — no try/catch pyramids in your handlers!
  onError({ error, ctx }) {
    console.error(`[Error in ${ctx.handlerName}]:`, error);

    // Map database constraints (like Prisma unique key violations) globally
    if (error.code === "P2002") {
      return {
        message: "This record already exists",
        reason: "CONFLICT",
        statusCode: 409,
      };
    }
  },

  // 4. Enrich every incoming handler input with context variables automatically
  enrichInput(ctx) {
    return { userId: ctx.userId };
  },
});

Now, every procedure created from this procedure builder gets auth context checks, global error transforms, and user ID injection with zero additional lines of code.

2. Defining and Calling Procedures

Actyx RPC keeps procedures simple. You define inputs using your validator of choice (Zod, Valibot, ArkType, Joi, Yup, or custom resolvers) and resolve them as either .query() (for reads) or .mutation() (for writes).

import { z } from "zod";
import { zodResolver } from "@explita/actyx-rpc/resolvers/zod";
import { db } from "@/lib/db";
import { procedure } from "./base-procedure";

// Create a mutation procedure
export const createPost = procedure
  .name("createPost")
  .input(
    zodResolver(
      z.object({
        title: z.string().min(1),
        body: z.string().min(10),
      }),
    ),
  )
  .mutation(async ({ ctx, input }) => {
    // ctx.userId is fully typed and available
    // input.title and input.body are validated, typed, and sanitized
    // input.userId is injected from enrichInput!
    return await db.post.create({
      data: {
        title: input.title,
        body: input.body,
        authorId: input.userId,
      },
    });
  });

When you call this procedure, Actyx returns a Go-style [data, error] tuple. No try/catch blocks needed:

const [post, err] = await createPost({
  title: "A Brand New Post",
  body: "This is a body longer than ten characters.",
});

if (err) {
  toast.error(err.message);
  return;
}

console.log(post.id); // 'post' is fully typed!

3. The Features That Surprised Me (DX Wins)

While building Actyx, I added a few features to solve my own development fatigue, and they turned out to be absolute game-changers:

💡 The `.mock()` Method (For Parallel Development)

Seeding and maintaining local databases just to test a frontend feature is exhausting. Actyx introduces first-class mocking directly in the builder chain:

export const getUser = procedure
  .name("getUser")
  .mock(() => ({
    id: "user_mock_123",
    name: "Jane Doe (Mocked)",
    email: "jane@example.com",
  }))
  .query(async ({ input }) => {
    // This expensive DB query is skipped when MOCKing is active!
    return await db.users.findUnique({ where: { id: input.id } });
  });

Set ACTYX_MOCK="true" in your environment variables, and the backend handlers are bypassed. The middleware, session validation, and inputs are still processed, but your database is never touched. Frontend devs can code against a "perfect" mock state while the backend is still being designed.

🧠 Caching with a Brain (SWR Built-in)

Actyx comes with Stale-While-revalidate (SWR) caching out of the box. You don't need Redis to get started; an in-memory cache adapter works by default, but you can plug in Redis as you scale:

export const getPost = procedure
  .cache({
    ttl: "5m", // Fresh for 5 minutes
    staleTime: "1m", // Becomes stale after 1 minute
    staleWhileRevalidate: true, // Serve stale data, refresh in the background
    key: ({ input }) => `post:${input.id}`,
  })
  .query(async ({ input }) => {
    return await db.post.findUnique({ where: { id: input.id } });
  });

🛡️ Serverless-Friendly Rate Limiting

Because Actyx can plug directly into your Redis cache adapter, rate limiting persists across serverless function invocations (like Vercel Serverless/AWS Lambda instances).

export const sendMessage = procedure
  .rateLimit({
    limit: 10,
    window: "1m",
    key: (ctx) => ctx.userId, // Limit requests per user
    message: "You're sending messages too fast!",
  })
  .mutation(async ({ input }) => {
    return await messageService.send(input);
  });

🔗 Inter-Procedure Calling (Zero Network Hops)

When procedures call other procedures, network overhead and duplicated auth logic usually slow things down. Actyx uses AsyncLocalStorage under the hood. When one procedure calls another, it bypasses context re-creation and authentication entirely while keeping the context secure:

const getAuditLog = procedure.query(async ({ ctx }) => {
  return await db.logs.findMany({ where: { userId: ctx.userId } });
});

export const getUserDashboard = procedure.query(async ({ ctx }) => {
  const user = await db.users.findUnique({ where: { id: ctx.userId } });

  // This nested call automatically inherits the parent's auth context!
  const [logs] = await getAuditLog();

  return { user, logs };
});

4. What Else is in the Box?

To make Actyx a production-ready choice, I added several advanced features:

OpenTelemetry: Native instrumentation so you can trace why a specific procedure is running slow at 3 AM.
Automatic OpenAPI Specs: Auto-generate standard OpenAPI JSON files to keep documentation from rotting.
Circuit Breakers: Prevent cascading failures when third-party microservices go down.
Adaptive Compression: Native support for gzip, deflate, and brotli.
Timeouts: Safe defaults to prevent hanging server processes.
React Hooks: Built-in hooks (useQuery, useMutation, useInfiniteQuery) for frontend state synchronization.

What I Haven't Figured Out Yet

Actyx is working great for my production projects, but it’s still in active development. Here’s what’s currently on my drawing board:

Bidirectional WebSockets: SSE (Server-Sent Events) streaming works perfectly for one-way flows (like LLM stream responses), but full bidirectional WS subscriptions are still being refined.
Performance Benchmarks: It feels lightning-fast under typical workloads, but I want to perform strict load/torture tests to publish concrete numbers.

If you have experience building scalable RPC networks or websocket adapters, I'd love to hear how you approached those challenges!

Give it a Spin 🚀

Actyx RPC is entirely open-source (MIT licensed). Break it, inspect it, and tell me what you think.

NPM: npm i @explita/actyx-rpc
GitHub: github.com/explita/actyx-rpc

P.S. — The name "Actyx" comes from "action" + "tyx" (as in type safety). Naming is hard. If you have a better suggestion, I'm all ears!