Forem: ZenStack

Prisma vs Drizzle vs ZenStack: Choosing a TypeScript ORM in 2026

ymc9 — Thu, 02 Apr 2026 17:00:00 +0000

If you've built a TypeScript backend in the last few years, you've probably used Prisma. It earned its place as the default choice — a clean schema language, an intuitive query API, and type safety that felt almost magical at the time.

But the TypeScript ORM space has quietly matured. Drizzle emerged as a serious alternative for developers who felt Prisma was too opinionated. And ZenStack v3 just completed a full rewrite that positions it not just as an ORM, but as a full-stack data layer.

Three tools, three distinct bets on what "great database access" means in 2026. This post breaks them down so you can pick the right one for your project.

Disclosure: This post is published by the ZenStack team. We've done our best to represent Prisma and Drizzle fairly, but you should factor that context into how you weigh the comparisons.

1. The Three Philosophies

Before comparing features and APIs, it helps to understand what each tool is actually optimizing for.

Prisma is schema-first and proud of it. You define your data model in a dedicated .prisma file, run a generator, and get a fully-typed client. The goal is maximum developer experience with minimum friction — you shouldn't need to think about SQL.

Drizzle takes the opposite bet. Your schema is TypeScript, your queries look like SQL, and the library stays thin on purpose. It does offer ORM-style queries too, but they feel more like a convenience layer on top of the SQL-first core than a first-class citizen. It trusts you to know what you're doing and gets out of the way. If you've ever felt ORMs were hiding too much, Drizzle is built for that instinct.

ZenStack starts where Prisma left off. It uses a Prisma-compatible schema language and a familiar query API, but expands the scope far beyond ORM territory — built-in access control, auto-generated CRUD APIs, frontend query hooks, and a plugin system for everything else. It's schema-first like Prisma, but engineered to cover much more of the full-stack surface area. On the API side, it gives you both ends of the query spectrum: an ORM API for day-to-day simplicity, and a SQL-style query builder (powered by Kysely) when you need precise control.

2. Data Modeling

The way you define your schema shapes everything downstream — how you think about your data and how much type safety you get out of the box.

Let's use a simple but realistic example: a User that has many Posts, where each post has a published status.

Prisma uses its own schema language (PSL):

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  posts Post[]
}

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  published Boolean @default(false)
  author    User    @relation(fields: [authorId], references: [id])
  authorId  Int
}

Clean and readable, even to non-developers. Prisma generates a fully-typed client from this schema, giving you strong type inference across your entire codebase.

Drizzle keeps the schema in TypeScript — no separate file, no custom language:

import { pgTable, serial, text, boolean, integer } from 'drizzle-orm/pg-core';

export const users = pgTable('users', {
  id: serial('id').primaryKey(),
  email: text('email').notNull().unique(),
});

export const posts = pgTable('posts', {
  id: serial('id').primaryKey(),
  title: text('title').notNull(),
  published: boolean('published').default(false),
  authorId: integer('author_id').references(() => users.id),
});

No magic, no code generation step. The schema is just TypeScript, which means your editor, your linter, and your CI pipeline all understand it natively.

ZenStack uses a superset of Prisma's schema language, called ZModel. If you're coming from Prisma, the model definitions are identical — in fact, renaming your .prisma file to .zmodel is a valid starting point:

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  posts Post[]

  @@allow('all', auth() == this)
}

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  published Boolean @default(false)
  author    User    @relation(fields: [authorId], references: [id])
  authorId  Int

  @@allow('read', published)
  @@allow('all', auth() == author)
}

The @@allow lines are access policies — more on those in section 4. The point here is that the data modeling syntax is familiar, and since ZenStack generates the same underlying database schema as Prisma, switching costs are low.

The takeaway: if your team prefers keeping everything in TypeScript, Drizzle wins on schema. If you want a dedicated, readable schema language, Prisma and ZenStack are effectively tied — with ZenStack gaining an edge as soon as access control or other advanced features enter the picture.

3. Querying

Let's fetch something realistic: all published posts for a given user, including the author's email. Same query, three tools.

Prisma uses a nested object API that closely mirrors the shape of your schema:

const posts = await prisma.post.findMany({
  where: {
    authorId: userId,
    published: true,
  },
  include: {
    author: {
      select: { email: true },
    },
  },
});

Readable, predictable, and fully typed. The result shape is inferred automatically — posts[0].author.email is typed as string with no extra work. For the vast majority of queries, this API is a pleasure to use.

Drizzle expresses the same query in a style that will feel immediately familiar if you know SQL:

const posts = await db
  .select({
    id: postsTable.id,
    title: postsTable.title,
    authorEmail: usersTable.email,
  })
  .from(postsTable)
  .innerJoin(usersTable, eq(postsTable.authorId, usersTable.id))
  .where(and(eq(postsTable.authorId, userId), eq(postsTable.published, true)));

More verbose, but nothing is hidden. You control exactly which columns are selected, how joins are constructed, and what the result shape looks like. For developers who think in SQL, this reads naturally. For those who don't, it's a steeper mental overhead.

ZenStack offers both styles. The Prisma-compatible API works identically:

const posts = await db.post.findMany({
  where: {
    authorId: userId,
    published: true,
  },
  include: {
    author: {
      select: { email: true },
    },
  },
});

And when you need more control, you can drop down to the Kysely query builder, which gives you full SQL power and even better typing than Drizzle's:

const posts = await db.$qb
  .selectFrom('Post')
  .innerJoin('User', 'User.id', 'Post.authorId')
  .select(['Post.id', 'Post.title', 'User.email as authorEmail'])
  .where('Post.authorId', '=', userId)
  .where('Post.published', '=', true)
  .execute();

The ability to mix both styles in the same codebase — using the high-level API for routine queries and dropping to the query builder when precision matters — is one of ZenStack's more practical advantages.

The takeaway: Prisma's query API is the most approachable. Drizzle's is the most SQL-faithful. ZenStack covers both ends.

4. Access Control & Multi-Tenancy

Access control is where the three tools diverge most sharply. Let's use a concrete rule: users can only read their own posts, and only published posts are visible to others.

Prisma has no built-in access control. You implement it manually, typically by adding where clauses wherever you query:

const posts = await prisma.post.findMany({
  where: {
    OR: [
      { authorId: userId },
      { published: true },
    ],
  },
});

This works, but it scales poorly. Every query is a new opportunity to forget a condition. In a large codebase with many developers and AI agents, enforcing consistent access rules this way requires discipline, code reviews, and a fair amount of trust.

Drizzle is in the same position — access control is entirely your responsibility:

const posts = await db
  .select()
  .from(postsTable)
  .where(
    or(
      eq(postsTable.published, true),
      eq(postsTable.authorId, currentUser.id)
    )
  );

Worth noting: PostgreSQL's Row-Level Security (RLS) is a viable alternative for both tools — Drizzle even has first-class modeling support for it. The trade-offs are real though: RLS policies are harder to write and test, add operational complexity, and can surprise developers who don't expect business logic at the database layer.

ZenStack treats access control as a first-class concern, defined once in the schema and enforced automatically at runtime. The enforcement is handled on the application level, so it works regardless of your database choice and doesn't require any special database features. You express policies declaratively in the schema using the @@allow and @@deny attributes:

model Post {
  id        Int     @id @default(autoincrement())
  title     String
  published Boolean
  author    User    @relation(fields: [authorId], references: [id])
  authorId  Int

  // authors can do anything to their own posts
  @@allow('all', auth() == author)
  // published posts are visible to everyone
  @@allow('read', published)
}

With these policies in place, every query through a ZenStack client automatically respects them — no manual where clauses needed:

const authDb = db.$setAuth({ id: currentUser.id });
const posts = await authDb.post.findMany();

The trade-off: ZenStack's approach is more powerful but also more opinionated. You're trusting the policy engine to handle enforcement correctly, which requires learning its rules and edge cases. For simple applications, Prisma or Drizzle's manual approach may feel more transparent. For anything with real multi-tenancy requirements — SaaS products, team-scoped data, role-based access — the ZenStack model pays for itself quickly.

5. API & Framework Integration

Writing database queries is only part of the story. In a full-stack TypeScript app, you also need to expose that data to your frontend — which typically means building an API layer on top of your ORM (unless you fully opt-in to server-side rendering). This is where the three tools have very different stories.

Prisma and Drizzle are both database libraries, not API frameworks. They have no opinion on how you expose data to the outside world. You write the API yourself — whether that's REST routes in Express, route handlers in Next.js, or a GraphQL resolver layer. This is the right call for many teams: full control, no surprises, no magic. The downside is that it's boilerplate you write and maintain for every project.

A typical Next.js route handler with Prisma/Drizzle looks like:

// API route for fetching published posts
export async function GET(request: Request) {
  const posts = await db.post.findMany({
    where: { published: true },
  });
  return Response.json(posts);
}

Straightforward, but multiply this across every model and every operation and it adds up fast.

ZenStack can follow the same pattern — you can use it exactly like Prisma and write your own routes. But it also offers an alternative: automatically mounting a full CRUD API directly from your schema, with access policies already enforced:

import { NextRequestHandler } from '@zenstackhq/server/next';
import { db } from '@/lib/db';
import { getSessionUser } from '@/lib/auth';

// API handler for all CRUD operations for all models, with access control enforced
const handler = NextRequestHandler({
  getClient: async (req) => db.$setAuth(await getSessionUser(req)),
});

export { handler as GET, handler as POST, handler as PUT, handler as DELETE };

That single file gives you a fully secured data API for every model in your schema — no additional route handlers needed. The access policies you defined in the schema are enforced automatically on every request.

On top of that, ZenStack can generate type-safe frontend hooks based on TanStack Query, so your client code can query your backend with the same query API as your server code, with zero manual wiring:

const client = useClientQueries(schema);
const { data: posts } = client.post.useFindMany({ where: { published: true } });

The trade-off is the usual one: more automation means more to understand when something doesn't behave as expected. But for teams building standard CRUD-heavy applications — which is most SaaS products — the reduction in boilerplate is substantial.

The takeaway: Prisma and Drizzle leave API design entirely to you, which is flexible but manual. ZenStack gives you the same escape hatch, but also offers a path where much of that layer is derived automatically from your schema and access policies.

6. Extensibility

No ORM covers every use case out of the box. How easy it is to extend the tool — to add behaviors, generate artifacts, or customize runtime logic — matters more than most developers realize until they hit a wall.

Prisma has a generator-based plugin system that lets you participate in the prisma generate step. Although barely documented, this is useful for things like generating Zod schemas or ERD from your schema. For runtime extensibility, it offers Client Extensions — a mechanism for extending PrismaClient's behavior. It's a meaningful improvement but comes with many limitations that disqualify it as a full-fledged extensibility system.

Drizzle takes a different approach to this problem by not having a plugin system at all. Extensibility in Drizzle is just TypeScript — you compose queries, wrap functions, and build abstractions the same way you would with any library. There's no framework to learn, no hook points to find. This is genuinely freeing for experienced developers, but it also means every team reinvents the same patterns independently.

ZenStack was explicitly designed around extensibility as a core concern. Its plugin system operates at three distinct levels:

Schema level — plugins can contribute new attributes, functions, and types to the ZModel language itself.
Generation level — plugins participate in the zen generate step to produce any artifact from your schema.
Runtime level — plugins can intercept and transform queries and results, enabling behaviors like soft deletes, field encryption, and audit logging to be implemented once and applied transparently across your entire data layer.

The trade-off: ZenStack's extensibility is structured. You work within its model, which has a learning curve. Drizzle's "extensibility" is just TypeScript, which will always feel more natural to developers who distrust frameworks. The right choice depends on whether you'd rather have powerful, opinionated building blocks or full freedom with no guardrails.

7. Performance

Performance is a genuinely complex topic for ORMs — numbers vary significantly depending on the database, query complexity, connection pooling setup, and whether you're measuring cold starts or steady-state throughput. No single benchmark tells the full story, and synthetic tests rarely match real workload distributions.

That said, all three tools publish their own benchmark results, which are worth reviewing in context:

Prisma: benchmarks.prisma.io
Drizzle: orm.drizzle.team/benchmarks
ZenStack: zenstack.dev/docs/orm/benchmark

If you're optimizing for raw throughput at scale, the official numbers are the right place to start — but for most applications, the differences likely won't be the deciding factor.

8. Ecosystem & Maturity

Features and API design matter, but so does the world around a tool — community size, documentation quality, available integrations, and how confident you can be putting it in production.

Ecosystem & maturity comparison — as of early 2026

	Prisma	Drizzle	ZenStack
GitHub stars	~45k	~32k	~3k
Production readiness	GA	GA	GA (v3 is recent)
Documentation	Excellent	Good	Good
GUI tooling	Prisma Studio	Drizzle Studio	ZenStack Studio
Database support	PostgreSQL, MySQL, SQLite, MongoDB, SQL Server, CockroachDB	PostgreSQL, MySQL, SQLite, SQL Server	PostgreSQL, MySQL, SQLite
Serverless / edge	✓ (since v7)	✓	✓
Community size	Large	Growing fast	Smaller but active

A few things worth expanding on:

Prisma is the clear ecosystem leader. Years of adoption means more Stack Overflow answers, more community plugins, more starter kits, and more teammates who already know it. Documentation is among the best in the TypeScript ecosystem. The main concern is strategic: Prisma the company has increasingly shifted focus toward its hosted products (Prisma Postgres, Prisma Accelerate), and ORM innovation has slowed as a result.
Drizzle has grown remarkably fast for a newer tool — evolving from a lightweight alternative into a serious contender, production adoption at scale, and performance numbers that matter for serverless and edge deployments. The community is active and vocal, and documentation has improved significantly.
ZenStack is the youngest of the three by community size, and v3 — while stable — is a relatively recent release. The documentation is solid, and the Discord community is active and responsive. The plugin ecosystem is early but growing quickly; community-built plugins for real-time, caching, and tRPC already exist. Given its schema language and query API are both Prisma-compatible, it offers an easy migration path for Prisma users who desire a more lightweight, extensible, and feature-rich alternative.

One thing worth watching: Prisma has an experimental prisma-next project in development — a full TypeScript rewrite with a proper extension system, suggesting the team is aware of the extensibility gap. The ORM space is moving fast.

Conclusion: How to Choose

No single tool wins across the board. The right choice depends on what your project actually needs. Here's a practical decision framework:

Choose Prisma if:

You want the most mature ecosystem with the largest community
Your team includes developers who aren't SQL-fluent and benefit from a high-abstraction query API
You're already on Prisma and the missing features aren't blocking you — switching has real costs
You want battle-tested tooling and don't care much about bundle size

Choose Drizzle if:

You're comfortable with SQL and want your queries to reflect that
You're deploying to serverless or edge runtimes where bundle size and cold start times matter
You want maximum flexibility with no framework opinions imposed on you
Your team prefers TypeScript-native everything, including schema definition

Choose ZenStack if:

You're building a multi-tenant application, a SaaS product, or anything where access control is a first-class concern
You want to reduce boilerplate across the full stack — from database to API to frontend hooks
You're coming from Prisma and want a low-friction migration path with significantly more capability
Your project would benefit from a schema that serves as a single source of truth for data, security, and API shape

Regarding team size: for solo developers or very small teams, any of the three works fine. As teams grow, ZenStack's declarative access control becomes increasingly valuable — the alternative is trusting every developer (or agent) to remember every where clause on every query, forever.

Greenfield vs. existing projects: if you're starting fresh, all three are equally viable starting points. If you're migrating an existing Prisma codebase, ZenStack offers a genuine migration path from Prisma without requiring a major rewrite.

The TypeScript ORM space in 2026 is healthier than it's ever been — you have real choices with real trade-offs, not just one obvious default. Whichever you pick, the official docs are the best starting point: Prisma, Drizzle, ZenStack.

Your Stack Choice Is Coding Agent's Safety Net

ymc9 — Tue, 10 Mar 2026 17:13:56 +0000

We're in the "vibe coding" era. AI coding agents — Cursor, Claude Code, Copilot, Devin, and their growing kin — are no longer writing toy snippets. They're scaffolding entire features, refactoring modules, and wiring up API endpoints in seconds. The promise is intoxicating: describe what you want, get working code.

The reality is more nuanced. These agents are prolific, but not infallible. They hallucinate API signatures. They skip edge cases. They introduce subtle bugs that compile cleanly and pass a first glance. And crucially, they do all of this fast — far faster than any human code review can keep up with.

So here's the question that matters more than ever: what catches the mistakes an agent makes?

We Need a New Way to Evaluate a Stack

For years, we've chosen tech stacks based on developer experience, ecosystem maturity, performance characteristics, and hiring pool. These criteria still matter. But a new dimension has entered the picture: how well does the stack constrain and verify AI-generated code?

Think about it this way. When a human writes code, they bring context, intuition, and institutional knowledge. They remember the auth check that needs to go on every endpoint. They know the subtle business rule about tenant isolation. An AI agent has none of that ambient awareness — it operates on whatever context it's given, and it fills in the gaps with statistical plausibility.

This means a tech stack is no longer just a productivity tool for humans. It's a safety net for agents. The right stack catches agent mistakes before they reach production. The wrong stack lets them sail through silently.

What Makes a Stack "Agent-Friendly"?

There are three qualities that make a stack effective at catching agent errors:

1. Strong Type System = Compile-Time Guardrails

This is the most obvious one, but it's worth stating clearly. A strong type system acts as a first line of defense against the kinds of errors agents commonly make.

Consider TypeScript vs. plain JavaScript. When an agent adds a new field to a data model, TypeScript propagates that change across the codebase — every function that touches that model lights up with type errors until it's updated. In plain JS, the agent might update the model and the handler it's currently looking at, while a dozen other consumers silently break.

The same principle applies to data access. A typed ORM like Prisma or Drizzle makes it structurally impossible to write queries that reference non-existent fields or use wrong types. Raw SQL strings? The agent can generate whatever it wants, and you won't know it's wrong until runtime — or worse, until a user hits the broken path in production.

The takeaway: types turn runtime surprises into compile-time errors. For human developers, that's nice. For AI agents generating code at speed, it's essential.

2. Declarative Rules Over Imperative Logic

Here's where things get interesting. Consider how most web apps handle authorization. The typical pattern looks like this:

// In route handler A
if (user.role !== 'admin' && resource.ownerId !== user.id) {
  throw new ForbiddenError();
}

// In route handler B (slightly different check)
if (user.role !== 'admin' && resource.tenantId !== user.tenantId) {
  throw new ForbiddenError();
}

// In route handler C (oops, forgot the check entirely)
const data = await db.resource.findMany();

This is imperative authorization — the rules are expressed as code, scattered across dozens of files, with subtle variations that may or may not be intentional. Now imagine asking an AI agent to add a new endpoint. It needs to somehow infer the correct authorization pattern from examples, and apply it correctly. Sometimes it will. Sometimes it won't. And when it doesn't, you have a security vulnerability.

Now contrast this with a declarative approach:

model Resource {
  // ...fields

  @@allow('read', auth().role == 'admin' || tenantId == auth().tenantId)
  @@allow('update', auth().role == 'admin' || ownerId == auth().id)
}

The rules live in one place. They're structural, not behavioral. An agent literally cannot create an endpoint that bypasses them, because the access control is enforced at the data layer, not at the route level. The more business logic lives in declarations, the less room there is for agents to introduce inconsistencies.

3. Single Source of Truth for Data Shape and Rules

AI agents perform best when context is concentrated, not scattered. This is a fundamental property of how large language models work — they reason over a context window, and the more relevant information fits within that window, the better their output.

Schema-first approaches shine here. When your data model, validation rules, and access policies all live in a single schema file, an agent can read that one file and understand the complete picture. Compare this to a codebase where the data models are in a bunch of migration files, validations are in a middleware folder, access rules are in a service layer, and business constraints are buried in utility functions. Even a skilled human developer struggles to hold all of that in their head. For an agent, it's nearly impossible.

The best stack for the AI era is one where the "spec" of your data layer fits in one place.

When the Safety Net Is Missing

To make this concrete, here are failure modes we've seen (or narrowly avoided) with AI-generated code:

The forgotten auth check. An agent writes a new API endpoint for fetching user invoices. It follows the pattern of existing endpoints — proper input validation, clean error handling, nice response formatting. But it doesn't add an authorization check, because the auth logic isn't in the ORM layer or the route middleware — it's manually applied per handler, and the agent didn't infer the pattern from context. Result: any authenticated user can read any other user's invoices.

The inconsistent validation. Your app validates email format in a Zod schema inside the signup handler, but the profile update handler has its own inline regex check, and the admin user-creation endpoint has no email validation at all. An agent is asked to add a new "invite user" endpoint. It writes one — with a slightly different email regex copied from the profile handler. Now you have four endpoints, three different validation rules, and one with none. The inconsistency is invisible at compile time and slips right through tests that only check the happy path.

The wrong tenant scope. An agent is asked to add a data export feature. It copy-pastes a query pattern from another feature, but the original query was for a single-tenant context. The new feature runs in a multi-tenant context, and the agent doesn't apply the tenant filter. Result: data leakage across tenants.

The common thread in all of these: the failures happen when rules are implicit and scattered. No single file told the agent "every query must be tenant-scoped" or "every endpoint must check ownership." The rules existed only as patterns in the codebase, and patterns are exactly what LLMs approximate — imperfectly.

How ZenStack Acts as the Safety Net

ZenStack is a TypeScript toolkit centered around a (Prisma-like) schema language called ZModel. In ZModel, you define your data model, access control rules, and validation constraints in a single file:

model Invoice {
  id        Int      @id @default(autoincrement())
  amount    Float    @gt(0)
  owner     User     @relation(fields: [ownerId], references: [id])
  ownerId   Int
  tenant    Tenant   @relation(fields: [tenantId], references: [id])
  tenantId  Int

  // Access rules: declarative, co-located with the model

  // no anonymous access
  @@deny('all', auth() == null)

  // can create for self in the context of a tenant
  @@allow('create', ownerId == auth().id && tenantId == auth().tenantId)

  // can read if in the same tenant
  @@allow('read', tenantId == auth().tenantId)

  // can update or delete if owner
  @@allow('update,delete', ownerId == auth().id)
}

From this single schema, ZenStack generates a type-safe, access-controlled database client. Here's what that means for AI agents:

Authorization is structural. An agent can't "forget" to add an auth check because the check happens automatically at the data layer. Every query through ZenStack's enhanced client is filtered by the rules in the schema. The agent's job is just to write the query — the safety net handles the rest.
The context is concentrated. An agent can read the ZModel file and understand the complete data model, relationships, access rules, and validation constraints. No hunting across files to piece together the full picture.
Type safety propagates. The generated client is fully typed. If an agent writes a query that references a non-existent field or uses an invalid filter, TypeScript catches it before the code runs.
Less code to generate, less to get wrong. ZenStack and its ecosystem can automatically derive CRUD APIs, TanStack Query hooks, Zod schemas, tRPC routers, OpenAPI specs, and more. Every auto-generated artifact is one less thing an agent needs to hand-write — and one less place for bugs to hide.

Going back to the failure modes above:

Forgotten auth check? Can't happen — ZenStack's enhanced client enforces rules automatically.
Inconsistent validation? Unlikely — validation rules live in the schema alongside the model, so every endpoint shares the same constraints automatically.
Wrong tenant scope? The tenantId == auth().tenantId rule in the schema ensures every query is scoped correctly, regardless of which endpoint makes the query.

Shrink the Blast Radius

The broader principle here isn't specific to ZenStack. It's this: the best stacks for the AI era minimize what can go wrong when code is generated at speed.

Think of type systems as guardrails on a highway. They don't slow you down — you can still drive at full speed. But they keep you from flying off a cliff when you drift. Declarative schemas, enforced access control, and auto-generated boilerplate are the same kind of guardrails, applied to the data and security layer — which is exactly where mistakes hurt the most.

The stacks that will thrive in the agent era share a common philosophy: make the right thing automatic, and the wrong thing impossible. The more of your application's correctness invariants that are expressed as declarations rather than scattered imperative code, the safer you are — whether the code is written by a human, an agent, or some combination of both.

Choose Stacks That Protect You From Speed

AI agents are only getting faster and more autonomous. The question is no longer whether to use them — it's whether your stack can keep up safely. A good stack isn't just pleasant to work with. It absorbs the speed and imprecision of AI-generated code. It turns out that what's good for human developers is even better for AI agents: clear, concentrated, enforceable rules.

If you're evaluating your stack for the agent era, ask yourself: when an AI writes code against my data layer, what stops it from making a catastrophic mistake? If the answer is "code review" or "hoping the tests catch it," it might be time to add a stronger safety net.

Get started with ZenStack and see what a schema-first, safety-net-first stack looks like in practice.

ZenStack V3: The Perfect Prisma ORM Alternative

ymc9 — Sat, 29 Nov 2025 08:09:38 +0000

Prisma won the hearts of many TypeScript developers with its excellent developer experience - the elegant schema language, the intuitive query API, and the unmatched type-safety. However, as time went by, its focus shifted, and innovation in the ORM space slowed down considerably. Many successful OSS projects indeed struggle to meet the ever-growing demands, but you'll be surprised to find that many seemingly fundamental features that have been requested for years are still missing today, such as:

As a new challenger in this space, ZenStack aspires to be the spiritual successor to Prisma, but with a light-weighted architecture, a richer feature set, well-thought-out extensibility, and an easy-to-contribute codebase. Furthermore, its being essentially compatible with Prisma means you can have a smooth transition from existing projects.

A bit of history

ZenStack began its journey as a power pack for Prisma ORM in late 2022. It extended Prisma's schema language with additional attributes and functions, and enhanced PrismaClient at runtime with extra features. The most notable enhancement is the introduction of access policies, which allow you to declaratively define fine-grained access rules in the schema had have them transparently enforced at runtime.

As we went deeper along the path with v1 and v2, we felt increasingly constrained by Prisma's intrinsic limitations. We decided to make a bold change in v3: build our own ORM engine (on top of the awesome Kysely) and migrate away from Prisma. To ensure an easy migration path, we've made several essential compatibility commitments:

The schema language remains compatible with (and in fact a superset of) Prisma Schema Language (PSL).
The resulting database schema remains unchanged, so no data migration is needed.
The query API stays compatible with PrismaClient.
Existing migration records continue to work without changes.

Dual API from a single schema

PrismaClient's API is pleasant to use, but when you go beyond simple queries, you'll have to resort to raw SQL queries. Prisma introduced the TypedSQL feature to mitigate this problem. Unfortunately, it only solved half of the problem (having the query results typed), but you still have to write SQL, which is quite a drop in developer experience.

ZenStack v3, thanks to the power of Kysely, offers a dual API design. You can continue to use the elegant high-level ORM queries like:

const users = await db.user.findMany({
  where: { age: { gt: 18 } },
  include: { posts: true },
});

Or, when your needs outgrow its power, you can seamlessly switch to Kysely's type-safe, fluent query builder API:

const users = await db
  .$qb
  .selectFrom('User')
  .where('age', '>', 18)
  .leftJoin('Post', 'Post.authorId', 'User.id')
  .select(['User.*', 'Post.title'])
  .execute();

For most applications, you'll never need to write a single line of SQL anymore.

Battery included

ZenStack aims to be a battery-included ORM and solve many common data modeling/query problems in a coherent package. Here are just a few examples of how far it's come in achieving this goal.

Built-in access control

Every serious application needs non-trivial authorization. Wouldn't it be great if you could consolidate all access rules in the data model and never need to worry about them at query time? Here you go:

Schema:

model Post {
  id        Int     @id
  title     String
  published Boolean
  author    User    @relation(fields: [authorId], references: [id])
  authorId  Int

  @@deny('all', auth() == null)    // deny anonymous access
  @@allow('all', auth() == author) // owner has full access
  @@allow('read', published)       // published posts are publicly readable
}

Query:

async function handleRequest(req: Request) {
  // get the validated current user from your auth system
  const user = await getCurrentUser(req);

  // create a user-bound ORM client
  const userDb = db.$setAuth(user);

  // query with access policies automatically enforced
  const posts = await userDb.post.findMany();
}

Strongly typed JSON

JSON columns are becoming increasingly popular in relational databases. Getting them typed is straightforward.

Schema:

model User {
  id      Int     @id
  profile Profile @json
}

type Profile {
  age Int
  bio String
}

Query:

const user = await db.user.findFirstOrThrow();
console.log(user.profile.age); // strongly typed

Polymorphic models

Ever felt the need to model an inheritance hierarchy in the database? Polymorphic models come to the rescue.

Schema:

model Content {
  id        Int    @id
  title     String
  type      String

  // marks this model to be a polymorphic base with its
  // concrete type designated by the "type" field
  @@delegate(type)
}

model Post extends Content {
  content String
}

model Image extends Content {
  data Bytes
}

Query:

// a query with base automatically includes sub-model fields
const content = await db.content.findFirstOrThrow();

// the returned type is a discriminated union
if (content.type === 'Post') {
  // typed narrowed to `Post`
  console.log(content.content);
} else if (content.type === 'Image') {
  // typed narrowed to `Image`
  console.log(content.data);
}

These are just some of the existing features. More cool stuff like soft deletes, audit trails, etc., will be added in the future.

Extensible from the ground up

ZenStack ORM comprises three main pillars - the schema language, the CLI, and the ORM runtime. All three are designed with extensibility in mind.

The schema language allows you to add custom attributes and functions to extend its semantics freely. E.g., you can add an @encrypted attribute to mark fields that need encryption.
```
attribute @encrypted()

model User {
    id       Int    @id
    email    String @unique @encrypted
}
```
The ORM runtime allows you to add plugins that can intercept queries at different levels and modify their payload or entire behavior. For the example above, you can create a plugin that recognizes the @encrypted attribute and transparently encrypts/decrypts field values during writes/reads.
```
const dbWithEncryption = db.$use(
  new EncryptionPlugin({
    algorithm: 'AES-256-CBC',
    key: process.env.ENCRYPTION_KEY,
  })
);
```
The CLI allows you to add generators that emit custom artifacts based on the schema. Think of generating an ERD diagram, or a GraphQL schema.
```
plugin erd {
  provider = './plugins/erd-generator'
  output = "./erd-diagram.md"
}
```

In fact, the access control feature mentioned earlier is entirely implemented with these extension points as a plugin package. The potential is limitless.

Simpler, smaller footprint

ZenStack is a monorepo, 100% TypeScript project - no native binaries, no WASM modules. It keeps things lean and reduces deployment footprint. As a quick comparison, for a minimal project that uses Postgres database, the "node_modules" size difference (with npm install --omit=dev) is quite significant:

ORM	"node_modules" Size
Prisma 7	224 MB
ZenStack V3	33 MB

A simpler code base also makes it easier for the community to navigate and contribute.

Beyond ORM

A feature-rich ORM can enable some very interesting new use cases. For example, since the ORM is equipped with access control, it can be directly mapped to a service that offers a full-fledged data query API without writing any code. You effectively get a self-hosted Backend-as-a-Service, but without any vendor lock-in. Check out the Query-as-a-Service documentation if you're interested.

Furthermore, frontend query hooks (based on TanStack Query) can be automatically derived, and they work seamlessly with the backend service.

All summed up, the project's goal is to be the data layer of modern full-stack applications. Kill boilerplate code, eliminate redundancy, and let your data model drive as many aspects as possible.

Conclusion

ZenStack v3 is currently in Beta, and a production-ready version will land soon. If you're interested in trying out migrating an existing Prisma project, you can find a more thorough guide here. Make sure to join us in Discord, and we'd love to hear your feedback!

Turning Your Database Into an MCP Server With Auth

JS — Tue, 10 Jun 2025 05:39:37 +0000

MCP is trending in AI, But…

MCP(Model Context Protocol) is undoubtedly one of the most exciting trends in AI now. Not only is everyone talking about it, but everyone is also rushing to develop their version to secure a seat at the table of the AI era. Don't feel so? Guess how many MCP servers are listed in MCP Server Directory ?

The number is 4,684 now, and remember, MCP is just a six-month-old baby. However, have you noticed the one and only filter on the left:

Guess how many remain after applying this filter? Only 59—approximately 1% of the total. For those unfamiliar with this filter, I'll provide a brief explanation that you can skip if you already understand it.

MCP was initially conceived primarily as a protocol for local execution, where AI models could interact with local tools and data sources running on the same machine, like the example MCP FileSystem and Fetch listed in the official doc. It means you must install and run the MCP server on your local machine, regardless of whether the underlying transport is stdio or HTTP SSE. This design choice made sense in the early days, as it simplified security concerns and reduced latency. The protocol's simplicity made it perfect for developers to experiment with AI tool integration on their personal machines. However, as MCP gained traction and the AI ecosystem evolved, the need for secure remote execution became increasingly apparent:

// Detect dark theme var iframe = document.getElementById('tweet-1907218594624372868-613'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1907218594624372868&theme=dark" }
With a remote MCP server, organizations expose their data and services to AI models over the internet, so the most important thing is Auth (authentication and authorization). Initially, this was addressed by asking users to generate an API key within the product and then configure it in the MCP settings. Here is an example from the Neon MCP server:

{
  "mcpServers": {
    "neon": {
      "command": "npx",
      "args": [
        "-y",
        "@neondatabase/mcp-server-neon",
        "start",
        "<YOUR_NEON_API_KEY>"
      ]
    }
  }
}

Developers are all familiar with this process. But as more and more SaaS products are providing the MCP server due to fear of death(search ‘SaaS is dead’ if you don't get it 😁), that's definitely not a good user experience for the non-developers. Moreover, users need to manually update the NPM package from time to time to stay current.

Kent raises the same concern in his tweet:

All the examples I see so far have the user generate a token and then put that token in the MCP configuration. Is that the best we have right now? I was hoping to find an example of an MCP client that supported an OAuth flow with a hosted MCP server.

The Advent of Authorization for MCP

The MCP is young but is growing very fast. The OAuth support was introduced in March 2025, around the time he was 3 months old. Here are the Authorization flow steps in the official specification:

The specification comes with SDK support for both client and server, enabling more MCP servers to adopt and leverage it. Even some existing servers that rely on API keys are beginning to embrace the new modern solution. For example, the Neon MCP server mentioned above adds support for it, too.

{
  "mcpServers": {
    "Neon": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.neon.tech/sse"]
    }
  }
}

💡 The mcp-remote is for clients that don’t support OAuth. It's unnecessary for clients like Cursor that have supported it.

After adding the above MCP configuration, the MCP client will automatically open the browser to go through the standard OAuth process without needing the API key anymore:

With this modern MCP server, you can stop worrying about the PM or CEO showing up at your desk asking for help connecting to the MCP server of some SaaS product your company uses. Trust me, it happens. 😂

MCP Is a Good Enhancement for SaaS

With the seamless experience of OAuth support, many companies are eager to provide an MCP server to enhance their existing product or service, especially within the SaaS landscape. Balancing flexibility and simplicity is always a core challenge for SaaS - too many buttons overwhelm users, too few constrain power users. For instance, I always love the clean and efficient UX/UI design of Trello:

However, it pricks me every time for certain routine jobs.

How many cards were done last week?
Who has the most incomplete cards?
Which list has the most incomplete cards?

Trello doesn’t provide a direct way to show the answer; you have to do the math manually. This is where the MCP-LLM duo could provide a great solution to let user use natural language to get their job done. I think that’s the actual point that Microsoft CEO Satya Nadella was trying to convey in his presumed “SaaS is dead” interview.

Two Approaches to Building an MCP Server

1. Relying on the Existing API

This seems like the obvious choice. However, since those APIs were most likely designed a long time before the LLM was born, they might not be suitable for the LLM to consume. One thing is that the semantics of the parameters and return data might not be self-explanatory enough for the LLM to understand; The other thing is that the API might not be flexible enough to provide the functionality to support what the user wants to achieve.

2. Start from Scratch

For those considering this approach, the biggest concern is probably time. Don’t worry, we never really build from scratch, do we? The MCP is evolving fast, and so is the whole ecosystem. Let me show you the modern stack that could dramatically reduce the code you need to write to speed it up.

MCP TypeScript SDK

It fully implements the MCP specification, including Authorization. It provides a strong abstraction, freeing you from wrestling with low-level protocol implementation so you can focus on the business logic.

ZenStack

ZenStack is a schema-first TypeScript toolkit on top of Prisma ORM. The core part is a ZModel DSL that unifies data modeling and access control. Here is an example of what a simple blog post looks like:

model User {
  id            Int                 @id @default(autoincrement())
  email         String              @unique
  name          String?
  password      String              @password @omit
  posts         Post[]

  @@allow('read', true)
}

model Post {
  id        Int      @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  title     String
  content   String?
  published Boolean  @default(false)
  viewCount Int      @default(0)
  author    User?    @relation(fields: [authorId], references: [id])
  authorId  Int?     @default(auth().id)

  @@allow('all', auth() == author)
  // logged-in users can view published posts
  @@allow('read', auth() != null && published)
}

Based on the ZModel schema, ZenStack automatically creates well-structured, type-safe, and authorized CRUD APIs for your database. MCP's core value lies in its tools, which fundamentally consist of schema definitions and executable operations—specifically, the CRUD operations on your database for most SaaS applications. ZenStack can generate both directly from its schema, which can be safely called by LLM thanks to the access control policy. Thus, your primary task is to define the schema, and ZenStack manages everything else.

Building an MCP Server from Scratch

So let me walk you through the process of turning your database into an MCP server with OAuth-based authentication and authorization from scratch. I will use the blog post mentioned above as a sample; you can adapt it for your app, and all you need to do is change the ZModel schema accordingly.

You can find the completed project below:

https://github.com/jiashengguo/zenstack-mcp-auth

Initialize the Project

Use the below script to initialize a project with Prisma and Express:

npx try-prisma@latest -t orm/express -n blog-app-mcp

Install the MCP SDK, bcrypt(used to hash password):

npm install @modelcontextprotocol/sdk, bcrypt, @types/bcrypt

Initialize ZenStack:

npx zenstack@latest init

Auth

To support the OAuth, the server needs to store the following information:

OAuth Client
Authorization Code
Access Token
Refresh Token

So let’s add them in the ZModel schema file so that we can use the generated type-safe API to operate on them:

model OAuthClient {
  id                       Int      @id @default(autoincrement())
  client_id                String   @unique
  client_secret            String?
  ...
}

model AuthorizationCode {
  id            Int      @id @default(autoincrement())
  code          String   @unique
  ...
}

model AccessToken {
  id        Int      @id @default(autoincrement())
  token     String   @unique
  ...
}

model RefreshToken {
  id        Int      @id @default(autoincrement())
  token     String   @unique
  ...
}

According to the MCP specification, here are the three endpoints that the server must implement:

Endpoint	Url	Usage
Authorization	/authorize	Used for authorization requests
Token	/token	Used for token exchange & refresh
Registration	/register	Used for dynamic client registration

MCP SDK provides a utility function, mcpAuthRouter, to install these standard authorization server endpoints. What we need to do is implement an OAuthServerProvider to pass it to the mcpAuthRouter.

Let’s create an AuthMiddleware class to handle all the Auth logic, and a PasswordAuthProvider implementing the OAuthServerProvider to do the actual logic.

export class AuthMiddleware {
   private authProvider: PasswordAuthProvider;
   private authRouter: express.Router = express.Router();
   ...
    private setupRouter() {
        // Add OAuth router using the mcpAuthRouter function
        this.authRouter.use(
            '/',
            mcpAuthRouter({
                provider: this.authProvider,
                issuerUrl: new URL(config.baseUrl),
                baseUrl: new URL(config.baseUrl),
                scopesSupported: ['read', 'write'],
            })
        );
        ...
    }
}

PasswordAuthProvider

Here are the three functions that will actually be called, corresponding to the three necessary endpoints mentioned above:

export interface OAuthServerProvider {
    // /register
    get clientsStore(): OAuthRegisteredClientsStore;

    // /authorize
    authorize(client: OAuthClientInformationFull, params: AuthorizationParams, res: Response): Promise<void>; 

    // /token
    exchangeAuthorizationCode(client: OAuthClientInformationFull, authorizationCode: string, codeVerifier?: string, redirectUri?: string): Promise<OAuthTokens>;
}

The clientStore deals with register and read through registerClient and getClient functions, it simply writes and reads the OAuthClient model from the database.

The actual authorization flow begins with authorize. Its job is to redirect to the actual authorization server with all the necessary parameters. Since in our case, the authorization server is itself, let’s redirect to the/auth/login path:

      const loginUrl = new URL('/auth/login', config.baseUrl);
      ...
      res.redirect(loginUrl.toString());

Therefore, we need to create a login.html to serve it. It’s a typical login form like below:

After clicking Login, it combines all the URL parameters passed from the authorization flow along with the email and passwords to post to the server endpoint /auth/login.

The server endpoint /auth/login would eventually call into the function handlelogin of PasswordAuthProvider. It verifies the user identity. If it is correct, then create an auth code, return to the client, and store it in an AuthorizationCode instance in the database

  // Generate authorization code
  const authCode = crypto.randomBytes(32).toString('hex');

  // Store authorization code in database
  await this.prisma.authorizationCode.create({
      data: {
          code: authCode,
          clientId,
          userId: user.id,
          codeChallenge,
          redirectUri,
          expiresAt: new Date(Date.now() + 600000), // 10 minutes
          scopes,
      },
  });

After getting the auth code returned from the server, login.html will redirect to the MCP client with the auth code. Finally, the MCP client will use the auth code to call the /token endpoint to exchange for the access token, which will call into the exchangeAuthorizationCode function.

In exchangeAuthorizationCode, the server will first verify that the auth code it just granted is valid, and the client’s identification, such as PKCE. If everything is correct, it will generate both access token and refresh token, store them in the database, and return to the MCP client.

// Store tokens in database
await this.prisma.accessToken.create({
    data: {
        token: accessToken,
        clientId: client.client_id,
        userId: authData.userId,
        scopes: authData.scopes as any,
        expiresAt,
    },
});

await this.prisma.refreshToken.create({
    data: {
        token: refreshToken,
        clientId: client.client_id,
        userId: authData.userId,
        scopes: authData.scopes as any,
        expiresAt: new Date(Date.now() + 86400 * 30 * 1000), // 30 days
    },
});

// Clean up authorization code
await this.prisma.authorizationCode.delete({
    where: { code: authorizationCode },
});

return {
    access_token: accessToken,
    token_type: 'Bearer',
    expires_in: expiresIn,
    refresh_token: refreshToken,
    scope: (authData.scopes as string[]).join(' '),
};

Stateful Multi-connections Streamable HTTP Server

After the MCP client gets the access token, each time it communicates with the server through the main endpoint, it will put the access token in the Authorization header. The server should use it to verify the client and get the client’s identity. Let’s choose the conventional /mcp endpoint as the main endpoint and getFlexibleAuthMiddleware to do so.

The first request sent by the MCP client to the server is an initialize request. The server should respond with server information and a generated session ID, which the client would always include to maintain the session. As a production-ready MCP server, it definitely should support multiple simultaneous connections. Therefore, we use a map to store each client by its session ID.

const transports: { [sessionId: string]: StreamableHTTPServerTransport } = {};

To manage the session for each user, we will create a dedicated MCPServer for it. Since it’s per user per MCP server, we could store the userId in it, which will be used for Authorization when executing tools.

if (sessionId && transports[sessionId]) {
    transport = transports[sessionId];
  } 
else if (!sessionId && isInitializeRequest(req.body)) {
    // Handle new MCP connection initialization
    transport = new StreamableHTTPServerTransport({
        sessionIdGenerator: () => crypto.randomUUID(),
        onsessioninitialized: (sessionId: string) => {
            console.log(`New MCP session initialized: ${sessionId}, User ID: ${userId}`);
            transports[sessionId] = transport!;
        },
    });

    const mcpServer = createMCPServer(userId);
    await mcpServer.connect(transport);
    console.log(`MCP server connected for User ID: ${userId}`);
    // Handle connection close
    transport.onclose = () => {
        if (transport?.sessionId) {
            console.log(`MCP session closed: ${transport.sessionId}`);
            delete transports[transport.sessionId];
        }
    };
}
else {
  // invalid request
  ...
}
// Handle the request
await transport.handleRequest(req, res, req.body);

Tool

We will fully rely on the ZenStack to do the job. Remember the two parts of the Tool: schema and execution.

Schema

ZenStack has a native Zod plugin to generate the Zod schema for its CRUD API. We can enable it by adding the one below to the schema.zmodel :

plugin zod {
    provider = '@core/zod'
}

Then, after running zenstack generate, it generates the Zod schema for all the operations it supports for every model in @zenstackhq/runtime/zod/input. For example, this is the one for Post :

import { z } from 'zod';
import type { Prisma } from '.zenstack/models';
declare type PostInputSchemaType = {
    findUnique: z.ZodType<Prisma.PostFindUniqueArgs>;
    findFirst: z.ZodType<Prisma.PostFindFirstArgs>;
    findMany: z.ZodType<Prisma.PostFindManyArgs>;
    create: z.ZodType<Prisma.PostCreateArgs>;
    createMany: z.ZodType<Prisma.PostCreateManyArgs>;
    delete: z.ZodType<Prisma.PostDeleteArgs>;
    deleteMany: z.ZodType<Prisma.PostDeleteManyArgs>;
    update: z.ZodType<Prisma.PostUpdateArgs>;
    updateMany: z.ZodType<Prisma.PostUpdateManyArgs>;
    upsert: z.ZodType<Prisma.PostUpsertArgs>;
    aggregate: z.ZodType<Prisma.PostAggregateArgs>;
    groupBy: z.ZodType<Prisma.PostGroupByArgs>;
    count: z.ZodType<Prisma.PostCountArgs>;
};

So each operation for each model will become a Tool of our MCP server.

Execution

The execution of each function is very straightforward; just dynamically invoke the function with the argument generated by the LLM. Therefore, the whole Tool creating logic is simply one lambda expression in less than 30 lines of code:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import crudInputSchema from '@zenstackhq/runtime/zod/input';
...
export function createMCPServer(userId: number) {
    const server = new McpServer(
        ...
    )
    Object.entries(crudInputSchema)
        .filter(([name]) => modelNames.includes(getModelName(name)))
        .forEach(([name, functions]) => {
            const modelName = getModelName(name);

            Object.entries(functions as Record<string, any>)
                .filter(([functionName]) => functionNames.includes(functionName))
                .forEach(([functionName, schema]) => {
                    const toolName = `${modelName}_${functionName}`;
                    server.tool(
                        toolName,
                        `Prisma client API '${functionName}' function input argument for model '${modelName}'. ${currentUserPrompt}`,
                        {
                            args: schema,
                        },
                        async ({ args }) => {
                            console.log(`Calling tool: ${toolName} with args:`, JSON.stringify(args, null, 2));
                            const prisma = getPrisma(userId);
                            const data = await (prisma as any)[modelName]<a href="args">functionName</a>;
                            console.log(`Tool ${toolName} returned:`, JSON.stringify(data, null, 2));
                            return {
                                content: [{ type: 'text', text: JSON.stringify(data, null, 2) }],
                            };
                        }
                    );
                });
        });

    return server;
}

One thing that needs to be mentioned is that the Prisma client that is used to call that operation is the ZenStack-enhanced one that contains the current user identity, which is the userId stored in the MCPServer during initialization. This will completely eliminate unauthorized data access, no matter what parameters LLM generates for the function, even if hallucination happens:

import { enhance } from '@zenstackhq/runtime';
// Gets a Prisma client bound to the current user identity
export function getPrisma(userId: number | null) {
    const user = userId ? { id: userId } : undefined;
    return enhance(prisma, { user });
}

There is another benefit that since these Tools are actually the standard Prisma Client API, it works well for the LLM:

First, its declarative and well-structured nature makes it easy to understand and reason about, allowing LLMs to generate accurate and predictable queries with minimal ambiguity
Second, the API's flexibility allows one single call to access multiple models (database tables), enabling LLMs to efficiently navigate complex data relationships and perform sophisticated queries across different entities without requiring separate API calls or complex orchestration logic.
Third, Prisma has been widely adopted for years, providing a rich ecosystem of documentation, examples, and community usage that LLMs can learn from, greatly increasing the chance of generating correct and context-aware code.

Test

The sample project includes seed data for you to play around with. Simply run the below command to make it ready:

npx prisma db push
npx prisma db seed

It creates three users with posts. The passwords for all users are password123.

Enjoy playing it with whatever MCP client of your choice:

I’m really eager to hear about the results you achieved with your application! If you’re looking for any tips on writing the ZModel schema, please feel free to reach out to me or hop onto our Discord. I’m always willing to help!

How to Build AI Agents to Enhance SaaS With Minimal Code and Effort

JS — Tue, 20 May 2025 05:59:45 +0000

Is SaaS Really Dead?

Several months ago, the internet was abuzz with the Microsoft CEO Satya Nadella saying, “SaaS is dead.”

The conversation started with a question from Bill Gurley about whether Satya was worried that newer startups are building applications with an AI-first approach, which could obfuscate traditional infrastructure like Excel or CRM. Here is Satya’s response:

I think the notion that business applications exist, that's probably where they'll all collapse, right in the agent era, because if you think about it, right, they are essentially CRUD databases with a bunch of business logic. The business logic is all going to these agents, and these agents are going to be multi-repo CRUD

Some people might assume he suggested that AI agents could or would replace SaaS. However, if you watch the entire podcast, you'll understand that he's actually discussing how AI agents will transform SaaS rather than replace it:

How? Let me share an example from my experience. At my previous company, we used Trello for project management. I was impressed by its clean and efficient UX design.

However, one drawback that consistently bothered me was the lack of flexibility in performing queries. For instance:

How many cards were done last week?
Who has the most incomplete cards?
Which list has the most incomplete cards?

Trello doesn't provide a direct way to show the answer; you'll need to do the math manually. I understand that offering such flexibility from a UI design perspective is challenging, yet each encounter often brings a sigh of frustration. 😮‍💨

Balancing flexibility and simplicity is a core challenge for SaaS. This is where an AI agent can play a role. The most straightforward solution is to introduce a chatbot that can easily provide answers to all the questions mentioned, without altering any existing features.

Challenge of Building an AI Chatbot

We are all aware of the hallucinations that AI causes. But there is another level of hallucination:

AI makes many things seem easily accomplished on the surface, but you will see the challenge under the iceberg when it comes to production.

My previous company tried to integrate a chat agent into their SaaS product, and was struggling with those challenges:

LLM Failed to Generate the Correct API Call

The initial plan was to have the LLM generate an API call directly based on user input. However, probably because the existing API is not well designed, LLM often struggles to interpret and generate the correct parameters. Sometimes, it even calls the wrong API.
The Complexity of Transforming the LLM Result

Since the initial plan fails, they ask LLM to create the intermediate structured query object, then use code to convert this object into an actual database query. The good thing is that it is the code that makes the final call; the bad thing is that the code can become highly complex as it needs to account for all possible cases the LLM might produce.

One critical issue that needs to be addressed is Authorization. You have to scrutinize and ensure the generated query doesn’t break the authorization rule of the current system, which can sometimes be quite complex. Any oversight could lead to significant security breaches, potentially disastrous for a B2B SaaS.

The fundamental issue seems to be that the current infrastructure is not friendly enough for AI agents, as Bill questioned Satya. So, what type of infrastructure would be suitable for AI?

Schema-First Fit AI-First

Among all the discussions regarding Satya’s statement:

They are essentially CRUD databases with a bunch of business logic. The business logic is all going to these agents.

Many people focus solely on the business logic that will be handled by the agent, often neglecting the essential prerequisite: the CRUD database. In other words, AI must accurately and precisely translate the business logic to the CRUD operation to ensure success. This is where the challenges arise, as illustrated in the previous example. It seems there is a missing layer that focuses on 'what' rather than 'how' to make AI better work: a schema. AI excels at declarative schemas over imperative code. Therefore, if we could make the CRUD database a well-designed schema for AI to manipulate, that could provide a robust foundation for the mission to be done.

The ZenStack schema-first toolkit is well-suited for the task. The core part is a DSL that unifies data modeling and access control, two essential parts of CRUD databases. Here is an example of what a simple blog post looks like:

enum Role {
    USER
    ADMIN
}

model Post {
    id        String  @id @default(cuid())
    title     String
    published Boolean @default(false)
    author    User    @relation(fields: [authorId], references: [id])
    authorId  String  @default(auth().id)

    @@allow('all', auth() == author)
    @@allow('read', auth() != null && published )
    @@allow('read', auth().role == 'ADMIN')
}

model User {
    id       String  @id @default(cuid())
    email    String? @unique
    password String  @password @omit
    role     Role    @default(USER)
    posts    Post[]

    @@allow('create,read', true)
    @@allow('update,delete', auth() == this)
}

Based on the schema, ZenStack automatically generates well-structured, type-safe, and authorized CRUD APIs to the database. Not only can AI understand and manipulate it better with less chance of hallucination, but also developers will be able to build the AI agent on top of it easily.

I know talk is cheap, so let me show you the code!

Building an AI Chatbot from Scratch

Let’s build an AI chatbot for a Todo app to address the pain points of Trello earlier. To keep this concise, I'll focus on the key steps. You can find the link to the completed project on GitHub at the end of the post. Here is the final outcome:

Here is the tech stack we are using:

Next.js - React framework
ZenStack - Full-stack toolkit with access control
NextAuth - Authentication for Next.js
AI SDK - AI integration for chat features

1. Creating the project

Create a Next.js project with create-t3-app with Prisma, NextAuth, and TailwindCSS:

npx create-t3-app@latest --prisma --nextAuth --tailwind --appRouter --CI todo-ai

2. Initialize the project for ZenStack

Run the zenstack CLI to prepare your project for using ZenStack.

npx zenstack@latest init

Replace the schema.zmodel with the below content:

generator client {
    provider = "prisma-client-js"
}

datasource db {
    provider = "sqlite"
    url      = env("DATABASE_URL")
}

plugin zod {
    provider = '@core/zod'
}

/*
 * Model for a Todo list
 */
model List {
    id        String   @id @default(uuid())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt
    owner     User     @relation(fields: [ownerId], references: [id], onDelete: Cascade)
    ownerId   String   @default(auth().id)
    title     String   @length(1, 100)
    private   Boolean  @default(false)
    todos     Todo[]
    // can be read by owner or space members (only if not private) 
    @@allow('read', !private)

    // owner can do anything
    @@allow('all', owner == auth())
}

/*
 * Model for a single Todo
 */
model Todo {
    id          String    @id @default(uuid())
    createdAt   DateTime  @default(now())
    updatedAt   DateTime  @updatedAt
    owner       User      @relation(fields: [ownerId], references: [id], onDelete: Cascade)
    ownerId     String    @default(auth().id)
    list        List      @relation(fields: [listId], references: [id], onDelete: Cascade)
    listId      String
    title       String    @length(1, 100)
    completedAt DateTime?

    // full access if the parent list is readable
    @@allow('all', check(list, 'read'))
}

model User {
    id       String  @id @default(cuid())
    name     String?
    email    String? @unique
    password String  @password @omit
    todo     Todo[]
    list     List[]

    // everyone can signup, and user profile is also publicly readable
    @@allow('create,read', true)
    // only the user can update or delete their own profile
    @@allow('update,delete', auth() == this)
}

This represents a multi-user Todo app. Todo list can be private or public; list owners have full control over their list. If a user can see the list, they can manipulate all the todos under that list.

3. Implement Signup/Signin

The tasks here are configuring NextAuth to use credential-based auth and creating the signup/signin form. Check out the code for details.

4. Implement the chatbot logic with Vercel AI SDK and ZenStack

We will primarily utilize the AI SDK to develop the chatbot. It not only standardizes integration across various LLM providers but also offers a range of hooks for creating chat and generative user interfaces. With that, building a chatbot with real-time message streaming requires just a few lines of code. Here is the official doc.

Simply put, it provides a userChat hook for the client and a corresponding server endpoint in src/app/chat/route.ts. I will skip the UI part and focus on implementing the endpoint, which is essentially the complete functionality of this bot.

Every AI agent typically consists of two components: Tools and Prompts. As previously discussed, Tools in this context refer to the CRUD APIs of the database. So let’s see how it is getting implemented.

The AI SDK allows Zod Schema to be used to define the parameters of the Tool. So, have you noticed a Zod plugin defined in the schema.zmodel ?

plugin zod {
    provider = '@core/zod'
}

This is a ZenStack native plugin that generates Zod schemas for models and input arguments of Prisma CRUD operations. For instance, it will generate the CRUD schema for every model as below:

declare type TodoInputSchemaType = {
    findUnique: z.ZodType<Prisma.TodoFindUniqueArgs>;
    findFirst: z.ZodType<Prisma.TodoFindFirstArgs>;
    findMany: z.ZodType<Prisma.TodoFindManyArgs>;
    create: z.ZodType<Prisma.TodoCreateArgs>;
    createMany: z.ZodType<Prisma.TodoCreateManyArgs>;
    delete: z.ZodType<Prisma.TodoDeleteArgs>;
    deleteMany: z.ZodType<Prisma.TodoDeleteManyArgs>;
    update: z.ZodType<Prisma.TodoUpdateArgs>;
    updateMany: z.ZodType<Prisma.TodoUpdateManyArgs>;
    upsert: z.ZodType<Prisma.TodoUpsertArgs>;
    aggregate: z.ZodType<Prisma.TodoAggregateArgs>;
    groupBy: z.ZodType<Prisma.TodoGroupByArgs>;
    count: z.ZodType<Prisma.TodoCountArgs>;
};

Therefore, all we need to do is convert each CRUD operation to an AI SDK tool. Let’s create a createToolsFromZodSchema function iterates all the models:

import prismaInputSchema from "@zenstackhq/runtime/zod/input";
import { type Tool, tool, zodSchema } from "ai";

async function createToolsFromZodSchema(prisma: PrismaClient) {
  const tools: Record<string, Tool> = {};
  const functionNames = ["findMany", "createMany", "deleteMany", "updateMany"];
  for (const [inputTypeName, functions] of Object.entries(prismaInputSchema)) {
    // remove the postfix InputSchema from the model name
    const modelName = inputTypeName.replace("InputSchema", "");
    for (const [functionName, functionSchema] of Object.entries(
      functions,
    ).filter((x) => functionNames.includes(x[0]))) {
      const functionParameterType = zodSchema(
        functionSchema as z.ZodObject<z.ZodRawShape>,
        {
          useReferences: true,
        },
      );
      tools[`${modelName}_${functionName}`] = tool({
        description: `Prisma client API '${functionName}' function input argument for model '${modelName}'`,
        parameters: functionParameterType,
        execute: async (input: unknown) => {
          console.log(
            `Executing ${modelName}.${functionName} with input:`,
            JSON.stringify(input),
          );
          // eslint-disable-next-line
          return (prisma as any)[modelName][functionName](input);
        },
      });
    }
  }

To minimize the tool count and alleviate the AI's workload, we offer only four fundamental operations: "findMany," "createMany," "deleteMany," and "updateMany.”

The execute function inside is quite simple, just invoke the corresponding prisma client API function using the passed in PrismaClient object. Here comes the most crucial part, which is also the most exciting part of ZenStack:

The PriamClient object should be the enhanced Prisma client that contains the current user identity instead of the regular Prisma client:

  const authObj = await auth();
  const enhancedPrisma = enhance(db, { user: authObj?.user });
  const tools = await createToolsFromZodSchema(enhancedPrisma);

The greatest advantage is that no matter what parameters AI generates for a function, you never have to worry about unauthorized access. This is because the access policy defined in the schema will always be injected under the hood before reaching the database.

The system prompt is straightforward and general. You can review the code and tailor it to suit your specific requirements:

  const systemPrompt = `...`;

  const result = streamText({
    model: openai("gpt-4.1"),
    system: systemPrompt,
    messages: messages,
    maxSteps: 3,
    tools: tools,
  });

Thanks to the AI SDK and ZenStack, the entire server implementation of this chatbot was completed in less than 100 lines of code! Even more impressive, this implementation is completely app-agnostic. In other words, regardless of your app (zmodel), it works seamlessly.

So if you're a ZenStack user, you now know the best practice for implementing an AI Chatbot. 😉

Try It for Your Own Application

Here is the final project that you can run directly:

https://github.com/jiashengguo/zenstack-ai-chatbot
You can easily test this AI chat agent for your own application — all you need to do is customize schema.zmodel to fit your application.

I would love to hear your feedback on it!

Code as Doc: Automate by Vercel AI SDK and ZenStack for Free

JS — Mon, 23 Dec 2024 06:04:53 +0000

Few developers like writing document

If you have ever worked as a developer in a large company, you know that coding is just one small part of the daily responsibilities. One of Google's full-stack software engineers, Ray Farias, once estimated that developers write about 100-150 lines of code per day at Google. While this estimate may vary across different teams, the order of magnitude matches my observations as a developer at Microsoft.

So where does the time go? A significant portion goes to activities like meetings, code reviews, planning sessions, and documentation tasks. Among all these tasks, documentation is my least favorite—and I suspect many other teammates feel the same way.

The main reason is that we didn't see much value in it. We were required to write design documents at the start of each sprint before coding, and after reviewing them with each other, most would remain unchanged forever. I can't count how many times I found something strange in a document only to have its author tell me it was outdated. 😂 Why don't we update the docs? Because our boss considers it less important than fixing bugs or adding new features.

Documentation should serve as a high-level abstraction of code to aid understanding. When documentation falls out of sync with the code, it loses its purpose. However, keeping doc synchronized with code requires effort—something few people actually enjoy.

Uncle Bob(Robert C. Martin) has a famous quote about clean code:

Good code serves as its own comments

I think it would be great if this principle could be extended to documentation as well:

Good code is its own best documentation

Generate document using AI

There is a simple rule for the current trend in AI adoption: if humans don't enjoy doing something, let AI handle it. Documentation seems to fit perfectly into this category, especially as more and more code has already been generated by AI nowadays.

The timing couldn't be better, as GitHub has just announced that Copilot features are free. You could simply try to let it generate the documentation for your project for free. However, the result might not be as good as you expected. Is it because your prompt isn't good enough? Maybe, but there's a more essential reason behind this:

LLMs don't handle imperative code as well as they handle declarative text.

Imperative code often involves complex control flow, state management, and intricate dependencies. This procedural nature requires a deeper understanding of the intent behind the code, which can be difficult for LLMs to infer accurately. Moreover, the larger the code volume, the more likely the result will be inaccurate and less informative.

What's the first thing you want to see in a web application's documentation? Most likely, it's the data models that serve as the foundation of the entire application. Can data models be defined declaratively? Absolutely! Prisma ORM has already done a great job by allowing developers to define their application models in an intuitive data modeling language.

The ZenStack toolkit, built on top of Prisma, enhances the schema with additional capabilities. By defining access policies and validation rules directly within the data model, it becomes the single source of truth for the backend of your application.

When I say "single source of truth," it contains not only all the information for the backend—it actually is your entire backend. ZenStack automatically generates APIs and corresponding frontend hooks for you. With access policies defined, these can be safely called directly from the frontend without needing to enable row-level security (RLS) in the database layer. Or, in another way, you’ll hardly need to write any code for your backend.

Here is an extremely simplified example of a blog post app:

datasource db {
    provider = 'postgresql'
    url = env('DATABASE_URL')
}

generator js {
    provider = 'prisma-client-js'
}

plugin hooks {
    provider = '@zenstackhq/tanstack-query'
    output = 'lib/hooks'
    target = 'react'
}

enum Role {
    USER
    ADMIN
}

model Post {
    id        String  @id @default(cuid())
    title     String
    published Boolean @default(false)
    author    User    @relation(fields: [authorId], references: [id])
    authorId  String  @default(auth().id)

    @@allow('all', auth() == author)
    @@allow('read', auth() != null && published )
    @@allow('read', auth().role == 'ADMIN')
}

model User {
    id       String  @id @default(cuid())
    name     String?
    email    String? @unique
    password String  @password @omit
    role     Role    @default(USER)
    posts    Post[]

    @@allow('create,read', true)
    @@allow('update,delete', auth() == this)
}

We can easily create a tool that generates documentation from this schema using AI. You don't have to manually write and maintain docs anymore—simply integrate the generation process into the CI/CD pipeline, and there's no out-of-sync problem anymore. Here's an example of documentation generated from the schema:

I will walk you through the steps of how to create this tool.

ZenStack plugin system

Like many wonderful tools in the web development world, ZenStack adopts a plugin-based architecture. At the core of the system is the ZModel schema, around which features are implemented as plugins. Let's create a plugin to generate a markdown for a ZModel so it can be easily adopted by others.

For brevity, we'll focus on core parts. See the ZenStack documentation for complete plugin development details.

A plugin is simply a Node.js module that has the two parts:

A named export name that specifies the name of the plugin used for logging and error reporting.
A default function export containing the plugin logic.

Here's what it looks like:

import type { PluginOptions } from '@zenstackhq/sdk';
import type { DMMF } from '@zenstackhq/sdk/prisma';
import type { Model } from '@zenstackhq/sdk/ast';

export const name = 'ZenStack MarkDown';

export default async function run(model: Model, options: PluginOptions, dmmf: DMMF.Document) {
    ...
}

model is the ZModel AST. It is the result object model of parsing and linking the ZModel schema, which is a tree structure containing all the information in the schema.

We can use ZModelCodeGenerator provided by ZenStack sdk to get the ZModel content from the AST.

import { ZModelCodeGenerator } from '@zenstackhq/sdk';
const zModelGenerator = new ZModelCodeGenerator();
const zmodel = zModelGenerator.generate(model);

Now that we have the ingredients let's have AI do the cooking.

Use Vercel AI SDK to generate document

Initially, I planned to use OpenAI to do the job. But soon, I realized this would exclude developers who don't have access to paid OpenAI services. Thanks to Elon Musk, you can get free API keys from Grok (https://x.ai/).

However, I had to write separate code for each model provider. This is where the Vercel AI SDK shines. It provides a standardized interface for interacting with various LLM providers, allowing us to write code that works with multiple AI models. Whether you're using OpenAI, Anthropic's Claude, or other providers, the implementation remains consistent.

It provides a unified LanguageModel type, allowing you to specify any LLM model you wish to use. Simply check the environment to determine which model is available.

    let model: LanguageModel;

    if (process.env.OPENAI_API_KEY) {
        model = openai('gpt-4-turbo');
    } else if (process.env.XAI_API_KEY) {
        model = xai('grok-beta');
    }
    ...

The rest of the implementation uses the same unified API, regardless of which provider you choose.

Here is the prompt we use to let AI generate the content of the doc:

  const prompt = `
    You are the expert of ZenStack open-source toolkit. 
    You will generate a technical design document from a provided ZModel schema file that help developer understand the structure and behavior of the application. 
    The document should include the following sections:
    1. Overview 
        a. A short paragraph for the high-level description of this app
        b. Functionality
    2. an array of model. Each model has below two information:
        a. model name
        b. array of access policies explained by plain text
    here is the ZModel schema file:
    \`\`\`zmodel
    ${zmodel}
    \`\`\`
    `;

Generating structured data

When dealing with APIs, we prefer to use JSON data instead of plain text. Although many LLMs are capable of generating JSON, each has its own approach. For example, OpenAI provides a JSON mode, while Claude requires JSON formatting to be specified in the prompt. The good news is that Vercel SDK also unifies this ability across model providers using Zod schema.

For the prompt above, here is the corresponding response data structure we expect to receive.

    const schema = z.object({
        overview: z.object({
            description: z.string(),
            functionality: z.string(),
        }),
        models: z.array(
            z.object({
                name: z.string(),
                access_control_policies: z.array(z.string()),
            })
        ),
    });

Then call the generateObject API to let AI do his job:

const { object } = await generateObject({
        model
        schema
        prompt
    });

Here is the returned type that allows you to work within a type-safe manner:

const object: {
    overview: {
        description: string;
        functionality: string;
    };
    models: {
        name: string;
        access_control_policies: string[];
    }[];
}

Generate Mermaid ERD diagram

Let's also generate the ERD diagram for each model. This part is quite straightforward and easy to implement, so I think writing code is more reliable and efficient here. Of course, you could still employ AI as a copilot here. 😄

export default class MermaidGenerator {
    generate(dataModel: DataModel) {
        const fields = dataModel.fields
            .filter((x) => !isRelationshipField(x))
            .map((x) => {
                return [
                    x.type.type || x.type.reference?.ref?.name,
                    x.name,
                    isIdField(x) ? 'PK' : isForeignKeyField(x) ? 'FK' : '',
                    x.type.optional ? '"?"' : '',
                ].join(' ');
            })
            .map((x) => `  ${x}`)
            .join('\n');

        const relations = dataModel.fields
            .filter((x) => isRelationshipField(x))
            .map((x) => {
                // eslint-disable-next-line @typescript-eslint/no-non-null-assertion
                const oppositeModel = x.type.reference!.ref as DataModel;

                const oppositeField = oppositeModel.fields.find(
                    (x) => x.type.reference?.ref == dataModel
                ) as DataModelField;

                const currentType = x.type;
                const oppositeType = oppositeField.type;

                let relation = '';

                if (currentType.array && oppositeType.array) {
                    //many to many
                    relation = '}o--o{';
                } else if (currentType.array && !oppositeType.array) {
                    //one to many
                    relation = '||--o{';
                } else if (!currentType.array && oppositeType.array) {
                    //many to one
                    relation = '}o--||';
                } else {
                    //one to one
                    relation = currentType.optional ? '||--o|' : '|o--||';
                }

                return [`"${dataModel.name}"`, relation, `"${oppositeField.$container.name}": ${x.name}`].join(' ');
            })
            .join('\n');

        return ['```

mermaid', 'erDiagram', {% raw %}`"${dataModel.name}" {\n${fields}\n}`{% endraw %}, relations, '

```'].join('\n');
    }
}

Stitch everything up

Finally, we'll combine all the generated components together to get our final doc:

 const modelChapter = dataModels
        .map((x) => {
            return [
                `### ${x.name}`,
                mermaidGenerator.generate(x),
                object.models
                    .find((model) => model.name === x.name)
                    ?.access_control_policies.map((x) => `- ${x}`)
                    .join('\n'),
            ].join('\n');
        })
        .join('\n');

 const content = [
        `# Technical Design Document`,
        '> Generated by [`ZenStack-markdown`](https://github.com/jiashengguo/zenstack-markdown)',
        `${object.overview.description}`,
        `## Functionality`,
        `${object.overview.functionality}`,
        '## Models:',
        dataModels.map((x) => `- [${x.name}](#${x.name})`).join('\n'),
        modelChapter,
    ].join('\n\n');

Off the shelf

Of course, you don't have to implement this yourself. It's already published as an NPM package for you to install:

npm i -D zenstack-markdown

Add the plugin to your ZModel schema file

plugin zenstackmd {
    provider = 'zenstack-markdown'
}

Just don’t forget to put whatever AI API keys are available for you in your .env. Otherwise, you might get some surprising results. 😉

OPENAI_API_KEY=xxxx
XAI_API_KEY=xxxxx
ANTHROPIC_API_KEY=xxxx

When Embedded AuthN Meets Embedded AuthZ - Building Multi-Tenant Apps With Better-Auth and ZenStack

ymc9 — Tue, 17 Dec 2024 00:34:16 +0000

Building a full-fledged multi-tenant application can be very challenging. Besides having a flexible sign-up and sign-in system, you also need to implement several other essential pieces:

Creating and managing tenants
User invitation flow
Managing roles and permissions
Enforcing data segregation and access control throughout the entire application

It sounds like lots of work, and it indeed is. You may have done this multiple times if you're a veteran SaaS developer.

Better-auth is an emerging open-source TypeScript authentication framework that offers a comprehensive set of features and great extensibility. Besides supporting a wide range of identity providers, its powerful plugin system allows you to add new features that contribute extensions across the entire stack - data model, backend API, and frontend hooks. A good example is the Organization plugin, which sets the foundation for implementing multi-tenant apps with access control.

While better-auth solves the problem of determining a user's identity and roles, ZenStack continues from there and uses such information to control what actions the user can perform on a piece of data. ZenStack is built above Prisma ORM and extends Prisma's power with flexible access control and automatic CRUD API. Since better-auth has built-in integration with Prisma, the two can make a perfect combination for building secure multi-tenant applications. This post will walk you through the steps of creating one.

The goal and the stack

The target application we'll build is a Todo List. Its core functionalities are simple: creating lists and managing todos within them. However, the focus will be on the multi-tenancy and access control aspects:

Organization management

Users can create organizations and invite others to join. They can manage members and set their roles.

Current context

Users can choose an organization to be the active one.

Data segregation

Only data within the active organization can be accessed.

Role-based access control
- Admin members have full access to all data within their organization.
- Regular members have full access to the todo lists they own.
- Regular members can view the other members' todo lists and manage their content.

The essential weapons we'll use to build the app are:

Next.js: the full-stack framework
Better-Auth: user authentication and organization management
Prisma: the ORM that we use to talk to the database
ZenStack: enhancing Prisma with access control and automatic CRUD API
TanStack Query: the data fetching/caching library

The benefit of this stack is that everything runs embedded inside Next.js. There are no third-party cloud services or self-hosted ones. The only thing you need is a Next.js hoster and a database provider.

You can find the link to the completed project at the end of the post.

Base setup

Better-auth's Next.js Demo provides a great starting point for us, which already includes:

Authentication configuration
User sign-up and sign-in flow
Organization plugin for organization management and member invitation flow
Dashboard for self-serviced user management and organization management
Admin UI for managing users

One major change that we'll make to the demo is switching from Kysely to Prisma as the database client.

// lib/auth.ts

import { prismaAdapter } from 'better-auth/adapters/prisma';

export const auth = betterAuth({
  appName: 'Better Auth Demo',
  database: prismaAdapter(prisma, {
      provider: 'sqlite',
  }),
  ...
});

Then, install Prisma packages and generate a schema with the better-auth CLI:

npm install -D prisma
npm install @prisma/client
npx @better-auth/cli generate

The generated schema file should contain the following models:

User: a registered user
Session: a user session
Account: OAuth account (not used)
Verification: sign-up verification record
Organization: an organization
Member: a member of an organization (join table between User and Organization)
Invitation: an invitation to join an organization

The initial dashboard UI looks like:

Setting up ZenStack

In the following sections, we'll use ZenStack to implement the access control requirements. ZenStack uses its own DSL called ZModel to define data models and access policy rules. ZModel is a superset of the Prisma schema language. The ZenStack CLI can generate a Prisma schema from a ZModel file so that downstream Prisma consumers (like better-auth) will continue to work seamlessly.

Let's initialize the project with ZenStack:

npx zenstack@latest init

The command will install the necessary dependencies, and copies the "prisma/schema.prisma" file to "/schema.zmodel". Moving forward, we'll modify "schema.zmodel" and use the ZenStack CLI to regenerate the Prisma schema.

npx zenstack generate

Preparing data models

Better-auth helped us generate the authentication-related data models, leaving us to work on the application-specific ones: Todo List and Todo. As mentioned previously, we should update "schema.zmodel" to define them:

// schema.zmodel

model TodoList {
  id             String        @id @default(cuid())
  createdAt      DateTime      @default(now())
  updatedAt      DateTime      @updatedAt
  name           String
  owner          User          @relation(fields: [ownerId], references: [id])
  ownerId        String
  organization   Organization? @relation(fields: [organizationId], references: [id])
  organizationId String?
  todos          Todo[]
}

model Todo {
  id        String   @id @default(cuid())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  title     String
  done      Boolean  @default(false)
  listId    String
  list      TodoList @relation(fields: [listId], references: [id])
}

Then regenerate Prisma schema and push changes to the database:

npx zenstack generate
npx prisma db push

Finally, create a "/lib/db.ts" file to export the Prisma client:

// lib/db.ts

import { PrismaClient } from "@prisma/client";
export const prisma = new PrismaClient();

Mounting automatic CRUD API

ZenStack provides a Next.js server adapter that automatically exposes Prisma-style CRUD APIs. To mount it, install the server adapter package:

npm install @zenstackhq/server

, and then create a "/app/api/[...path]/router.ts" file:

// app/api/[...path]/router.ts"

import { prisma } from '@/lib/db';
import { NextRequestHandler } from '@zenstackhq/server/next';

async function getPrisma() {
  return prisma;
}

const handler = NextRequestHandler({ getPrisma, useAppDir: true });

export {
  handler as DELETE,
  handler as GET,
  handler as PATCH,
  handler as POST,
  handler as PUT,
};

This will expose a set of CRUD endpoints like /api/model/TodoList/findMany, /api/model/TodoList/create, etc. You can find more details here.

Although we can call these APIs with fetch directly, a much easier way is to leverage ZenStack's TanStack Query plugin to generate client-side hooks.

npm install @zenstackhq/tanstack-query

// schema.zmodel

plugin hooks {
  provider = "@zenstackhq/tanstack-query"
  target = "react"
  output = "./hooks/model"
}

npx zenstack generate

You can then enjoy type-safe Prisma-style hooks in the frontend code.

import { useFindManyTodoList }  from '@/hooks/model';

export function MyComponent() {
  const { data: lists, isLoading } = useFindManyTodoList({ include: { owner: true }});
  ...
}

Implementing access control

Now, we can manipulate the database from the frontend through the generated hooks and automatic API. However, the APIs are open to all without any protection, which is obviously not what we want.

The biggest value ZenStack adds above Prisma is access control, which can be implemented directly inside the schema using the @@allow and @@deny attributes. At runtime, ZenStack lets you create a wrapper around PrismaClient (called enhanced PrismaClient) that automatically enforces these policy rules. Access is rejected by default unless explicitly granted with an @@allow rule and not rejected by any @@deny rule. When using an enhanced client to access the database, inaccessible records are filtered out during read, and mutations with insufficient permissions are rejected.

In real-world applications, authorization is always connected to authentication: you'll determine a user's access based on his identity and other information (like organization membership, roles, etc.). In our context, we'll use better-auth to retrieve the current user's identity, active organization, and role in the organization and use this information as the "user context" when creating the enhanced PrismaClient. Since the auto APIs use the enhanced client, they are also secured.

// app/api/model/[...path]/route.ts

async function getPrisma() {
  const reqHeaders = await headers();
  const sessionResult = await auth.api.getSession({
    headers: reqHeaders,
  });

  if (!sessionResult) {
    // anonymous user, create enhanced client without user context
    return enhance(prisma);
  }

  let organizationId: string | undefined = undefined;
  let organizationRole: string | undefined = undefined;
  const { session } = sessionResult;

  if (session.activeOrganizationId) {
    // if there's an active orgId, get the role of the user in the org
    organizationId = session.activeOrganizationId;
    const org = await auth.api.getFullOrganization({ headers: reqHeaders });
    if (org?.members) {
      const myMember = org.members.find(
          (m) => m.userId === session.userId
      );
      organizationRole = myMember?.role;
    }
  }

  // create enhanced client with user context
  const userContext = {
    userId: session.userId,
    organizationId,
    organizationRole,
  };
  return enhance(prisma, { user: userContext });
}

The user context will be accessible in ZModel policy rules via the special auth() function. To get it to work, we'll use a type to define the shape of auth():

// schema.zmodel

type Auth {
  userId           String  @id
  organizationId   String?
  organizationRole String?
  @@auth
}

Now, we're ready to write the policy rules. You can find more information about access polices here.

1. Tenant segregation

model TodoList {
  ...

  // deny anonymous users
  @@deny('all', auth() == null)

  // deny access to lists that don't belong to the user's active organization
  @@deny('all', auth().organizationId != organizationId)
}

2. Users can only create lists for themselves

model TodoList {
  ...

  // users can create lists for themselves
  @@allow('create', auth().userId == ownerId)
}

3. Owner and admins have full access

By default, better-auth's organization members can have "owner", "admin", or "member" role.

model TodoList {
  ...

  // full access to: list owner, org owner, and org admins
  @@allow('all', 
    auth().userId == ownerId ||
    auth().organizationRole == 'owner' ||
    auth().organizationRole == 'admin')
}

4. Readable to organization members

model TodoList {
  ...

  // if the list belongs to an org, it's readable to all members
  @@allow('read', organizationId != null)
}

5. Owner and organization cannot be changed

You can use @allow and @deny attributes (note the single @ sign) to define field-level rules.

model TodoList {
  ...
  ownerId        String  @allow('update', false)
  organizationId String? @allow('update', false)
}

6. A user as full access to `Todo` if he can read its parent `TodoList`

We've managed to protect the TodoList model, and rules for the Todo model are yet to be defined. Fortunately, ZenStack allows you to reference relations in policy rules. The check() helper allows you to directly delegate permission check to a relation (here Todo -> TodoList).

model Todo {
  ...

  // `check()` delegates permission check to a relation
  @@allow('all', check(list, 'read'))
}

Finally, the Todo list UI

With the CRUD APIs secured and frontend hooks generated, implementing the UI for managing TodoLists becomes very straightforward. I'm only showing part of the implementation here.

// app/dashboard/todo-lists-card.tsx

export default function TodoListsCard() {
  // Note that you don't need to filter for the current user and the active organization
  // because the ZModel rules have taken care of it
  const { data: todoLists } = useFindManyTodoList({
    orderBy: { createdAt: 'desc' },
  });

  const { mutateAsync: del, isPending: isDeleting } = useDeleteTodoList();

  async function onDelete(id: string) {
    await del({ where: { id } });
  }

  return (
    <Card>
      <CardHeader>
        <CardTitle>Todo List</CardTitle>
      </CardHeader>
      <CardContent>
        <div>
          {todoLists?.map((list) => (
            <div key={list.id}>
              <p>{list.name}</p>
              <p>{list.createdAt.toLocaleString()}</p>
              <Button disabled={isDeleting} onClick={() => onDelete(list.id)}>
                Delete
              </Button>
            </div>
          ))}
        </div>
      </CardContent>
    </Card>
  );
}

You can find the fully completed code below:

ymc9 / better-auth-zenstack-multitenancy

A multi-tenant Todo app built with better-auth and ZenStack

This is the companion project of the blog post When Embedded AuthN Meets Embedded AuthZ - Building Multi-Tenant Apps With Better-Auth and ZenStack.

The project is based on better-auth's Next.js demo project.

Getting Started

Copy ".env.example" to ".env" and fill in the variables.
Install dependencies
```
npm install
```

Prepare the database

npx zenstack generate
npx prisma db push

Start dev server
```
npm run dev
```

View on GitHub

Conclusion

Authentication and authorization are two cornerstones of most applications. They can be especially challenging to build for multi-tenant ones. This post demonstrated how the work can be significantly simplified and streamlined by combining better-auth and ZenStack. The end result is a secure application with great flexibility and little boilerplate code.

Better-auth also supports defining custom permissions for organizations. Although not covered in this post, with some tweaking, you should be able to leverage it to define access policies. That way, you can manage permissions with better-auth's API and have ZenStack enforce them at runtime.

Building Multi-Tenant Apps Using StackAuth's "Teams" and Next.js

ymc9 — Wed, 11 Dec 2024 10:41:42 +0000

Building a full-fledged multi-tenant application can be very challenging. Besides having a flexible sign-up and sign-in system, you also need to implement several other essential pieces:

Creating and managing tenants
User invitation flow
Managing roles and permissions
Enforcing data segregation and access control throughout the entire application

It sounds like lots of work, and it indeed is. You may have done this multiple times if you're a veteran SaaS developer.

StackAuth is an open-source authentication and user management platform designed to integrate seamlessly into Next.js projects. Its combination of frontend/backend APIs and pre-built UI components dramatically simplifies the integration of such capabilities into your application. Similarly, its newer "Teams" feature provides an excellent starting point for creating multi-tenant applications. In this post, we'll explore leveraging it to build a non-trivial one while trying to keep our code simple and clean.

The goal and the stack

Team management

Users can create teams and invite others to join. They can manage members and set their roles.

Current context

Users can choose an team to be the current context.

Data segregation

Only data within the current team can be accessed.

Role-based access control
- Admin members have full access to all data within their team.
- Regular members have full access to the todo lists they own.
- Regular members can view the other members' todo lists and manage their content, as long as the list is not private.

The essential weapons we'll use to build the app are:

Next.js: the full-stack framework
StackAuth: user authentication and team management
Prisma: the ORM that we use to talk to the database
ZenStack: the authorization layer above Prisma that handles data segregation and access control

You can find the link of the completed project at the end of the post.

Adding team management

I assume you've created a Next.js project and completed the steps as described StackAuth's setup guide. Verify the basic sign-up/sign-in flow is working. Also, in StackAuth's management console, enable "Client-Side Team Creation" and "Automatic Team Creation" options in the "Team Settings" section.

Now, we can add the "SelectedTeamSwitcher" component into the layout.

// src/app/layout.tsx

import { SelectedTeamSwitcher } from "@stackframe/stack";
...

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <StackProvider app={stackServerApp}>
          <StackTheme>
            <header>
              <SelectedTeamSwitcher />
            </header>
            <main>{children}</main>
          </StackTheme>
        </StackProvider>
      </body>
    </html>
  );
}

With this one-liner, you'll have a set of fully working UI components for managing teams and choosing an active one!

Although StackAuth made it effortless to add "teams" feature into an app, it's up to you to determine how to use the user and team information to control data access. We'll see how to connect it with Prisma/ZenStack to achieve proper authorization.

Setting up the database

Our user and team data are stored on StackAuth's side. We need to store the todo lists and items in our own database. In this section, we'll set up Prisma and ZenStack and create the database schema.

Let's start with installing the necessary packages:

npm install --save-dev prisma zenstack
npm install @prisma/client @zenstackhq/runtime

Then we can create the database schema. Please note that we're creating a schema.zmodel file (as a replacement of "schema.prisma"). The ZModel language is a superset of Prisma schema language, allowing you to model both the data schema and access control policies. In this section, we'll only focus on the data modeling part.

// schema.zmodel

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator js {
  provider = "prisma-client-js"
}

// Todo list
model List {
  id        String        @id @default(cuid())
  createdAt DateTime      @default(now())
  title     String
  private   Boolean       @default(false)
  orgId     String?
  ownerId   String
  todos     Todo[]
}

// Todo item
model Todo {
  id          String    @id @default(cuid())
  title       String
  completedAt DateTime?
  list        List      @relation(fields: [listId], references: [id], onDelete: Cascade)
  listId      String
}

You can then generate a regular Prisma schema file and push the schema to the database:

# The `zenstack generate` command generates the "prisma/schema.prisma" file and runs "prisma generate"
npx zenstack generate
npx prisma db push

Finally, create a "src/server/db.ts" file to export the Prisma client:

// src/server/db.ts

import { PrismaClient } from "@prisma/client";
export const prisma = new PrismaClient();

Implementing access control

As mentioned, ZenStack allows you to model both data and access control in a single schema. Let's see how we can entirely implement our authorization requirements with it. The rules are defined with the @@allow and @@deny attributes. Access is rejected by default unless explicitly granted with an @@allow rule.

Although authorization is a distinct concept from authentication, it usually depends on authentication to work. For example, to determine if the current user has access to a list, a verdict must be made based on the user's id, current team, and role in the team. To access such information, let's first declare a type to express it:

// schema.zmodel

// The shape of `auth()`
type Auth {
  // Current user's ID
  userId         String  @id

  // User's current team ID
  currentTeamId   String?

  // User's role in the current team
  currentTeamRole String?

  @@auth
}

Then you can use the special auth() function in access policy rules to access the current user's information. Let's use the List model as an example to demonstrate how the rules are defined.

// schema.zmodel

model List {
  ...

  // deny anonymous access
  @@deny('all', auth() == null)

  // tenant segregation: deny access if the user's current org doesn't match
  @@deny('all', auth().currentOrgId != orgId)

  // owner/admin has full access
  @@allow('all', auth().userId == ownerId || auth().currentOrgRole == 'org:admin')

  // can be read by org members if not private
  @@allow('read', !private)

  // when create, owner must be set to current user
  @@allow('create', ownerId == auth().userId)
}

The last piece of the puzzle is, as you may already be wondering, where the value of auth() comes from? At runtime, ZenStack offers an enhance() API to create an enhanced PrismaClient (a lightweighted wrapper) that automatically enforces the access policies. You pass in a user context (usually fetched from the authentication provider) when calling enhance(), and that context provides the value for auth().

We'll see how it works in detail in the next section.

Finally, the UI

Before diving into creating the UI, let's first make a helper to get an enhanced PrismaClient for the current user, team, and role.

// src/server/db.ts

import { enhance } from "@zenstackhq/runtime";
import { stackServerApp } from "~/stack";

export async function getUserDb() {
  const stackAuthUser = await stackServerApp.getUser();
  const currentTeam = stackAuthUser?.selectedTeam;

  // by default StackAuth's team members have "admin" or "member" role
  const perm =
    currentTeam && (await stackAuthUser.getPermission(currentTeam, "admin"));

  const user = stackAuthUser
    ? {
        userId: stackAuthUser.id,
        currentTeamId: stackAuthUser.selectedTeam?.id,
        currentTeamRole: perm ? "admin" : "member",
      }
    : undefined; // anonymous
  return enhance(prisma, { user });
}

Let's build the UI using React Server Components (RSC) and Server Actions. We'll also consistently use the getUserDb() helper to access the database with access control enforcement.

Here's the RSC that renders the todo lists for the current user (with styling omitted):

// src/components/TodoList.tsx

// Component showing Todo list for the current user

export default async function TodoLists() {
  const db = await getUserDb();

  // enhanced PrismaClient automatically filters out
  // the lists that the user doesn't have access to
  const lists = await db.list.findMany({
    orderBy: { updatedAt: "desc" },
  });

  return (
    <div>
      <div>
        {/* client component for creating a new List */}
        <CreateList />

        <ul>
          {lists?.map((list) => (
            <Link href={`/lists/${list.id}`} key={list.id}>
              <li>{list.title}</li>
            </Link>
          ))}
        </ul>
      </div>
    </div>
  );
}

A client component that creates a new list by calling into a server action:

// src/components/CreateList.tsx

"use client";

import { createList } from "~/app/actions";

export default function CreateList() {
  function onCreate() {
    const title = prompt("Enter a title for your list");
    if (title) {
      createList(title);
    }
  }

  return (
    <button onClick={onCreate}>
      Create a list
    </button>
  );
}

// src/app/actions.ts

'use server';

import { revalidatePath } from "next/cache";
import { getUserDb } from "~/server/db";

export async function createList(title: string) {
  const db = await getUserDb();
  await db.list.create({ data: { title } });
  revalidatePath("/");
}

The components that manage Todo items are not shown for brevity, but the ideas are similar. You can find the fully completed code here.

Conclusion

Authentication and authorization are two cornerstones of most applications. They can be especially challenging to build for multi-tenant ones. This post demonstrated how the work can be significantly simplified and streamlined by combining StackAuth's "Teams" feature and ZenStack's access control capabilities. The end result is a secure application with great flexibility and little boilerplate code.

StackAuth also supports defining custom permissions for teams. Although not covered in this post, with some tweaking, you should be able to leverage it to define access policies. That way, you can manage permissions with StackAuth's dashboard and have ZenStack enforce them at runtime.

Building Multi-Tenant Apps Using Clerk's "Organization" and Next.js

ymc9 — Mon, 25 Nov 2024 17:29:42 +0000

Building a full-fledged multi-tenant application can be very challenging. Besides having a flexible sign-up and sign-in system, you also need to implement several other essential pieces:

Creating and managing tenants
User invitation flow
Managing roles and permissions
Enforcing data segregation and access control throughout the entire application

It sounds like lots of work, and it indeed is. You may have done this multiple times if you're a veteran SaaS developer.

Clerk is one of the most popular authentication and user management cloud services. Its combination of APIs and pre-built UI components dramatically simplifies the integration of such capabilities into your application. Similarly, its newer "Organization" feature provides an excellent starting point for creating multi-tenant applications. In this post, we'll explore leveraging it to build a non-trivial one while trying to keep our code simple and clean.

The goal and the stack

Organization management

Users can create organizations and invite others to join. They can manage members and set their roles.

Current context

Users can choose an organization to be the current context.

Data segregation

Only data within the current organization can be accessed.

Role-based access control
- Admin members have full access to all data within their organization.
- Regular members have full access to the todo lists they own.
- Regular members can view the other members' todo lists and manage their content, as long as the list is not private.

Clerk can be used with any JavaScript framework, but its support for Next.js seems to be the best. So we'll use Next.js as our full-stack framework, along with two other essential pieces of weapon:

Prisma: the ORM
ZenStack: the access control layer on top of Prisma

You can find the link of the completed project at the end of the post.

Adding organization management

I assume you've created a Next.js project and set up the basic Clerk sign-up/sign-in flow following the guide. Also, make sure you've enabled the "Organization" feature in Clerk's dashboard.

Now, we can add the "OrganizationSwitcher" component into the layout.

// src/app/layout.tsx

import { OrganizationSwitcher } from "@clerk/nextjs";
...

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <ClerkProvider>
      <html lang="en">
        <body>
          <header>
            <SignedOut>
              <SignInButton />
            </SignedOut>
            <SignedIn>
              <div>
                <OrganizationSwitcher />
                <UserButton />
              </div>
            </SignedIn>
          </header>
        </body>
      </html>
    </ClerkProvider>
  );
}

With this one-liner, you'll have a set of fully working UI components for managing organizations and choosing an active one!

Setting up the database

Our user and organization data are stored on Clerk's side. We need to store the todo lists and items in our own database. In this section, we'll set up Prisma and ZenStack and create the database schema.

Let's start with installing the necessary packages:

npm install --save-dev prisma zenstack
npm install @prisma/client @zenstackhq/runtime

// schema.zmodel

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator js {
  provider = "prisma-client-js"
}

// Todo list
model List {
  id        String        @id @default(cuid())
  createdAt DateTime      @default(now())
  title     String
  private   Boolean       @default(false)
  orgId     String?
  ownerId   String
  todos     Todo[]
}

// Todo item
model Todo {
  id          String    @id @default(cuid())
  title       String
  completedAt DateTime?
  list        List      @relation(fields: [listId], references: [id], onDelete: Cascade)
  listId      String
}

You can then generate a regular Prisma schema file and push the schema to the database:

# The `zenstack generate` command generates the "prisma/schema.prisma" file and runs "prisma generate"
npx zenstack generate
npx prisma db push

Finally, create a "src/server/db.ts" file to export the Prisma client:

// src/server/db.ts
import { PrismaClient } from "@prisma/client";
export const prisma = new PrismaClient();

Implementing access control

Although authorization is a distinct concept from authentication, it usually depends on authentication to work. For example, to determine if the current user has access to a list, a verdict must be made based on the user's id, current organization, and role in the organization. To access such information, let's first declare a type to express it:

// schema.zmodel

// The shape of `auth()`
type Auth {
  // Current user's ID
  userId         String  @id

  // User's current organization ID
  currentOrgId   String?

  // User's role in the current organization
  currentOrgRole Role?

  @@auth
}

Then you can use the special auth() function in access policy rules to access the current user's information. Let's use the List model as an example to demonstrate how the rules are defined.

// schema.zmodel

model List {
  ...

  // deny anonymous access
  @@deny('all', auth() == null)

  // tenant segregation: deny access if the user's current org doesn't match
  @@deny('all', auth().currentOrgId != orgId)

  // owner/admin has full access
  @@allow('all', auth().userId == ownerId || auth().currentOrgRole == 'org:admin')

  // can be read by org members if not private
  @@allow('read', !private)

  // when create, owner must be set to current user
  @@allow('create', ownerId == auth().userId)
}

We'll see how it works in detail in the next section.

Finally, the UI

Before diving into creating the UI, let's first make a helper to get an enhanced PrismaClient for the current user.

// src/server/db.ts

import { auth } from "@clerk/nextjs/server";
import { Role } from "@prisma/client";
import { enhance } from "@zenstackhq/runtime";

export async function getUserDb() {
  // get the current user's information from Clerk
  const { userId, orgId, orgRole } = await auth();

  // create an enhanced Prisma Client with proper user context
  const user = userId
    ? {
        userId,
        currentOrgId: orgId,
        currentOrgRole: orgRole
      }
    : undefined; // anonymous
  return enhance(prisma, { user });
}

Let's build the UI using React Server Components (RSC) and Server Actions. We'll also consistently use the getUserDb() helper to access the database with access control enforcement.

Here's the RSC that renders the todo lists for the current user (with styling omitted):

// src/components/TodoList.tsx

// Component showing Todo list for the current user

export default async function TodoLists() {
  const db = await getUserDb();

  // enhanced PrismaClient automatically filters out
  // the lists that the user doesn't have access to
  const lists = await db.list.findMany({
    orderBy: { updatedAt: "desc" },
  });

  return (
    <div>
      <div>
        {/* client component for creating a new List */}
        <CreateList />

        <ul>
          {lists?.map((list) => (
            <Link href={`/lists/${list.id}`} key={list.id}>
              <li>{list.title}</li>
            </Link>
          ))}
        </ul>
      </div>
    </div>
  );
}

A client component that creates a new list by calling into a server action:

// src/components/CreateList.tsx

"use client";

import { createList } from "~/app/actions";

export default function CreateList() {
  function onCreate() {
    const title = prompt("Enter a title for your list");
    if (title) {
      createList(title);
    }
  }

  return (
    <button onClick={onCreate}>
      Create a list
    </button>
  );
}

// src/app/actions.ts

'use server';

import { revalidatePath } from "next/cache";
import { getUserDb } from "~/server/db";

export async function createList(title: string) {
  const db = await getUserDb();
  await db.list.create({ data: { title } });
  revalidatePath("/");
}

The components that manage Todo items are not shown for brevity, but the ideas are similar. You can find the fully completed code here.

Conclusion

Authentication and authorization are two cornerstones of most applications. They can be especially challenging to build for multi-tenant ones. This post demonstrated how the work can be significantly simplified and streamlined by combining Clerk's "Organization" feature and ZenStack's access control capabilities. The end result is a secure application with great flexibility and little boilerplate code.

Clerk also supports defining custom roles and permissions (still Beta) for organizations. Although not covered in this post, with some tweaking, you should be able to leverage it to define access policies. That way, you can manage permissions with Clerk's dashboard and have ZenStack enforce them at runtime.

ZenStack is our open-source TypeScript toolkit for building high-quality, scalable apps faster, smarter, and happier. It centralizes the data model, access policies, and validation rules in a single declarative schema on top of Prisma, well-suited for AI-enhanced development. Start integrating ZenStack with your existing stack now!

Typing Prisma Json Fields? Yes, You Can!

ymc9 — Thu, 07 Nov 2024 17:28:47 +0000

SQL databases provide us with many benefits, the most important of which is strong schema enforcement. Yes, you pay the cost of migration when the schema changes, but the gain is far more significant - your code is clean because it can assume all data are in correct shapes.

However, once in a while, we want to break free from such strong guarantees for valid reasons. You may have some tiny objects that you want to attach to the main entities (e.g., metadata of an image) without formalizing them into a separate table. Or you need to store records with many possible sparse fields but want to avoid creating wide tables.

Prisma's JSON type provides a generic escape hatch for such scenarios. It allows storing arbitrary data and gives you a generic JsonValue type in the query results.

// schema.prisma

model Image {
  id Int @id @default(autoincrement())
  metadata Json
}


// TS code

type Metadata {
  width: number
  height: number
  format: string
}

const image = await prisma.image.findFirstOrThrow();
// an explicit cast into the desired type
const metadata = image.metadata as Metadata;
console.log('Image dimensions:',
    metadata.width, 'by', metadata.height);

This is not always ideal because, in practice, many people use JSON type in a "controlled" way - only data of specific fixed shapes are stored in a field. So, regaining some of the strong typing capabilities would be very beneficial.

ZenStack's new "strongly typed JSON field" feature is designed to address this need. It allows you to define shapes of JSON data in the schema, and "fixes" PrismaClient to return data with correct types. The feature is in preview and only supports PostgreSQL for now.

Using strongly typed JSON fields

The first step is to use the new type keyword to define the shape of the JSON data in the ZModel schema (a DSL extended from Prisma schema):

// schema.zmodel

type Metadata {
  width Int
  height Int
  format String
}

model Image {
  id Int @id @default(autoincrement())
  metadata Metadata @json
}

Types have a structure similar to models but are not mapped to database tables. They only exist for typing and validation purposes. You can not have relations to other models in types. However, you can include fields of other types to form a nested structure.

When you run zenstack generate, the compiler will transform the typed JSON fields back into the regular Prisma Json type:

// schema.prisma

model Image {
  id Int @id @default(autoincrement())
  metadata Json
}

So, where did the Metadata type go? It's compiled into a TypeScript type declaration, which is used to type the query results when you use the ZenStack-enhanced PrismaClient:

// TS code

import { enhance } from '@zenstackhq/runtime';

const db = enhance(prisma);
const image = await db.image.findFirstOrThrow();

// image.metadata is now directly typed as 
// { width: number, height: number, format: string }
console.log('Image dimensions:',
    image.metadata.width, 'by', image.metadata.height);

When you create or update, the input is also properly typed so you get nice auto-completion and typechecking for the payload:

// TS code

await db.image.create({
  data: {
    metadata: {
      width: 1920,
      height: '1080', // <- type error here
      format: 'jpeg'
    }
  }
});

Straightforward, isn't it? But the feature doesn't stop here.

How about some runtime validation?

For mutations, ZenStack also validates the input data's shape at runtime by deriving a Zod schema from the type declaration. You can also add additional constraints to fields the same way you can do with models:

// schema.zmodel

type Metadata {
  width Int @gt(0) @lt(10000)
  height Int @gt(0) @lt(10000)
  format String
}

Mutation calls violating these constraints will be rejected:

// TS code
await db.image.create({
  data: {
    metadata: {
      width: 1920,
      height: 10800, // <- runtime error here
      format: 'jpeg'
    }
  }
});

Error calling enhanced Prisma method `image.create`: denied by policy:
image entities failed 'create' check, input failed validation:
Validation error: Number must be less than 10000 at "metadata.height"

Is it really type-safe?

JSON fields are meant to hold arbitrary data types, so there isn't really a way to guarantee data consistency. As such, to preserve enough flexibility, ZenStack doesn't validate if the query results comply with the type declaration. This effectively means you can't trust the TypeScript typings alone if you know the column contains mixed data.

One way to mitigate the problem is to validate the data with the generated Zod schemas explicitly:

import { MetadataSchema } from '@zenstackhq/runtime/zod/models';

const image = await db.image.findFirstOrThrow();
const metadata = MetadataSchema.parse(image.metadata);

Next steps

One area that's not addressed by this feature yet is the filtering part. The where clause still follows Prisma's Json filter format:

// find images with width greater than 102
const images = await db.image.findMany({
  where: {
    metadata: { path: ['width'], gt: 1024 }
  }
});

We can potentially "enhance" that part to provide a typed experience like:

const images = await db.image.findMany({
  where: {
    metadata: { width: { gt: 1024 } }
  }
});

Is it useful, or can it be confusing (as it looks the same as relation filters)? Let us know by leaving a comment below. You can also learn more about this feature in the official guide.

About ZenStack

ZenStack is a TypeScript toolkit that systematically extends Prisma ORM's power. Besides strongly typed JSON fields, it offers a set of other capabilities that may greatly simplify your full-stack development:

Authorization rules in schema
Auto RESTful API generation
Frontend query hooks generation
...

Make sure you check it out if you're using Prisma.

Programmers, Will AI Work For You, With You, or Without You?

ymc9 — Mon, 14 Oct 2024 16:15:29 +0000

"Programming is dead."

A friend said so when he heard I was working on dev tools. It was right after LLM’s coding abilities shocked the world. He felt it pointless to continue building tools for human programmers anymore when AI is taking over this profession. You'll never be wrong by predicting without attaching a time frame. Dead when? At least for the time being, the emergence of generative AI has introduced more work for programmers, some more difficult than before.

Whether AI will replace human developers is too big a topic to tackle. However, we can keep an open mind and explore different roles that AI can play in software development. Let's conduct thought experiments to imagine what each means to us.

Coding Copilot

We all love GitHub Copilot. There’s absolutely zero learning curve. Your IDE suddenly gets 10x smarter and generates code snippet completions as you type. It’s fast. It’s context-aware. It keeps you in the flow by letting you stay inside the IDE.

The quality is pretty good. Far from perfect, but the tolerance in this scenario is also pretty high. Who doesn’t enjoy some free code written for? Even if it’s not 100% correct, it can still be a good starting point. Otherwise, you’ll go to StackOverflow and grab something there anyway, won’t you?

A Copilot works FOR developers. It’s a tool, but a very smart one. It’s fully at your disposal, and its entire goal is to make you more productive. You, the human programmer, are the pilot. This brings several implications:

All prior wisdom generated by humans for humans continues to be valid and important — writing readable code, using design patterns to combat complexity, planning for the future, etc. Eventually, they are used to overcome humans' limited capacity for comprehension, memory, and consistency.
Languages, frameworks, and libraries will continue to be created and evolve as they are today. Made by humans for humans, these tools are the actualization of wisdom mentioned in #1. Contrary to what laymen may expect, the top priority of these tools is not generating powerful and performant applications but lowering programmers' mental load. DX will continue to be one of the most essential topics in the industry.
Following #1 and #2, such AI Copilot must adapt well to whatever tools the human programmer has chosen to use. It must serve him by creating code that not only works but is also "good" by human standards. Preferably, the code should have a consistent style as those manually written.

Copilots like GitHub Copilot, Codeium, and Cursor have proven very useful. However, they are certainly not the kind of disruptive innovation the crowd anticipates.

What's next?

Buddy Developer

Although routines are the primary unit developers organize and work on their code, they usually think at a higher granularity — feature. Features have business meanings, making them a good fit for planning, communication, and delivery. They’re also the ideal unit for breaking work down and distributing it among team members.

Naturally, AI's more ambitious goal is to tackle feature development directly.

You play a product manager or team leader role in such a setup. The AI works WITH you. It takes requirements from you, employs its own thoughts to generate an implementation strategy, and eventually comes up with code that contains the feature and integrates seamlessly into the project's code base. Instead of prompting with code or comments, as when you use Copilot, you prompt your AI buddy with requirements in natural language, optionally complemented by other high-level artifacts like a flow chart.

This poses some very tough challenges. One obvious problem is that humans are terribly incapable of describing things precisely.

Wife: buy a watermelon on your way home. If you see tomatoes, buy two.

Q: how many watermelons should the husband buy if he sees tomatoes?

Humans are even worse at precisely understanding other people’s thoughts. So when we work with our AI buddy, we can have these desperate struggles:

Have I explained enough of my needs to the AI?
Does the execution plan generated by the AI (most AIs take a "plan-then-write" approach) show that it’ll actually cover everything I need?

Of course, the ultimate guarantee is to review every line of code the AI writes thoroughly, but our expectations should be higher than that. When humans see ambiguity, we resort to common sense. If a pair of communicators share a "common" common sense, they’re likely to be on the same page. That's why a team gets more efficient after working together for an extended period of time. LLMs are already amazingly good at capturing common sense (albeit with a brute-force approach). As they get even better in the future, we can probably have enough confidence that we’re actually talking to a reasonable person.

Another bigger question is whether LLMs are powerful enough to implement features. Today’s LLMs have extremely tight context size limits. Unlike Copilots, which work at the code snippet level, feature-building AIs need a ton of context, often a big portion of the entire code base, and maybe access the code change history to understand why something currently works the way it does. Also, generating large chunks of code is computation-intensive, which can be rather slow and prohibitively expensive.

Of course, we can wait for LLMs to get much stronger or employ techniques like CoT to mitigate the problem, but another parallel solution is probably to adapt our project setup to help AIs do a better job. Use more high-level programming languages (including DSLs), do more declarative coding, make APIs more succinct, and employ more pre-built components so that AIs don’t need to generate from scratch. Basically, just try programming at a higher abstraction level and write less code. Just think about it: how much difference will it make if AI codes against a well-designed ORM API vs. generating SQL directly to access the database? A higher level of abstraction reduces AI’s cognition and generation load, and thus less chance of hallucination.

The benefits are also mutual. If AI generates higher-level code, you’ll also have a much easier time comprehending it, validating it, and making changes to it as necessary.

Feature-building AI is still in its very early stages. Products like Cursor Composer, Marblism, and Replit Agent are having a good head start. For such products to succeed, a solid long-term partnership needs to form between humans and AI. It requires finding the right compromise (languages, frameworks, libraries, etc.) that allows both humans and AI to work effectively.

Fully Autonomous Software Engineer

We even tried giving Devin real jobs on Upwork and it could do those too!
— Introducing Devin, Cognition AI

I’m not sure how true the story is, as it mentioned no details about what kind of jobs were done, how many times they were done, the success rate, how satisfied the customers were, etc.

The ultimate form of AI-assisted programming will be fully autonomous programming agents. It requires no supervision from professional software engineers, takes requirements directly from non-technical stakeholders, and delivers systems end to end. From a developer’s perspective, the AI works WITHOUT us! Or, in more brutal words, it replaces us. Instead of hiring an IT team, a non-tech-savvy company may purchase AI computation power to build and host the business applications they need.

It can have some very interesting implications:

How the application is built can be a complete black box. This is what happens inside an organization when the IT department delivers an app to a business team. The demanding party doesn’t care and can’t understand how it works internally.
Given #1, AI can implement the system as straightforwardly as it sees fit. There’s no more restraint on writing code that humans can understand and change. There’s no need to follow best practices designed to mitigate human weakness. Duplicated code? Not a problem as long as it makes sure when a change is needed, all duplicates are consistently updated. SOLID principles? No more relevant. What humans see as shitty code can be perfectly fine for AI.

If we pursue this direction, it'll make sense to design languages and building blocks that maximize LLM's performance. AI programming and human programming would become two distinct worlds. Is it utopia or dystopia? I’m not sure. Fortunately, after a two-year cooling down, we know today’s AI is still extremely limited. A full-scale replacement of human developers is not coming any time soon.

Final Thoughts

The future is very uncertain. But what’s certain is that software developers are among the first cohort to benefit from AI. We will also be the first group of people who struggle with it. Anyone who seriously integrated LLM into a product knows how frustrating it is to program against it — it’s restricted, unstable, slow, and hallucinating all the time. It's an API that requires us to think very differently. If old-days APIs are like Newtonian physics, LLMs are quantum mechanics — no more determinism, everything is probabilistic.

It’s too early to worry about being replaced by AI programmers. What’s imminent is to learn how to combat its weakness. Regardless of its immaturity, Generative AI is undoubtedly the most promising key to unlocking an exciting future.

Supabase RLS Alternative

JS — Wed, 24 Jul 2024 08:45:12 +0000

A Short History of BaaS

In the early days of web and mobile app development, building a backend from scratch was laborious and error-prone. Developers had to manage servers, databases, and infrastructure and ensure scalability while writing the core business logic of their applications. Then came Backend-as-a-Service (BaaS), promising to liberate developers from this burden.

Firebase: The Pioneer

Firebase was one of the first BaaS platforms to gain widespread adoption. It was acquired by Google, and at Google I/O in 2016, it announced an expansion of its services to become a unified BaaS platform for mobile developers. Firebase quickly became popular among developers for its ease of use and integration with Google's ecosystem.

However, as projects grew in complexity, so did concerns about vendor lock-in and data control. Its rigid data models and scalability issues led developers to seek more flexible and robust alternatives.

Supabase: The Open-Source Contender

In response to these limitations, Supabase was founded in 2020, positioning itself as the “open-source Firebase alternative.” Built on top of PostgreSQL, it offered a more flexible and powerful database solution while remaining open-source. Unsurprisingly, it soon became the new spokesperson for BaaS.

ACL(Access Control Layer) is the Core

While BaaS promises a simple abstraction of connecting the frontend to the database, it actually rejects another old-school promise:

You never expose the database directly to the frontend

The hero behind it is the ACL, or more specifically, authorization. It is the gatekeeper that stands between your database and potentially malicious actors. It ensures that users can only read or write data they are authorized to access.

Firebase: Security Rules

Firebase introduces a simple DSL to enforce access control.

service cloud.firestore {
  match /databases/{database}/documents {
    match /posts/{postId} {
      allow read: if true;
      allow write: if request.auth != null && request.auth.uid == resource.data.authorId;
    }
  }
}

Supabase: RLS(Row Level Security)

Since Supabase is built upon Postgres, it could leverage PostgreSQL's robust RLS to handle access control.

-- owner has full access to her own posts
CREATE POLICY post_owner_policy ON post
    USING (owner = current_user);

Since RLS is written in SQL, it allows more fine-grained access control. Developers can define policies that determine which rows of data a user can access based on their role or other attributes. Theoretically, it could express any authorization pattern you use, like RBAC, ABAC, PBAC, etc.

Multi-Tenancy SaaS Example

Multi-tenancy is the classical pattern used in SaaS applications. An application can host many organizations, and users can join organizations and access resources based on their permissions. Let’s use a ToDo app to illustrate.

Database Model

The User and Space are many-to-many relations through the relation table SpaceUser.
A Todo belongs to a User, and a List
A List belongs to the User, and a Space

RLS rules for List

Let’s go through the access control requirements for List model and the corresponding RLS rules.

Create

owner must be set to the current user.
user must be in the space.

create policy "list_create"
on "public"."List"
to public
with check (
  ((auth.uid() = ("ownerId")::uuid) AND (EXISTS ( SELECT 1
   FROM "SpaceUser"
  WHERE (("SpaceUser"."spaceId" = "List"."spaceId") AND (("SpaceUser"."userId")::uuid = auth.uid())))))
);

Read

can be read by the owner.
can be read by space members if not private.

create policy "list_read"
on "public"."List"
to authenticated
using (
   ((auth.uid() = ("ownerId")::uuid) OR ((NOT private) AND (EXISTS (SELECT 1
   FROM "SpaceUser"
  WHERE (("SpaceUser"."spaceId" = "List"."spaceId") AND (("SpaceUser"."userId")::uuid = auth.uid()))))))
);

Update

only the owner is allowed to update
owner must be in the space of the current list
it doesn’t allow to change owner

create policy "list_update"
on "public"."List"
to authenticated
using (
  ((auth.uid() = ("ownerId")::uuid) AND (EXISTS ( SELECT 1
   FROM "SpaceUser"
  WHERE (("SpaceUser"."spaceId" = "List"."spaceId") AND (("SpaceUser"."userId")::uuid = auth.uid())))))
with check (
  (auth.uid() = ("ownerId")::uuid)
);

Delete

can be deleted by owner

create policy "list.delete"
on "public"."List"
to authenticated
using (
  (auth.uid() = ("ownerId")::uuid)
);

Supabase provides a RESTful API using PostgREST. However, without RLS, you will expose your database to the frontend. With the RLS policies created above, it’s safe to expose the API to the public because each user can only access the data allowed by the policy. For example, if you try to get all the List items using the API below, you will only receive the ones you are allowed to read by the read policy:

curl '{SUPABASE_PROJECT_URL}/rest/v1/List?select=*' \
-H "apikey: SUPABASE_ANON_KEY" \
-H "Authorization: Bearer USER_JWT_TOKEN"

Everything looks perfect, especially if you are familiar with SQL. So why do I need alternatives?

The Problems of Supabase RLS

1.Separation from Application Logic

As a modern developer, you know the sense of control when you can launch with a one-click. The prerequisite is to keep everything within the codebase. It's not just about convenience; it's about maintaining a single source of truth, ensuring consistency, and streamlining your workflow.

However, for RLS, you have to define authorization directly in the database, not in your source code. Of course, you could store it as an SQL file in your codebase, but you need to rely on SQL migration to ensure consistency. I think it’s the same reason why you seldom see people using stored procedures of databases nowadays despite all the benefits they offer.

What makes the consistency even worse is that you have to duplicate the policy filters in the application code. For example, if you are using the Supabase JS SDK, you have to use the two queries below to get the result:

// First, get the user's spaceIds
const { data: userSpaces } = await supabase.from('SpaceUser').select('spaceId').eq('userId', userId);

// Extract spaceIds from the result
const userSpaceIds = userSpaces.map((space) => space.spaceId);

// Now, query the List table
const { data, error } = await supabase
    .from('List')
    .select('*')
    .or(`ownerId.eq.${userId},and(private.eq.false,spaceId.in.(${userSpaceIds.join(',')}))`);

Why? Because otherwise, you might experience 20x slower query performance, according to the official benchmark of Supabase. 😲

Add filters to every query | Supabase Docs

2. Poor DX

If you are an SQL expert, you can ignore this one.

Writing SQL itself is not considered a good developer experience (DX) for many developers, with the majority adopting ORM. Moreover, you have to write it in a UI box without the help of Intellisense and often get an obscure error after clicking the save button:

The more challenging part is testing and debugging. Honestly, I have no idea about the best practice for it; if you have any tips, please share them in the comments.

3. Scalability

You might feel the aforementioned RLS for List is clear and straightforward, but that’s only for one table. If the access control policy for Todo is the same as List, which is a very common case, what policy do you need to create for Todo? The answer is that you have to duplicate all the policies of the list for Todo. That’s definitely not DRY(Don’t repeat yourself).

If you don't think it's a big deal, imagine you're lucky enough to grow your Todo SaaS into a team collaboration platform that manages various entities like dashboards, tasks, bugs, projects, etc.

4. Maintainability

Let’s say we get a feature request that if a team member can see a Todo list, he will have full access to all the Todos under it, even the ones not owned by him.

Do you know what change you need to make? You need to delete all the policies copied from the List mentioned above and then create a new policy below:

create policy "Todo"
on "public"."Todo"
to authenticated
using (
  ((EXISTS ( SELECT 1
   FROM "List"
  WHERE (("List".id = "Todo"."listId") AND (("List"."ownerId")::uuid = auth.uid())))) OR (EXISTS ( SELECT 1
   FROM (("List"
     JOIN "Space" ON (("List"."spaceId" = "Space".id)))
     JOIN "SpaceUser" ON (("SpaceUser"."spaceId" = "Space".id)))
  WHERE (("List".id = "Todo"."listId") AND (("SpaceUser"."userId")::uuid = auth.uid()) AND (NOT "List".private)))))
)

Do you think you can write this kind of policy all by yourselves? I actually asked ChatGPT to write it myself. Even if it's not a problem for you, think about how another team member might feel when he sees it for the first time.

And don't forget to duplicate this change in your application code for performance's sake. 😂

Alternative Solution

Remember in 2016 when Google I/O Firebase announced its expansion to BaaS? In the same year, another product with an interesting name joined this journey: Graphcool.

Maybe you haven't heard about it because it was sunsetted in 2020, the same year Supabase came out (what a coincidence!). Why was it sunsetted? See the detailed explanation on its home page:

https://www.graph.cool/

TLDR: The team felt that BaaS was too limited for developers to build the next generation of web applications, so they pivoted it to the Prisma ORM.

It simplifies database interactions by providing a type-safe query builder, seamless migrations, and an intuitive data modeling language. While Prisma ORM does provide more flexibility compared to BaaS, it intentionally misses the access control layer as an ORM. Consequently, you have to switch back to implementing Authorization logic at the application level.

Is it possible to bring back the convenience of not writing code for the Authorization like BaaS while maintaining the flexibility of a custom backend?

That's why we built ZenStack on top of Prisma ORM, adding the missing authorization layer and auto-generating type-safe APIs/hooks. It gives you the same convenience as using BaaS while maintaining flexibility with everything in your codebase.

Let’s cut the crap and see the code directly. Below are the equivalent ZenStack schema definitions of List and Todo you need to write for the ToDo apps.

abstract model BaseEntity {
    id        String   @id @default(uuid())
    space     Space    @relation(fields: [spaceId], references: [id], onDelete: Cascade)
    spaceId   String
    owner     User     @relation(fields: [ownerId], references: [id], onDelete: Cascade)
    ownerId   String   @default(auth().id)

    // can be read by owner or space members 
    @@allow('read', owner == auth() || (space.members?[user == auth()]))

    // when create, owner must be set to current user, and user must be in the space
    @@allow('create', owner == auth() && space.members?[user == auth()])

    // when create, owner must be set to current user, and user must be in the space
    // update is not allowed to change owner
    @@allow('update', owner == auth() && space.members?[user == auth()] && future().owner == owner)

    // can be deleted by owner
    @@allow('delete', owner == auth())
}

/**
 * Model for a Todo list
 */
model List extends BaseEntity {
    title   String  @length(1, 100)
    private Boolean @default(false)
    todos   Todo[]

    // can't be read by others if it's private
    @@deny('read', private == true && owner != auth())
}

/**
 * Model for a single Todo
 */
model Todo {
    id          String    @id @default(uuid())
    owner       User      @relation(fields: [ownerId], references: [id], onDelete: Cascade)
    ownerId     String    @default(auth().id)
    list        List      @relation(fields: [listId], references: [id], onDelete: Cascade)
    listId      String
    title       String    @length(1, 100)
    completedAt DateTime?

    // same as its parent list
    @@allow('all', check(list))
}

Keep in mind that with this schema done, although you still need a server to deploy, you hardly need to write any backend code. ZenStack introspects the schema and installs CRUD APIs to the framework of your choice. Thanks to the access policy defined in the model, the APIs are fully secure and can be directly exposed to the public. You can also generate the OpenAPI(swagger) specification.

In fact, you don’t even need to be aware of the API, as ZenStack generates fully typed client hooks that call into the generated APIs. You can directly use those hooks with intrinsic automatic invalidation and optimistic update support.

What about the problems of RLS? Let’s go through them one by one.

1. Single Source of Truth

The access policies are now defined alongside the database models. The schema becomes the single source of truth of your backend, enabling an easier understanding of the system as a whole.

Moreover, whether calling from the frontend or backend, you don’t need to use any filter regarding the authorization rules, which will be injected into queries automatically by the ZenStack runtime. The application code you need to write is clean and clear:

   // frontend query：hook is auto generated by ZenStack
   const { data: lists } = useFindManyList();    
   ...

   // server props  
   export const getServerSideProps: GetServerSideProps<Props> = async ({ req, res, params }) => {
    const db = await getEnhancedPrisma({ req, res });

    const lists = await db.list.findMany();
    return {
        props: { lists },
    };
};

Remember the complex query you need to write for the RLS case mentioned above?

2. Good DX

ZenStack comes with a VSCode extension. All the basic features of IntelliSense, like autocomplete, Inline error reporting, Go-to definition, finding the reference, and auto-format,

work as usual.

If you have GitHub Copilot, there is a big chance that you don’t have to write the policy yourself:

For testing and debugging, you can enable ZenStack's debug logging by setting a simple flag. Then, you can see all the Prisma queries ZenStack actually calls to the database from the console log:

prisma:info [policy] `findMany` list:
{
  where: {
    AND: [
      { NOT: { OR: [] } },
      {
        OR: [
          { owner: { is: { id: 1 } } },
          {
            AND: [
              {
                space: {
                  members: {
                    some: { user: { is: { id: 1 } } }
                  }
                }
              },
              { NOT: { private: true } }
            ]
          }
        ]
      }
    ]
  }
}

Since all the code is actually running on your server, you can set breakpoints in the generated code to debug it step by step.

ZenStack also provides a REPL CLI for interactive query execution. You can quickly switch between different user contexts and see how the access policies affect the result.

3. Scalability

Have you noticed that for Todo there is only one line of the policy rule?

    // same as its parent list
    @@allow('all', check(list))

There is no need to duplicate the policies of List as needed for RLS.

Furthermore, if you need to add a new top-level entity like Bug, all you need is to add the below model in the schema:

model Bug extends BaseEntity {
    title    String @length(1, 100)
    priority Int
}

What about the policy rules for it? Thanks to model inheritance, it could inherit all the policies from the abstract base model BaseEntity.

As you can see, ZenStack has provided several features to keep schemas DRY and achieve better scalability.

4. Maintainability

Implementing the requirement change request mentioned above is just adding one parameter

// full access if the parent list is readable
// @@allow('all', check(list))
   @@allow('all', check(list, 'read'))

Nothing explains better than code here.

Here is the complete runnable project for this SaaS ToDo app:

https://github.com/zenstackhq/sample-todo-nextjs

The Art of Trade-off

As developers, we know better than others that every sword has two blades. For all the problems I mentioned with RLS above, the opposite side also shows its advantage. For example:

Although the policy is separate from the application, you don’t have to redeploy the application to let the new policy take effect.
While RLS's SQL policy may seem less intuitive than ZenStack’s, it is more flexible and has a better ecosystem.

Software engineering is an art of trade-offs. It involves balancing time and space, stability and flexibility, performance and code complexity, and more. What ZenStack provides is just another alternative; it's up to you to balance these trade-offs and make it an art.

Someone has completed the artwork in production 😉

We've launched MermaidChart's team feature using ZenStack. Much cleaner and easier to maintain than writing RLS policies or application level checks that will surely leak after some time.

— Sidharth MermaidChart

Forem: ZenStack

Prisma vs Drizzle vs ZenStack: Choosing a TypeScript ORM in 2026

1. The Three Philosophies

2. Data Modeling

3. Querying

4. Access Control & Multi-Tenancy

5. API & Framework Integration

6. Extensibility

7. Performance

8. Ecosystem & Maturity

Conclusion: How to Choose

Your Stack Choice Is Coding Agent's Safety Net

We Need a New Way to Evaluate a Stack

What Makes a Stack "Agent-Friendly"?

1. Strong Type System = Compile-Time Guardrails

2. Declarative Rules Over Imperative Logic

3. Single Source of Truth for Data Shape and Rules

When the Safety Net Is Missing

How ZenStack Acts as the Safety Net

Shrink the Blast Radius

Choose Stacks That Protect You From Speed

ZenStack V3: The Perfect Prisma ORM Alternative

A bit of history

Dual API from a single schema

Battery included

Built-in access control

Strongly typed JSON

Polymorphic models

Extensible from the ground up

Simpler, smaller footprint

Beyond ORM

Conclusion

Turning Your Database Into an MCP Server With Auth

MCP is trending in AI, But…

The Advent of Authorization for MCP

MCP Is a Good Enhancement for SaaS

Two Approaches to Building an MCP Server

1. Relying on the Existing API

2. Start from Scratch

Building an MCP Server from Scratch

Initialize the Project

Auth

PasswordAuthProvider

Stateful Multi-connections Streamable HTTP Server

Tool

Schema

Execution

Test

How to Build AI Agents to Enhance SaaS With Minimal Code and Effort

Is SaaS Really Dead?

Challenge of Building an AI Chatbot

Schema-First Fit AI-First

Building an AI Chatbot from Scratch

1. Creating the project

2. Initialize the project for ZenStack

3. Implement Signup/Signin

4. Implement the chatbot logic with Vercel AI SDK and ZenStack

Try It for Your Own Application

Code as Doc: Automate by Vercel AI SDK and ZenStack for Free

Few developers like writing document

Generate document using AI

ZenStack plugin system

Use Vercel AI SDK to generate document

Generating structured data

Generate Mermaid ERD diagram

Stitch everything up

Off the shelf

When Embedded AuthN Meets Embedded AuthZ - Building Multi-Tenant Apps With Better-Auth and ZenStack

The goal and the stack

Base setup

Setting up ZenStack

Preparing data models

Mounting automatic CRUD API

Implementing access control

1. Tenant segregation

2. Users can only create lists for themselves

3. Owner and admins have full access

4. Readable to organization members

5. Owner and organization cannot be changed

6. A user as full access to Todo if he can read its parent TodoList

6. A user as full access to `Todo` if he can read its parent `TodoList`