DEV Community: ymc9

A fresh look at the ORM landscape — and how the new ZenStack stacks up against Prisma and Drizzle.

ymc9 — Fri, 03 Apr 2026 20:49:20 +0000

ymc9 for ZenStack

Apr 2

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

#typescript #prisma #drizzle #database

Comments

12 min read

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!

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.

Rendering Prisma Queries With React Table: The Low-Code Way

ymc9 — Sun, 21 Jul 2024 19:01:29 +0000

React Table, or more precisely, TanStack Table is a headless table UI library. If you're new to this kind of product, you'll probably ask, "What the heck is headless UI"? Isn't UI all about the head, after all? It all starts to make sense until you try something like React Table.

For two reasons, tables are one of the nastiest things to build in web UI. First, they are difficult to render well, considering the amount of data they can hold, the interactions they allow, and the need to adapt to different screen sizes. Second, their state is complex: sorting, filtering, pagination, grouping, etc. React Table's philosophy is to solve the second problem well and leave the first entirely to you. It manages the state and logic of a table but doesn't touch the rendering part because:

Building UI is a very branded and custom experience, even if that means choosing a design system or adhering to a design spec. - tanstack.com

Tables are most commonly used to render database query results — in modern times, the output of an ORM. In this post, I'll introduce a way of connecting Prisma - the most popular TypeScript ORM, to React Table, with the help of React Query and ZenStack. You'll be amazed by how little code you need to write to render a full-fledged table UI.

A full-stack setup

We need a full-stack application to query a database and render the UI. In this example, I'll use Next.js as the framework, although the approach can be applied to other similar frameworks (like Nuxt, SvelteKit, etc.), or to an application with decoupled front-end and back-end.

We can easily create a new project with npx create-next-app. After that, we need to install several dependencies:

Prisma - the ORM
ZenStack - a full-stack toolkit built above Prisma
React Query - the data-fetching library
React Table - the headless table library

We'll also use the legendary "North Wind" trading dataset (created by Microsoft many, many years ago) to feed our database. Here's its ERD:

A Prisma schema file is authored to reflect this database structure.

The "free lunch" API

SQL databases are not meant to be consumed from the frontend. You need an API to mediate. You can build such an API in many ways, but here we'll use ZenStack to "unbuild" it. ZenStack is a full-stack toolkit built above Prisma, and one of the cool things it does is to automagically derive a backend API from the schema.

Setting ZenStack up is straightforward:

Run npx zenstack init to prep the project. It copies the schema.prisma file into schema.zmodel - which is the schema file used by ZenStack. ZModel is a superset of Prisma schema.
Whenever you make changes to schema.zmodel, run npx zenstack generate to regenerate the Prisma schema and PrismaClient.

ZenStack can provide a full set of CRUD API with Next.js in a few lines of code:

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

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

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

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

Now you have a set of APIs mounted at /api/model that mirrors PrismaClient:

GET /api/model/order/findMany?q=...
GET /api/model/order/count?q=...
PUT /api/model/order/update
...

The query parameters and body also follow the corresponding PrismaClient method parameters.

I know a big 🚨 NO THIS IS NOT SECURE 🚨 is flashing in your mind. Hold on, we'll get to that later.

The "free lunch" hooks

Having a free API is cool, but writing fetch to call it is cumbersome. How about some free query hooks? Yes, add the @zenstackhq/tanstack-query plugin to the ZModel schema, and you'll have a set of fully typed React Query hooks generated for each model:

// schema.zmodel

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

The hooks call into the APIs we installed in the previous section, and they also precisely mirror PrismaClient's signature:

import { useFindManyOrder } from '@/hooks/order';

// data is typed as `(Order & { details: OrderDetail[]; customer: Customer })[]`
const { data, isLoading, error } = useFindManyOrder({
  where: { ... },
  orderBy: { ... },
  include: { details: true, customer: true }
});

Please note that although React Query and React Table are both from TanStack, you don't have to use them together. React Table is agnostic to the data fetching mechanism. They just happen to play very well together.

Finally, let's build the table

Creating a basic table is straightforward, You define the columns and then initialize a table instance with data. We'll see how to do it by building a table to display order details.

// the relation fields included when querying `OrderDetail`
const queryInclude = {
  include: {
    order: { include: { employee: true } },
    product: { include: { category: true } },
  },
} satisfies Prisma.OrderDetailFindManyArgs;

// create a column helper to simplify the column definition
// The `Prisma.OrderDetailGetPayload<typeof queryInclude>` type gives us
// the shape of the query result
const columnHelper =
  createColumnHelper<Prisma.OrderDetailGetPayload<typeof queryInclude>>();

const columns = [
  columnHelper.accessor('order.id', { header: () => <span>Order ID</span> }),

  columnHelper.accessor('order.orderDate', {
      cell: (info) => info.getValue()?.toLocaleDateString(),
      header: () => <span>Date</span>,
  }),

  // other columns ...

  columnHelper.accessor('order.employee.firstName', {
      header: () => <span>Employee</span>,
  }),
];

export const OrderDetails = () => {
  // fetch data with query hooks
  const { data } = useFindManyOrderDetail({
    ...queryInclude
  });

  // create a table instance
  const table = useReactTable({
    data: orders ?? [],
    columns,
    getCoreRowModel: getCoreRowModel(),
  });
}

We can then render the table with some basic tsx:

export const OrderDetails = () => {
  ...

  return (
    <table>
      <thead>
        {table.getHeaderGroups().map((headerGroup) => (
          <tr key={headerGroup.id}>
            {headerGroup.headers.map((header) => (
              <th key={header.id}>
                {flexRender(
                  header.column.columnDef.header,
                  header.getContext()
                )}
              </th>
            ))}
          </tr>
        ))}
      </thead>
      <tbody>
        {table.getRowModel().rows.map((row) => (
          <tr key={row.id}>
            {row.getVisibleCells().map((cell) => (
              <td key={cell.id}>
                {flexRender(
                  cell.column.columnDef.cell,
                  cell.getContext()
                )}
              </td>
            ))}
          </tr>
        ))}
      </tbody>
  );
}

With the help of column definitions, React Table knows how to fetch data for a cell and transform it as needed. You only need to focus on properly laying the table out.

What's cool about React Table is that you don't need to flatten the nested query result into tabular form. The columns can be defined to reach into deeply nested objects.

Making it fancier

Tables allow you to do many things besides viewing data. Let's use pagination as an example to demonstrate how to enable such interaction in our setup.

React Query has built-in support from front-end pagination. However, since we're rendering database tables, we want the pagination to run at the backend. First, we define a pagination state and set the table to use manual pagination mode (meaning that we handle the pagination ourselves):


// pagination state
const [pagination, setPagination] = useState<PaginationState>({
  pageIndex: 0,
  pageSize: PAGE_SIZE,
});

// fetch total row count
const { data: count } = useCountOrderDetail();

const table = useReactTable({
  ...

  // pagination
  manualPagination: true,
  onPaginationChange: setPagination,
  pageCount: Math.ceil((count ?? 0) / PAGE_SIZE),

  // state
  state: { agination },
});

Also, update the hooks call to respect the pagination state:

const { data } = useFindManyOrderDetail({
  ...queryInclude,
  skip: pagination.pageIndex * pagination.pageSize,
  take: pagination.pageSize,
});

Finally, add navigation buttons:

<div>
  <button onClick={() => table.previousPage()} disabled={!table.getCanPreviousPage()}>
    Prev
  </button>
  <button onClick={() => table.nextPage()} disabled={!table.getCanNextPage()}>
    Next
  </button>
  <span className="ml-2">
    Page {table.getState().pagination.pageIndex + 1} of{' '}
    {table.getPageCount().toLocaleString()}
  </span>
</div>

This part well demonstrates the value of "headless" UI. You don't need to manage detailed pagination state anymore. Instead, provide the bare minimum logic and let React Table handle the rest. Sorting can be implemented similarly. Check out the link at the end of this post for the complete code.

Tons of flexibility

We've got a pretty cool table end-to-end working now, with roughly 200 lines of code. Less code is only one of the benefits of this combination. It also provides excellent flexibility in every layer of the stack:

Prisma's query

Prisma is known for its concise yet powerful query API. It allows you to do complex joins and aggregations without writing SQL. In our example, our table shows data from five tables, and we barely noticed the complexity.
ZenStack's access control

Remember I said we'll get back to the security issue? A real-world API must have an authorization mechanism with it. ZenStack's real power lies in its ability to define access control rules in the data schema. You can define rules like rejecting anonymous users or showing only the orders of the current login employee, etc. Read more details here.
React Query's fetching

React Query provides great flexibility around how data is fetched, cached, and invalidated. Leverage its power to build a highly responsive UI and reduce the load on the database at same time.
React Table's state management

React Table has every aspect of a table's state organized for you. It provides a solid pattern to follow without limiting how you render the table UI.

Conclusion

The evolution of dev tools is like a pendulum swinging backward and forward between simplicity and flexibility. All these years of wisdom have distilled into awesome tools like React Table and React Query, which seem to have found a good balance. They are not the simplest to pick up, but they are simple enough yet wonderfully flexible.

The complete sample code: https://github.com/ymc9/react-query-table-zenstack

Low-Code Backend Solution for Refine.dev Using Prisma and ZenStack

ymc9 — Mon, 27 May 2024 14:12:18 +0000

Refine.dev is a very powerful and popular React-based framework for building web apps with less code. It focuses on providing high-level components and hooks to cover common use cases like authentication, authorization, and CRUD. One of the main reasons for its popularity is that it allows easy integration with many different kinds of backend systems via a flexible adapter design.

This post will focus on the most important type of integration: database CRUD. I'll show how easy it is, with the help of Prisma and ZenStack, to turn your database schema into a fully secured API that powers your refine app. You'll see how we start by defining the data schema and access policies, derive an automatic CRUD API from it, and finally integrate with the Refine app via a "Data Provider."

A quick overview of the tools

Prisma

Prisma is a modern TypeScript-first ORM that allows you to manage database schemas easily, make queries and mutations with great flexibility, and ensure excellent type safety.

ZenStack

ZenStack is a toolkit built above Prisma that adds access control, automatic CRUD web API, etc. It unleashes the ORM's full power for full-stack development.

Auth.js

Auth.js (successor of NextAuth) is a flexible authentication library that supports many authentication providers and strategies. Although you can use many external services for auth, simply storing everything inside your database is often the easiest way to get started.

A blogging app

I'll use a simple blogging app as an example to facilitate the discussion. We'll first focus on implementing the authentication and CRUD with essential access control and then expand to more advanced topics.

You can find the link to the completed project's GitHub repo at the end of the post.

Scaffolding the app

The create-refine-app CLI provides several handy templates to scaffold a new app. We'll use the "Next.js" one so that we can easily contain both the frontend and backend in the same project. Most of the ideas in this post can be applied to a standalone backend project as well.

We also need to install Prisma and NextAuth:

npm install --save-dev prisma
npm install @prisma/client next-auth@beta

Finally, we'll create the database schema for our app (schema.prisma):

datasource db {
  provider = "sqlite"
  url      = "file:./dev.db"
}

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

model User {
  id            String    @id() @default(cuid())
  name          String?
  email         String?   @unique()
  emailVerified DateTime?
  image         String?
  createdAt     DateTime  @default(now())
  updatedAt     DateTime  @updatedAt()
  accounts      Account[]
  sessions      Session[]
  password      String
  posts         Post[]
}

model Post {
  id        String   @id() @default(cuid())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt()
  title     String
  content   String
  status    String   @default("draft")
  author    User     @relation(fields: [authorId], references: [id])
  authorId  String
}

model Account {
  ...
}

model Session {
  ...
}

model VerificationToken {
  ...
}

The Account, Session, and VerificationToken models are required by Auth.js.

Building authentication

The focus of this post will be data access and access control. However, they are only possible with an authentication system in place. We'll use simple credential-based authentication in this app. The implementation involves creating an Auth.js configuration, installing an API route to handle auth requests, and implementing a Refine "Authentication Provider".

I won't elaborate on the details of this part, but you can find the completed code here. It should get the registration, login, and session management parts working.

Set up access control

There are many ways to implement access control. People typically put the check in the API layer with imperative code. ZenStack offers a unique and powerful way to do it declaratively inside the database schema. Let's see how it works.

First, let's initialize the project for ZenStack:

npx zenstack@latest init

It'll install a few dependencies and copies over the prisma/schema.prisma file to /schema.zmodel. ZModel is a superset of Prisma Schema Language that adds more features like access control.

Next, we'll add policy rules to the schema:

model User {
  ...

  // everybody can signup
  @@allow('create', true)

  // full access by self
  @@allow('all', auth() == this)
}


model Post {
  ...

  // allow read for all signin users
  @@allow('read', auth() != null && status == 'published')

  // full access by author
  @@allow('all', author == auth())
}

As you can see, the overall schema still looks very similar to the original Prisma schema. The @@allow directive defines access control rules. The auth() function returns the current authenticated user. We'll see how it's connected with the authentication system next.

The most straightforward way to use ZenStack is to create an "enhancement" wrapper around the Prisma client. First, run the CLI to generate JS modules that support the enforcement of policies:

npx zenstack generate

Then, you can call the enhance API to create an enhanced PrismaClient.

const session = await auth();
const user = session?.user?.id ? { id: session.user.id } : undefined;
const db = enhance(prisma, { user });

Besides the prisma instance, the enhance function also takes a second argument that contains the current user. The user object provides value to the auth() function call in the schema at runtime.

The enhanced PrismaClient has the same API as the original one, but it will enforce the policy rules automatically for you.

Automatic CRUD API

Having the ORM instance enhanced with access control capabilities is great. We can now implement CRUD APIs without writing imperative authorization code as long as we use the enhanced client. However, wouldn't it be even cooler if the CRUD APIs were automatically derived from the schema?

ZenStack makes it possible by providing a set of server adapters for popular Node.js frameworks. Using it with Next.js is easy. You'll only need to create an API route handler:

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

import { auth } from '@/auth';
import { prisma } from '@/db';
import { enhance } from '@zenstackhq/runtime';
import { NextRequestHandler } from '@zenstackhq/server/next';

// create an enhanced Prisma client with user context
async function getPrisma() {
  const session = await auth();
  const user = session?.user?.id ? { id: session.user.id } : undefined;
  return enhance(prisma, { user });
}

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

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

You then have a set of CRUD APIs served at "/api/model/[Model Name]/...". The APIs closely resemble PrismaClient's API:

/api/model/post/findMany
/api/model/post/create
...

You can find the detailed API specification here.

Implementing a data provider

We've got the backend APIs ready. Now, the only missing piece is a Refine "Data Provider", which talks to the API to fetch and update data. The following code snippet shows how the getList method is implemented. Refine's data provider's data structure is conceptually very close to Prisma, and we only need to do some lightweighted translation:

// src/providers/data-provider/index.ts

export const dataProvider: DataProvider = {

  getList: async function <TData extends BaseRecord = BaseRecord>(
      params: GetListParams
  ): Promise<GetListResponse<TData>> {
    const queryArgs: any = {};

    // filtering
    if (params.filters && params.filters.length > 0) {
      const filters = params.filters.map((filter) =>
          transformFilter(filter)
      );
      if (filters.length > 1) {
          queryArgs.where = { AND: filters };
      } else {
          queryArgs.where = filters[0];
      }
    }

    // sorting
    if (params.sorters && params.sorters.length > 0) {
      queryArgs.orderBy = params.sorters.map((sorter) => ({
          [sorter.field]: sorter.order,
      }));
    }

    // pagination
    if (
      params.pagination?.mode === 'server' &&
      params.pagination.current !== undefined &&
      params.pagination.pageSize !== undefined
    ) {
      queryArgs.take = params.pagination.pageSize;
      queryArgs.skip =
          (params.pagination.current - 1) * params.pagination.pageSize;
    }

    // call the API to fetch data and count
    const [data, count] = await Promise.all([
      fetchData(params.resource, '/findMany', queryArgs),
      fetchData(params.resource, '/count', queryArgs),
    ]);

    return { data, total: count };
  },

  ...
};

With the data provider in place, we now have a fully working CRUD UI.

You can sign up for two accounts and verify that the access control rules are working as expected - draft posts are only visible to the author.

Bonus: guarding UI with permission checker

Let's add one more challenge to the problem: the users of our app will have two roles:

Reader: can only read published posts
Writer: can create new posts

Our schema needs to be updated accordingly:

model User {
  ...

  role          String    @default('Reader')
}

model Post {
  ...

  // allow read for all signin users
  @@allow('read', auth() != null && status == 'published')

  // allow "Writer" users to create
  @@allow('create', auth().role == 'Writer')

  // full access by author
  @@allow('read,update,delete', author == auth())
}

Now, if you try to create a new post with a "Reader" account, you'll see the following error:

The operation is denied correctly according to the rules. However, it's not an entirely user-friendly experience. It'd be nice to prevent the "Create" button from appearing in the first place. This can be achieved by combining two additional features from Refine and ZenStack:

Refine allows you to implement an "Access Control Provider" to verdict whether the current user has permission to perform an action.
ZenStack's enhanced PrismaClient has an extra check API for inferring permission based on the policy rules. The check API is also available in the automatic CRUD API.

ZenStack's check API doesn't query the database. It's based on logical inference from the policy rules. See more details here.

Let's see how these two pieces are put together. First, implement an AccessControlProvider:

// src/providers/access-control-provider/index.ts

export const accessControlProvider: AccessControlProvider = {
  can: async ({ resource, action }: CanParams): Promise<CanReturnType> => {
    if (action === 'create') {
      // make a request to "/api/model/:resource/check?q={operation:'create'}"
      let url = `/api/model/${resource}/check`;
      url +=
        '?q=' +
        encodeURIComponent(
            JSON.stringify({
                operation: 'create',
            })
        );
      const resp = await fetch(url);
      if (!resp.ok) {
        return { can: false };
      } else {
        const { data } = await resp.json();
        return { can: data };
      }
    }

    return { can: true };
  },

  options: {
    buttons: {
        enableAccessControl: true,
        hideIfUnauthorized: false,
    },
    queryOptions: {},
  },
};

Then, register the provider to the top-level Refine component:

// src/app/layout.tsx

<Refine 
  accessControlProvider={ accessControlProvider }
  ...
/>

You'll immediately notice the difference that, with a "Reader" user, the "Create" button is grayed out and disabled.

However, you can still directly navigate to the "/blog-post/create" URL to access the create form. We can prevent that by using Refine's CanAccess component to guard it:

// src/app/blog-post/create/page.tsx

<CanAccess
    resource="post"
    action="create"
    fallback={<div>Not Allowed</div>}
>
    <Create ... />
</CanAccess>

Mission accomplished! We've also done it elegantly without hard coding any permission logic in the UI. Everything about access control is still centralized in the ZModel schema.

Conclusion

Refine.dev is a great tool for building complex UI without writing complex code. Combined with the superpowers of Prisma and ZenStack, we've now got a full-stack, low-code solution with excellent flexibility.

The completed sample project is here: https://github.com/ymc9/refine-nextjs-zenstack.

Adapting ZenStack to the Edge: Our Struggles and Learnings

ymc9 — Fri, 19 Apr 2024 11:34:30 +0000

Edge has been a buzzword for web development for a while, but the reality is the ecosystem support is still lagging, many tools and libraries are not ready for it yet. We've recently been working on adapting ZenStack to the edge runtime. As we're wrapping up the work, it's time to share our struggles and learnings with you.

What is Edge Runtime?

In the context of JavaScript development, edge runtime is a kind of runtime environment that allows code to run closer to the user's location, typically at the "edge" of the network. It can potentially improve the performance of web applications by reducing latency and increasing the speed of content delivery.

For developers, the main mind-warping aspect of edge runtime is that it's a server-side environment, but it offers browser-like APIs. It means you can't enjoy the full power of Node.js or use arbitrary npm packages there. Most hurdles in adapting a project to edge runtime are about going around these limitations. You can get a feeling of what APIs are supported by skimming through this specification from WinterCG.

The Hurdles and Solutions

1. CommonJS Support

My initial worry was that to run in an edge runtime, your code has to be compiled into ESM. To my surprise, that's not the case. Although the edge runtime itself is not Node.js compatible and doesn't support the require API, apparently, the tooling of the hosting environments (like Vercel and Cloudflare) can handle CommonJS modules just fine. This saved us from the immediate trouble of converting our codebase to ESM, although we should do it anyway to keep up with the future trend.

2. Loading Modules Dynamically

Being able to use CommonJS doesn't mean there are no restrictions. One of the biggest hurdles we met was that require a module from a dynamically calculated path is not supported. We do that in ZenStack for several reasons. For example, to deal with differences between multiple versions of a peer dependency (Prisma ORM specifically), we detect its version and adjust the module load path accordingly. It'll result in errors like:

Error: Dynamic require of "[Module Name]" is not supported.

Fortunately, ZenStack has a compiler that generates JavaScript modules (from a DSL) loaded at runtime. We could turn the runtime detection into compile-time and generate the correct module import code for the specific project setup (Prisma version). That way, the module load path is static at runtime and works well with edge runtime.

3. Node APIs

Edge runtime is not Node.js compatible, and this is an intentional trade-off made for a lighter footprint and better security. You can avoid using Node-specific APIs in your code, but it can be a harder problem to solve if some of your essential dependencies are using them.

For example, ZenStack relies on bcryptjs to hash passwords, which uses Node's crypto module. Ironically, crypto API is available in the edge runtime, but it's provided as a built-in, meaning you can't explicitly require it. To work around the problem, we have to let our users add a "browser" entry into "package.json" to tell Vercel's bundler to ignore the package during resolution:

{
  ...
  "browser": {
    "crypto": false
  }
}

It's ugly, but it solves the problem.

Another problem with bcryptjs is its async hash function uses the process.nextTick Node API to yield control to the event loop for better performance. Cloudflare Worker's runtime provides a shim for the API, but unfortunately, Vercel doesn't have it. We have to detect if we're running on Vercel and fall back to the synchronous hashSync function.

const hashFunc = typeof EdgeRuntime === 'string' 
    ? require('bcryptjs').hashSync 
    : require('bcryptjs').hash;

4. Vendor Maturity and Consistency

If you've read to this point, you've probably already noticed that different edge environments behave differently. Yes, there is a specification about the common APIs to support, but many details remain unspecified, leaving vendors to make their own decisions. We've only tested Vercel and Cloudflare so far and have no idea how other vendors like Netlify Edge or AWS Lambda@Edge may break in other ways 🤔.

So far, the experience working with Cloudflare has been smoother than Vercel (or, more accurately, Next.js?). We've run into numerous issues with Vercel without an actionable error message. For example, the reason for the following is still unknown:

Compiler edge-server unexpectedly exited with code: null and signal: SIGTERM

5. A Bonus Trap

After getting everything running locally with a Next.js project targeting edge runtime, we excitedly deployed it to Vercel. And it worked, well, sometimes ... and other times the APIs on edge randomly return HTTP 405, 500, and 504 with incomprehensible errors like:

[GET ] /api/... reason=INTERNAL_EDGE_FUNCTION_INVOCATION_FAILED, status=500, upstream_status=500, user_error=false
[POST] /api/... reason=EDGE_FUNCTION_INVOCATION_TIMEOUT, status=504, user_error=true

We created a Vercel ticket, communicated back and forth with their support for a few days, and couldn't identify the cause. Until I accidentally found this piece of comment from Prisma's dev lead @janpio:

> I also want to know if this way of instantiating a Prisma Client on each function call
> is the best approach, as in other app components I'm using a global prisma client as 
> from the docs

Yes, this is unfortunately a limitation of the edge runtimes. Connections can only be used
in the request where they were created, if you try to reuse them this might initially even
work - but as soon as one worker or environment is called to handle multiple requests at
the same time (which can happen in these environments) your worker will crash with an
exception.

Right. As how you usually do in a Node.js application, I had a global PrismaClient singleton. After changing to create a new instance for each request, the random errors are gone, and everything works perfectly.

I still don't know why using a global instance causes such bizarre errors. Please leave a comment if you do, and I'll really appreciate it. The world is amazing - if you try hard enough, you can find a solution to pretty much any problem by some odd coincidence.

Now That You Can. Should You?

Many excellent posts already analyze whether you should run your API on the edge, and I don't need to repeat them. Just be sure to do the research and make first-hand performance measurements before making a final decision to have your API talk to a database from the edge. This reflection from @leeerob is a very interesting one to read.

DEV Community: ymc9

A fresh look at the ORM landscape — and how the new ZenStack stacks up against Prisma and Drizzle.

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

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

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

Finally, the Todo list UI

ymc9 / better-auth-zenstack-multitenancy

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

Getting Started

Conclusion

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

The goal and the stack

Adding team management

Setting up the database

Implementing access control

Finally, the UI

Conclusion

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

The goal and the stack

Adding organization management

Setting up the database

Implementing access control

Finally, the UI

Conclusion

Typing Prisma Json Fields? Yes, You Can!

Using strongly typed JSON fields

How about some runtime validation?

Is it really type-safe?

Next steps

About ZenStack

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

Coding Copilot

Buddy Developer

Fully Autonomous Software Engineer

Final Thoughts

Rendering Prisma Queries With React Table: The Low-Code Way

A full-stack setup

The "free lunch" API

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